引言
在分布式系统中，数据一致性是核心挑战。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 通过明确角色和任期机制，大幅降低分布式一致性实现难度。
- 强一致性：通过多数派提交和日志匹配原则，确保系统状态严格一致。
- 适用场景：适合需要强一致性的系统（如配置中心、分布式锁服务）。
