引言：为什么需要共识算法？
在分布式系统中，多个节点如何就某个值达成一致？这是计算机科学中最基础也最困难的问题之一。当你的数据库有三个副本，客户端写入其中一个后突然断网，另外两个副本应该如何响应？当一个 Leader 宕机，谁应该接管？这些问题的答案，正是共识算法要解决的。
Paxos 是这个领域的第一个实用解决方䅁，但因其实现复杂、难以理解而长期停留在论文层面。直到 2014 年 Diego Ongaro 和 John Ousterhout 提出 Raft，才让共识算法真正走进了生产系统 —— etcd、Consul、TiKV、CockroachDB 等核心基础设施都将 Raft 作为底层共识引擎。
Raft 的设计哲学：可理解性优先
Raft 的核心设计目标不是性能最优，而是可理解性（Understandability）。Ongaro 认为，工程师只有真正理解一个算法，才能正确实现和维护它。为此， Raft 采用了两个关键策略：
- 问题分解：将共识问题拆分为 Leader 选举、日志复制和安全性三个独立子问题
- 状态简化：减少系统中的不确定性和随机性，使状态转换更清晰
这种"工程优先"的设计理念，直接决定了 Raft 在工业界的广泛采用。
核心概念与状态机模型
Raft 集群中的每个节点在任何时刻处于三种状态之一：
| 状态 | 职责 |
|---|---|
| Leader | 处理所有客户端请求，复制日志到 Follower，发送心跳维持权威 |
| Follower | 被动响应 Leader 和 Candidate 的请求，若超时则转为 Candidate |
| Candidate | 发起投票请求，争取多数票以成为新 Leader |
每个节点维护三个关键持久化状态：currentTerm（当前任期号）、votedFor（本任期投票给谁）、log[]（日志条目数组）。其中 currentTerm 和 votedFor 必须在响应 RPC 之前写入持久存储，这保证了即使节点崩溃重启后也不会丢失关键投票信息。
Phase 1：Leader 选举与_term机制
Raft 将时间划分为不定长度的任期（Term），每个 Term 从选举开始。任期号是单调递增的全局标识，节点每次通信都会携带自己的任期号。当节点发现自己的任期号小于对方时，立即更新到自己的编号并退化为 Follower。
选举触发与投票规则
Follower 在选举超时（Election Timeout，通常 150-300ms）内未收到 Leader 的心跳，就会转为 Candidate 并发起投票：
- 自增 currentTerm
- 投票给自己
- 重置选举定时器
- 向所有其他节点发送 RequestVote RPC
每个节点在每个 Term 内最多投一票（先来先服务原则）。候选人要成为 Leader 必须获得集群多数票（Majority）。
安全性保障：日志完整性检查
仅有多数票还不够，Raft 通过日志比较规则保证新 Leader 包含所有已提交的日志条目：候选人必须证明自己的日志至少跟投票者一样新。具体比较规则是——先比较最后一条日志的 Term，Term 大的更新；Term 相同时，日志长度更长的更新。
分裂问题与随机超时
如果多个 Follower 同时超时转为 Candidate，可能出现"票数分裂"无人当选的情况。Raft 的解决方案是：每个节点在 [150ms, 300ms] 区间内随机选取选举超时时间。这样，节点超时的时间点被分散开，极大降低了分裂概率。即使发生分裂，也会在下一轮很快选出 Leader。
Phase 2：日志复制与一致性保证
Leader 当选后开始接受客户端的写请求。每个写请求被封装为一条日志条目，经历以下生命周期的：
复制流程
- Leader 将日志追加到自己的本地日志
- 并行向所有 Follower 发送 AppendEntries RPC
- Follower 验证日志一致性检查（prevLogIndex/prevLogTerm） 多数 Follower 成功后，Leader 将该日志标记为已提交（Committed）
- Leader 应用已提交日志到状态机，返回结果给客户端
- Followers 在下次心跳时获知新的 commitIndex，各自应用到自己的状态机
日志匹配特性与冲突解决
Raft 保证两条核心不变性：（1）如果两个日志条目有相同的 Index 和 Term，它们存储相同的命令；（2）如果两个日志条目有相同的 Index 和 Term，之前的所有条目都相同。
当 Follower 收到 AppendEntries 发现 prevLogIndex/prevLogTerm 不匹配时，拒绝此次 RPC。Leader 的处理方式是递减 nextIndex 重试，直到找到最后一个一致的日志点，然后用 Leader 的日志覆盖 Follower 的冲突部分。这个过程保证了最终所有节点的日志与 Leader 完全一致。
Phase 3：安全性约束与工程陷阱
上述机制看起来已经足够，但在 Leader 变更场景下存在微妙的已提交日志丢失风险。
Leader 完整性限制
Raft 论文中的关键洞察：Leader 的日志不可能比多数节点少。因为 Leader 当选需要多数投票，而投票规则保证其日志至少与投票者一样新。
但有一个边界情况：旧 Leader 在 Term T 提交了一条日志到新 Leader 的部分节点，但新 Leader 的 Term T+1 并没有包含这条日志。新 Leader 当选后用自己的日志覆盖，就会导致已提交日志丢失。
解决方案：Term T+1 的 Leader 在当选后立即提交一条空操作（No-op）日志。这条日志的 Term 是 T+1，由于所有 Term ≤ T 的日志必须在多数派中被确认，这就间接确认了所有 Term ≤ T 的日志。从而保证了安全性。
只读操作的线性一致性
只读请求看似简单（直接从 Leader 读状态机即可），但在 Leader 变更时可能导致过期读（Stale Read）——新 Leader 可能尚未得知某些日志已提交。解决方案：Leader 在处理只读请求之前，先在当前 Term 提交一条 No-op 日志，确认自己的领导权。
工程实践：从理论到生产
预写日志与持久化
生产环境中， WAL（Write-Ahead Log）的性能直接影响 Raft 的吞吐量。建议使用 io_uring（Linux）或批量提交策略减少 fsync 调用。etcd 将LogEntry 序列化后直接写入 WAL，RocksDB 作为状态机后端。
集群成员变更
Raft 支持联合共识（Joint Consensus）的成员变更：在过渡期同时使用新旧两个配置，所有决策需要两个配置的多数派共同批准。这避免了单节点变更期间的"双 Leader"问题。etcd 进一步实现了更高效的单节点步进变更作为优化。
快照与日志压缩
随着运行日志无限增长，Raft 支持快照机制：Leader 定期将已提交日志对应的状态机进行快照，连同最后的日志 Index 和 Term 一并发送给落后的 Follower。Follower 收到快照后，丢弃所有早于快照的日志，将状态机恢复到快照点。
性能调优与常见参数
| 参数 | 推荐值 | 说明 |
|---|---|---|
| Heartbeat Interval | 1-5ms | Leader 心跳间隔，影响故障检测速度 |
| Election Timeout | 150-300ms (随机) | Follower 等待心跳超时 |
| Max Batch Size | 1024 entries | 单次 AppendEntries 最大日志数 |
| Snapshot Min Count | 10000 entries | 触发快照压缩的日志阈值 |
复制管道化（Pipeline）
在高延迟网络环境下，逐条 RPC 的 AppendEntries 效率极低。Raft 工程实现可参考长轮询或管道化复制模式：Leader 连续发送 AppendEntries RPC，不等上一个返回就发下一个，同时维护 nextIndex 的乐观更新。但需注意 Leader 变更时必须回退 nextIndex，处理潜在冲突。
与 Paxos 的对比
| 维度 | Raft | Multi-Paxos |
|---|---|---|
| 可理解性 | 高，论文即实现 | 低，"谜题"式理解 |
| 成员变更 | 联合共识，标准形式 | 各自实现差异大 |
| Leader 选举 | 内置，统一模型 | 需额外实现（如 Chubby 的 Master Lease） |
| 日志提交 | 简单多数 | 灵活，但易引入边缘 Bug |
| 工业应用 | etcd, TiKV, Consul | Chubby, Spanner(内部) |
结语
Raft 的成功告诉我们：在系统设计中，可理解性往往比理论完美性更有价值。一个工程师能在脑中完整推演状态机的算法，远比一个性能优越但存在隐蔽边界条件的算法更适合生产环境。理解 Raft 不仅是掌握一个共识算法，更是学习如何在分布式系统中设计"正确"的失败处理路径。
正如 Ongaro 本人在论文中所写的："Paxos has a reputation for being difficult to implement... Raft was designed to be a better-structured alternative." 在构建可靠分布式系统的路上，Raft 是每个后端工程师的必修课。
发表评论 取消回复