本章涵蓋三種分散式系統中的故障偵測與狀態傳播模式：心跳機制（Heartbeat）、八卦協定（Gossip Protocol） 以及 Phi 累積故障偵測（Phi Accrual Failure Detection）。

心跳機制（Heartbeat）#

背景#

在分散式環境中，工作與資料分散在多台伺服器上。為了有效地路由請求，伺服器需要知道系統中有哪些其他伺服器，以及這些伺服器是否仍然存活且正常運作。及時偵測伺服器故障是一項關鍵任務，這使系統能夠採取矯正措施，將資料或工作轉移到其他健康的伺服器上，防止環境進一步惡化。

定義#

每台伺服器定期發送心跳訊息（Heartbeat Message）給中央監控伺服器或系統中的其他伺服器，以表明自己仍然存活且正常運作。

解決方案#

心跳機制是分散式系統中偵測故障的基本機制之一：

  • 若存在中央伺服器，所有伺服器定期向其發送心跳訊息
  • 若不存在中央伺服器，所有伺服器隨機選擇一組伺服器，每隔幾秒向它們發送心跳訊息
  • 若在一段時間內未收到某伺服器的心跳訊息，系統可以懷疑該伺服器可能已經當機
  • 若在設定的逾時期間（Configured Timeout）內沒有收到心跳，系統便判定該伺服器已不再存活，停止向其發送請求，並開始進行替換作業

逾時時間的設定需要謹慎權衡：過短可能導致誤判（False Positive），過長則會延遲故障偵測。

範例#

  • GFS：領導者（Leader）透過心跳訊息（HeartBeat Messages）定期與每台區塊伺服器（ChunkServer）通訊，用以發送指令並收集狀態資訊。
  • HDFS：名稱節點（NameNode）透過心跳機制追蹤資料節點（DataNode）的狀態。每個資料節點每隔幾秒向名稱節點發送定期心跳訊息。若資料節點停止運作，心跳訊息也隨之停止。當未收到的心跳訊息數量達到一定閾值（Threshold）時，名稱節點便將該資料節點標記為已停止運作，不再向其轉發任何 I/O 請求。

八卦協定（Gossip Protocol）#

背景#

在大型分散式環境中，若沒有中央節點來追蹤所有節點的狀態，一個節點該如何得知其他所有節點的當前狀態？

最簡單的方法是讓每個節點與其他所有節點都維持心跳連線。然而，這意味著每個時間單位（Tick）需要發送 O(N^2) 條訊息（N 為節點總數），這會消耗大量網路頻寬，在任何具有一定規模的叢集中都不可行。

在擁有數百或數千個節點的叢集中，全對全（All-to-All）心跳方式產生的訊息量會呈平方級增長，迅速耗盡網路資源。

定義#

每個節點維護關於其他節點的狀態資訊，並每秒將這些資訊八卦（Gossip）給隨機選取的另一個節點。最終，每個節點都會得知系統中所有其他節點的狀態。

解決方案#

八卦協定是一種點對點通訊機制（Peer-to-Peer Communication），其運作方式如下：

  • 每個節點定期（通常每秒一次）與一個隨機選取的節點交換狀態資訊
  • 交換的內容包含該節點自身的狀態以及它所知道的其他節點狀態
  • 狀態變更最終會透過整個系統傳播（Propagate）開來
  • 這種方式實現了最終一致性（Eventual Consistency）的狀態同步
sequenceDiagram
    participant A as 節點A(Node A)
    participant B as 節點B(Node B)
    participant C as 節點C(Node C)
    participant D as 節點D(Node D)

    Note over A: 節點A 偵測到新狀態變更
    A->>B: 1. 隨機選擇節點B，發送狀態資訊(Gossip)
    B->>B: 2. 合併接收到的狀態與自身狀態
    B->>D: 3. 隨機選擇節點D，轉發合併後的狀態
    D->>D: 合併狀態
    A->>C: 4. 下一輪：節點A 隨機選擇節點C
    C->>C: 合併狀態
    D->>C: 5. 節點D 隨機選擇節點C，轉發狀態
    C->>B: 6. 節點C 隨機選擇節點B，轉發狀態
    Note over A,D: 最終所有節點收斂到相同的狀態視圖(Eventual Consistency)

八卦協定的名稱來源於其運作方式類似於人們之間傳播八卦的過程 – 每個人告訴少數幾個人，消息就會逐漸擴散到整個群體。

範例#

  • Dynamo 和 Cassandra 使用八卦協定來追蹤叢集中節點的狀態、可達性（Reachability）、金鑰範圍（Key Ranges）等資訊。

Phi 累積故障偵測（Phi Accrual Failure Detection）#

背景#

準確偵測故障是一個困難的問題 – 我們無法以 100% 的確定性判斷一個系統是否已經停機，還是只是回應緩慢。

傳統的心跳機制使用固定逾時（Fixed Timeout）輸出布林值結果（存活或未存活）：

  • 短逾時：偵測速度快，但容易產生大量誤報（False Positive）
  • 長逾時：誤報較少，但偵測速度慢

固定逾時的兩難困境促使了自適應故障偵測方法的發展，能夠根據實際網路狀況動態調整判斷標準。

定義#

Phi 累積故障偵測器（Phi Accrual Failure Detector）是一種自適應故障偵測（Adaptive Failure Detection）機制。它利用歷史心跳資訊來建立自適應閾值，輸出的不是簡單的布林值，而是一個懷疑程度（Suspicion Level）。

解決方案#

Phi 累積故障偵測器的運作方式：

  • 基於歷史心跳到達的時間間隔，建立一個統計模型
  • 若節點未回應，懷疑程度會持續上升
  • 系統可以根據懷疑程度逐步減少向該節點發送的請求
  • 在正式宣告節點已停止運作之前，會考慮網路波動（Network Fluctuations）和間歇性問題（Intermittent Issues）
  • 不同的應用場景可以根據自身需求，選擇不同的懷疑程度閾值來做出決策

與傳統布林值判斷相比，Phi 累積故障偵測器提供了更細緻的故障判斷，讓系統能夠根據不同的懷疑程度採取不同的應對策略。

範例#

  • Cassandra 使用 Phi 累積故障偵測器來判斷叢集中節點的狀態，實現更精確且具備自適應能力的故障偵測。
Backward Bloom Filters Quorum Forward