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，就接受该提案。

优缺点分析

🚣 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 vs Raft

把它们放在一起对比：

💡 总结建议

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

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