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 是‘以人为本’的共识算法。通过选举强有力的领导者并遵循少数服从多数的原则，它确保了集群始终共享唯一的真理。”