在很多分布式系統(tǒng)中，我們經常看到它們使用心跳機制，為什么這么多的分布式系統(tǒng)使用心跳機制？心跳機制到底是什么？今天一起來聊一聊。

一、什么是心跳機制？

在分布式系統(tǒng)中，心跳其實就是從一個組件發(fā)送到另一個組件的定期消息，用于交換數(shù)據(jù)或者健康狀態(tài)，心跳可以是單向的，也可以是雙向的。

1.單向心跳包

單向心跳包是由一個節(jié)點（發(fā)送者）定期向另一個節(jié)點（接收者）發(fā)送消息，而不要求接收者回復。這種方式簡單而高效，適用于一些基本的健康檢查和狀態(tài)監(jiān)控。

優(yōu)點：

• 實現(xiàn)簡單：發(fā)送者只需定期發(fā)送心跳包，不需要處理回復邏輯。
• 低延遲：減少了通信的往返時間，適合低延遲應用場景。

缺點：

• 缺乏確認：接收者的狀態(tài)信息是單向的，發(fā)送者無法確定接收者是否收到心跳包。
• 誤報風險：如果網絡臨時中斷，接收者無法通知發(fā)送者，可能導致誤報。

使用場景：

• 基礎監(jiān)控：如定期發(fā)送服務器狀態(tài)信息到監(jiān)控系統(tǒng)。
• 簡單的健康檢查：如負載均衡器檢查后端服務器是否存活。

2.雙向心跳包

雙向心跳包涉及兩個節(jié)點之間的雙向通信。一個節(jié)點發(fā)送心跳包，接收者收到后回復確認消息。這種方式能夠提供更可靠的狀態(tài)信息。

優(yōu)點：

• 確認機制：發(fā)送者能確認接收者是否收到心跳包，提高了通信的可靠性。
• 狀態(tài)同步：雙方可以交換狀態(tài)信息，確保數(shù)據(jù)的一致性和同步。

缺點：

• 實現(xiàn)復雜：需要處理發(fā)送和接收的邏輯，增加了系統(tǒng)的復雜性。
• 潛在延遲：增加了通信的往返時間，可能引入一些延遲。

使用場景：

• 故障檢測：如數(shù)據(jù)庫主從同步，確保數(shù)據(jù)一致性。
• 高可靠性應用：如分布式文件系統(tǒng)，確保各節(jié)點間的狀態(tài)同步。

如下圖：Server1 向 Server2 發(fā)送一條單向心跳消息：

二、為什么需要心跳機制？

因為分布式系統(tǒng)可能包含很多服務器，形成錯綜復雜的網絡交互，產生的問題也是形形色色，假如沒有心跳機制，可能會出現(xiàn)以下問題：

• 無法及時感知故障檢測
• 服務器停機時間和錯誤會增加
• 整體分布式系統(tǒng)的可靠性會降低

增加心跳機制后，可以實現(xiàn)以下功能：

• 監(jiān)控：心跳消息有助于監(jiān)控分布式系統(tǒng)不同部分的運行狀況和狀態(tài)。
• 檢測故障：心跳機制使系統(tǒng)能夠識別組件何時無響應。如果節(jié)點錯過了幾個預期的心跳信號，則表明可能存在問題。
• 觸發(fā)恢復操作：心跳機制允許系統(tǒng)采取糾正措施，如將任務移動到正常運行的節(jié)點、重新啟動故障組件或通知系統(tǒng)管理員介入。
• 負載均衡：通過監(jiān)控不同節(jié)點的心跳信號，負載均衡器可以根據(jù)每個節(jié)點的響應能力和運行狀況，更有效地在網絡中分配任務。

三、心跳機制是如何工作的？

心跳機制主要涉及兩個主要組件：

• 心跳發(fā)送者（節(jié)點）：定期發(fā)送心跳信號的節(jié)點。
• 心跳接收器（監(jiān)視器）：接收并監(jiān)視心跳信號的組件。

心跳機制整個過程包含以下幾個步驟：

• 節(jié)點定期向監(jiān)視器發(fā)送心跳包，比如每 5/10/30秒發(fā)送一次心跳包。
• 監(jiān)視器接收心跳包，并更新節(jié)點的狀態(tài)，比如“活動”或“可用”。
• 如果監(jiān)視器在規(guī)定的時間范圍內未收到節(jié)點的心跳包，則會將節(jié)點標記為“不可用”或“故障”。
• 系統(tǒng)檢測到有異常的節(jié)點，需要采取適當?shù)牟僮鳎缰囟ㄏ蛄髁俊庸收限D移過程或向管理員發(fā)出警報。

心跳包的發(fā)送機制通常上有 2種方式：

• Push方式：節(jié)點主動向監(jiān)視器發(fā)送心跳包
• Pull方式：監(jiān)視器會定期查詢節(jié)點的狀態(tài)

如下圖為一個簡單的心跳健康檢查機制：

四、心跳包類型

心跳包在分布式系統(tǒng)中本質上就是一條信息，只不過會根據(jù)不同的業(yè)務場景定義成不同的類型，以下是常見的心跳包類型：

