Raft 一致性演算法

引言：「共享真理」的問題

在分散式集群中，即使部分伺服器宕機或網路延遲，我們如何確保所有伺服器對同一個值（例如「目前的配置是 X」）達成一致？

多年來，Paxos 是唯一的答案，但她以晦澀難懂和難以實現而著稱。2013 年，Raft 作為一種更簡單的替代方案被提出。她將複雜的一致性問題拆解為三個清晰的子問題：領導者選舉 (Leader Election)、日誌複製 (Log Replication) 和 安全性 (Safety)。

演算法要解決什麼問題？

• 輸入： 來自用戶端的一系列指令（日誌）。
• 輸出： 在所有健康節點上保持一致的、同步的日誌副本。
• 承諾： 集群表現得像一台單一、可靠的狀態機。只要大多數節點（法定人數 Quorum）存活，系統就能繼續工作。

核心思想 (直覺版)

Raft 就像一個 議會制 系統：

1. 唯一的領導者： 只有領導者能接受用戶端的新指令。
2. 跟隨者的職責： 跟隨者只需複製領導者發送給她的內容。
3. 任期與選舉： 如果領導者停止發送「心跳」，跟隨者就會變成候選人並開始選舉。每次選舉都在一個「任期 (Term)」內進行。

黃金法則：「領導者總是正確的。」 但要成為領導者，你必須證明你擁有最新、最全的日誌。

演算法是如何工作的？

1. 領導者選舉

• 節點初始狀態為 跟隨者 (Follower)。
• 如果跟隨者在隨機超時時間內沒收到心跳，她就變成 候選人 (Candidate)。
• 她向其他節點拉票。如果獲得 半數以上 的投票（例如 5 台中的 3 台），她就成為 領導者 (Leader)。

2. 日誌複製

• 用戶端發送指令給領導者。
• 領導者將其寫入日誌，並發送給所有跟隨者。
• 一旦 大多數 跟隨者確認寫入，領導者就「提交」該指令，並通知跟隨者也提交。

3. 安全性

• Raft 確保如果一條指令已被提交，她就永遠不會丟失，也不會被未來的領導者覆蓋。

典型業務場景

• ✅ 服務發現與元數據： etcd（Kubernetes 的核心）使用 Raft 儲存集群元數據。

• ✅ 分散式資料庫： CockroachDB 和 TiDB 使用 Raft 確保不同數據中心之間的數據一致性。

• ✅ 配置管理： 儲存必須在所有伺服器上保持完全一致的全局配置或金鑰。

• ❌ 極高寫入性能需求： Raft 的每次寫入都需要大多數節點確認，這會增加網路延遲。如果追求極致速度而不在乎強一致性，請考慮 Gossip 協定 或 最終一致性資料庫。

性能與複雜度總結

• 可用性： 必須有 $N/2 + 1$ 個節點存活。
• 延遲： 每次寫入至少需要一次到大多數節點的往返通訊。

小結：一句話記住它

「Raft 是『以人為本』的共識演算法。透過選舉強有力的領導者並遵循少數服從多數的原則，她確保了集群始終共享唯一的真理。」