paxos and raft (分布式一致性算法)

Paxos 和 Raft 是分布式系统中解决共识问题（Consensus Problem）的两个最核心算法。简单来说，它们的目标是让分布式集群中的多个节点，在面对网络延迟、丢包或节点宕机的情况下，依然能对某个数据（比如“谁当老大”或“下一条日志是什么”）达成一致。

如果把分布式系统比作一个团队，这两个协议就是团队的决策机制。

下面详细介绍这两个协议及其优缺点。

---

🏛️ Paxos：理论界的“九阳神功”

Paxos 由 Leslie Lamport（2013 年图灵奖得主）在 1990 年提出。它是分布式一致性领域的理论基石，后续的很多协议（包括 Raft）都深受其影响。

核心原理

Paxos 的核心思想是“少数服从多数”。只要集群中超过半数（$N/2 + 1$）的节点存活并达成一致，系统就能正常工作。

它定义了三种角色：

1. Proposer（提议者）：提出提案（比如“我建议把值设为 X”）。
2. Acceptor（接受者）：投票决定是否接受提案。
3. Learner（学习者）：学习最终被选定的值（通常不参与投票，只负责同步数据）。

基本流程（两阶段提交）：

1. Prepare 阶段：Proposer 生成一个全局唯一的递增编号 $N$，向多数派 Acceptor 发送 Prepare(N)。Acceptor 如果承诺不接受更小编号的提案，就会回复“承诺”以及它之前接受过的最大编号的提案值。
2. Accept 阶段：Proposer 收到多数派的承诺后，发送 Accept(N, V)。这里的 $V$ 很关键：如果 Acceptor 返回了之前接受过的值，Proposer 必须使用那个值；如果没有，才能用自己的值。Acceptor 收到后如果没收到更大编号的 Prepare，就接受该提案。

优缺点分析

维度	优点	缺点
理论性	极其严谨。有严格的数学证明，安全性（Safety）无懈可击。	晦涩难懂。Lamport 的论文以“难读”著称，被称为“像天书一样”。
容错性	极强。只要半数以上节点存活，就能保证一致性。	活锁问题。在 Basic Paxos 中，如果多个 Proposer 竞争，可能互相抬高编号，导致谁都提交不成功。
工程落地	是 Google Chubby、Spanner 等系统的理论基础。	实现极难。从理论到代码有巨大的鸿沟，容易写出 Bug。工业界通常使用 Multi-Paxos（引入 Leader 优化）。

---

🚣 Raft：工程界的“屠龙刀”

Raft 诞生于 2013 年，作者 Diego Ongaro 和 John Ousterhout 的目标非常明确：设计一个易于理解的共识算法。

Raft 认为 Paxos 太难懂，不利于工程实现。因此，Raft 将共识问题拆解为三个独立的子问题：领导者选举、日志复制和安全性。

核心原理

Raft 采用强领导者模型，所有决策都由 Leader 拍板。

它定义了三种角色（节点在任何时刻只能是其中之一）：

1. Leader（领导者）：唯一的提案者，处理所有客户端请求，复制日志给 Follower。
2. Follower（追随者）：被动接收 Leader 的指令，参与投票。
3. Candidate（候选人）：选举期间的临时角色。

关键机制：

• 任期（Term）：逻辑时钟，每次选举 Term 加 1。
• 领导者选举：Follower 如果长时间（随机 150-300ms）没收到 Leader 心跳，就变成 Candidate，发起投票。获得半数票的成为新 Leader。
• 日志复制：Leader 将日志发给 Follower，超过半数写入成功后，日志即被提交（Committed）。

优缺点分析

维度	优点	缺点
可理解性	极高。逻辑清晰，模块化设计，普通程序员也能看懂。	相比 Paxos，理论抽象度稍低（但这正是它的设计目标）。
性能	高。强 Leader 模型减少了竞争，稳定时只需一次 RPC 即可复制日志。	写性能瓶颈。所有写请求必须经过 Leader，Leader 成为吞吐量上限。
工程落地	非常广泛。Etcd (K8s核心)、Consul、TiKV 等都使用 Raft。	脑裂风险。网络分区时可能出现双 Leader，但 Raft 能保证旧 Leader 无法写入（牺牲可用性保一致性）。

---

⚔️ 终极对比：Paxos vs Raft

把它们放在一起对比：

特性	Paxos (Multi-Paxos)	Raft
核心理念	灵活。节点角色不固定，任何节点都可以提议。	集权。强 Leader 模型，只有 Leader 能提议。
理解难度	⭐⭐⭐⭐⭐ (困难模式)	⭐ (简单模式)
实现难度	高。需要处理复杂的活锁和竞争。	中。有明确的伪代码和状态机。
适用场景	对理论要求极高，或需要极度定制化的场景（如 Google 内部系统）。	现代分布式系统的首选，特别是需要快速落地和维护的场景（如云原生组件）。

💡 总结建议

• 如果做学术研究，或者想深入理解分布式一致性的数学本质，Paxos 是必修课。
• 如果是工程师，需要构建一个高可用的分布式存储或协调服务（比如用 Go 写一个配置中心），Raft 绝对是更好的选择。它的生态更丰富（如 hashicorp/raft 或 etcd/raft 库），遇到问题也更容易排查。

简单来说：Paxos 是内功心法，Raft 是实战剑谱。