(1) 簡單心跳包

• 用途：基本的存在檢測。
• 內容：通常包含節(jié)點ID和時間戳。
• 示例：節(jié)點每隔一段時間發(fā)送一個簡單消息，告知其仍在運行。

(2) 狀態(tài)心跳包

• 用途：不僅檢測節(jié)點存在，還報告節(jié)點狀態(tài)。
• 內容：包含節(jié)點ID、時間戳、CPU使用率、內存使用率、磁盤狀態(tài)等。
• 示例：節(jié)點發(fā)送詳細的狀態(tài)信息，使監(jiān)視器可以評估其健康狀況。

(3) 負載心跳包

• 用途：報告節(jié)點當前負載，以便于負載均衡。
• 內容：包含節(jié)點ID、時間戳、當前負載指標（如當前連接數(shù)、任務隊列長度等）。
• 示例：負載均衡器根據(jù)負載心跳包的信息來調整任務分配。

(4) 自檢心跳包

• 用途：節(jié)點自行檢查并報告其健康狀態(tài)。
• 內容：包含節(jié)點ID、時間戳、自檢結果（如服務健康檢查結果、錯誤日志摘要等）。
• 示例：節(jié)點定期運行自檢腳本，并將結果發(fā)送給監(jiān)視器。

(5) 同步心跳包

• 用途：用于多節(jié)點之間的狀態(tài)同步。
• 內容：包含節(jié)點ID、時間戳、同步狀態(tài)、最新數(shù)據(jù)版本等。
• 示例：數(shù)據(jù)庫集群中的主節(jié)點與從節(jié)點之間使用同步心跳包來確保數(shù)據(jù)一致性。

(6) 事件心跳包

• 用途：通知監(jiān)視器特定事件的發(fā)生。
• 內容：包含節(jié)點ID、時間戳、事件類型和事件詳細信息。
• 示例：節(jié)點在發(fā)生重要事件（如重新啟動、故障修復）時發(fā)送事件心跳包。

(7) 安全心跳包

• 用途：增強安全性，確保心跳消息的真實性和完整性。
• 內容：包含節(jié)點ID、時間戳、簽名信息或加密數(shù)據(jù)。
• 示例：節(jié)點發(fā)送的心跳包經過數(shù)字簽名，監(jiān)視器驗證簽名以確保消息未被篡改。

五、心跳機制面臨的問題

因為分布式系統(tǒng)包含了比較多的服務器，而心跳又是在這些服務器之間通過網絡傳播的，因此，使用心跳包也面臨一些挑戰(zhàn)：

• 網絡擁塞：如果管理不當，心跳信號的持續(xù)流動可能會導致網絡擁塞。
• 誤報：心跳信號間隔配置不當可能會導致故障檢測出現(xiàn)誤報，誤將運行緩慢但正常的組件標識為故障組件。
• 資源使用：持續(xù)監(jiān)控需要計算資源，必須優(yōu)化以防止對系統(tǒng)造成不必要的壓力。
• 腦裂場景：在極少數(shù)情況下，網絡故障可能會將系統(tǒng)分區(qū)，導致雙方節(jié)點互相宣布對方死亡，這需要更復雜的故障處理機制。

六、心跳機制的使用場景

心跳機制在分布式系統(tǒng)中有著大量的使用場景，這里列舉幾個實際工作中最常見的例子：

(1) 消息中間件

在消息中間件 RocketMQ中，Broker會通過心跳包和注冊中心 NameServer保持交互，這樣注冊中心就能監(jiān)控到 Broker的狀態(tài)，從而給生產者和消費者提供比較實時的 Broker集群列表。

(2) Kubernetes

在 Kubernetes容器編排平臺中，每個節(jié)點都會定期向控制平面發(fā)送心跳，以指示其可用性。控制平面使用這些檢測信號來跟蹤節(jié)點的運行狀況，并相應地做出調度決策。

(3) Elasticsearch

在 Elasticsearch集群中，節(jié)點交換心跳以形成八卦網絡。此網絡使節(jié)點能夠相互發(fā)現(xiàn)、共享集群狀態(tài)信息并檢測節(jié)點故障。

(4) Redis Cluster

Redis Cluster集群中的心跳包實現(xiàn)基于 Gossip協(xié)議，它是一種分布式通信協(xié)議，允許節(jié)點周期性地與隨機選擇的其他節(jié)點交換狀態(tài)信息。Redis Cluster的心跳包稱為 PING和 PONG消息，主要結構如下：

• PING 消息：用于發(fā)送節(jié)點的狀態(tài)信息，包括節(jié)點ID、節(jié)點角色（主節(jié)點或從節(jié)點）、槽位信息等。
• PONG 消息：用于響應 PING 消息，確認接收到的狀態(tài)信息。

七、總結

心跳機制在分布式系統(tǒng)中起到了重要的作用，因此，了解和掌握心跳機制，對于掌握分布式系統(tǒng)之間如何交互信息和服務器探活有著重要的意義。