引言
在分布式系統中，數據一致性是核心挑戰。Raft 協議作為一種易于理解的一致性算法，被廣泛應用于 etcd、Consul 等系統中。
一、Raft 核心概念
1.1 角色與任期（Term）
? 領導者（Leader）：處理所有客戶端請求，管理日志復制。
? 跟隨者（Follower）：被動響應領導者的心跳和日志條目。
? 候選人（Candidate）：在領導者失效時發起選舉。
? 任期（Term）：邏輯時鐘，用于檢測過期的請求。
1.2 日志結構
? 日志條目（Log Entry）：包含命令、任期號和索引。
? 日志匹配原則：若兩個日志條目索引相同且任期相同，則后續條目也一致。
二、領導者選舉流程
2.1 選舉觸發條件
? 心跳超時：跟隨者未在 election timeout（通常 150-300ms）內收到領導者心跳，則轉為候選人。
? 自增任期號：候選人發起選舉時遞增當前任期號。
2.2 選舉過程時序
2.3 選舉超時隨機化
? 避免分割投票：每個節點的超時時間隨機化（150-300ms），減少多個候選人同時競選。
三、日志復制機制
3.1 日志追加流程
3.2 日志一致性規則
- 匹配原則：若索引
i的日志條目在多數節點存在且任期一致，則視為已提交。 - 提交規則：領導者只能提交當前任期的日志，舊任期日志需通過新日志間接提交。
四、安全性保障
4.1 領導者完整性
? 日志匹配檢查：候選人在選舉時需攜帶最新日志索引和任期，跟隨者拒絕日志落后的請求。
4.2 選舉限制
? 任期號校驗：節點拒絕來自舊任期的請求（如 Term=2 請求在 Term=3 時被丟棄）。
4.3 網絡分區容錯
五、Raft 與 Paxos 對比
| 特性 | Raft | Paxos |
|---|---|---|
| 設計目標 | 易于理解和實現 | 理論完備性 |
| 角色劃分 | 明確的三角色模型 | 多角色（Proposer/Acceptor/Learner） |
| 日志復制 | 單領導者線性化復制 | 多領導者并行復制 |
| 學習曲線 | 低（狀態機清晰） | 高（多階段提案機制） |
六、實戰應用場景
6.1 etcd 中的 Raft 實現
? 元數據管理：通過 Raft 同步集群節點狀態。
? 鍵值存儲：客戶端請求經 Raft 提交后持久化。
6.2 容錯與恢復
? 節點宕機：領導者持續發送心跳，超時后觸發新一輪選舉。
? 日志恢復：新加入節點通過快照（Snapshot）和日志同步補全數據。
七、總結與延伸
核心結論
- 易用性：Raft 通過明確角色和任期機制，大幅降低分布式一致性實現難度。
- 強一致性：通過多數派提交和日志匹配原則，確保系統狀態嚴格一致。
- 適用場景：適合需要強一致性的系統（如配置中心、分布式鎖服務）。
