分布式系统 Raft 一致性算法：从理论到工程落地

引言

在分布式系统中，多节点之间如何就某个值达成一致，是构建可靠系统的基石。Paxos 算法虽然理论上正确，但其理解难度和实现复杂度成为工程落地的巨大障碍。2014 年，Raft 算法应运而生，以"可理解性（Understandability）"为核心设计目标，成为当今最广泛采用的共识算法之一。

一、Raft 的设计哲学

Raft 将共识问题分解为三个相对独立的子问题：领导选举（Leader Election）、日志复制（Log Replication）和安全性（Safety）。这种分解大大降低了算法的理解难度。

Raft 使用"强领导者"（Strong Leader）模型：所有日志条目只能从领导者发送给其他服务器。领导者从不覆盖或删除自己的日志，只进行追加操作。

二、状态与术语

Raft 中每个节点可能处于三种状态之一：

• Leader（领导者）：处理所有客户端请求，定期发送心跳维持领导地位
• Follower（跟随者）：被动响应来自 Leader 和 Candidate 的请求
• Candidate（候选人）：用于选举新的 Leader，当 Follower 超时未收到心跳时进入此状态

时间被划分为任意长度的 Term（任期），每个 Term 是一个连续递增的数字。每个节点记录当前 Term，RPC 通信时携带 Term 信息。Term 本质上是逻辑时钟，用于检测过期的信息。

三、领导选举机制

Leader 通过定期发送心跳（AppendEntries RPC，不包含日志条目）维持其领导地位。如果 Follower 在选举超时时间（通常 150-300ms）内未收到心跳，它就假设 Leader 已故障，开始新一轮选举：

1. 增加当前 Term，切换到 Candidate 状态

2. 投票给自己

3. 向其他节点发送 RequestVote RPC

4. 等待结果，可能产生三种 outcomes：获得大多数选票成为 Leader；收到 Leader 的 AppendEntries 退回 Follower；超时后 Term 内无结果，开始下一轮选举。

为了确保选举安全，Raft 的投票规则保证：每个 Term 中每个节点最多投一票，且只有当候选人的日志至少和自己一样新时才投票。

四、日志复制流程

当选出 Leader 后，系统对外提供服务。日志复制的核心流程：

1. 客户端向 Leader 发送写请求

2. Leader 将操作追加为日志条目，此时条目处于未提交状态

3. Leader 通过 AppendEntries RPC 并行向所有 Follower 复制该条目

4. Leader 收到大多数节点的确认后，提交该条目并应用到状态机

5. 向客户端返回执行结果

Leader 维护每个 Follower 的 nextIndex 和 matchIndex，高效追踪复制进度。当 AppendEntries 因日志不一致而失败时，Leader 回退 nextIndex 重试。

五、安全性保证

Raft 的关键安全性规则——选举限制：Leader 必须包含之前所有 Term 的所有已提交条目。这意味着：

日志条目只从 Leader 流向 Follower，Leader 从不覆盖已有日志；要成为 Leader 的候选人，其日志必须包含所有已提交条目（通过 RequestVote RPC 中的日志信息判断）。

另一个关键是提交规则：Leader 不能通过计算副本数的方式提交之前 Term 的日志条目，只能通过提交当前 Term 的日志条目来间接提交之前的条目。这一限制避免了"已提交日志被覆盖"的情况。

六、成员变更与日志压缩

成员变更：直接切换节点集合可能导致脑裂（多个 Leader 同时存在）。Raft 使用联合共识（Joint Consensus）方案——在过渡期间需要新旧两个配置的多数派同意。实际工程中，通常采用更简单的单节点变更一次逐一增减节点。

日志压缩：长时间运行的系统中，日志会无限增长。Raft 使用快照（Snapshot）机制解决此问题：将系统状态和最后已提交日志的元数据打包为快照节点，丢弃之前的日志条目。InstallSnapshot RPC 用于向落后领导者传输快照。

七、业界实现与工程实践

• etcd：Kubernetes 的核心存储，使用 Go 语言实现 Raft
• TiKV：TiDB 的分布式 KV 存储引擎，使用 Rust 实现 Multi-Raft
• Consul：HashiCorp 的服务发现与配置管理工具
• NATS Streaming：基于 Raft 的消息系统

工程实践中的关键优化：批量写入减少 RPC 开销、流水线复制保持 Leader 始终忙碌、Pre-Vote 机制避免网络分区节点频繁发起选举、Lease Read 减少读请求的开销。

八、总结

Raft 通过将共识问题分解为领导选举、日志复制和安全性三个子问题，提供了一种比 Paxos 更易理解和实现的方案。其强领导者模型简化了复制流程，选举限制和提交规则确保了系统的强一致性。理解 Raft 的核心机制，是构建可靠分布式系统的必备基础。