Paxos vs Raft

wen IT资讯 2026-07-02 25

本文目录导读：

Paxos vs Raft

核心机制对比详解
为什么 Raft 更流行？
什么时候该用哪个？

这是一个非常经典的问题，Paxos 和 Raft 都是用于解决分布式一致性问题的共识算法，它们的核心目标相同：在一个由多个节点组成的分布式系统中，即使部分节点出现故障（如宕机、网络分区），也能保证整个系统就某个值（例如日志条目、配置信息）达成一致。

Paxos 是理论上的“祖师爷”，而 Raft 是工程上的“优等生”。

下面从几个关键维度进行对比：

特性	Paxos	Raft
设计哲学	极度精简，追求理论上的普适性和正确性。	以可理解性为首要目标，易于实现和教学。
核心概念	提案者 (Proposer)、接受者 (Acceptor)、学习者 (Learner)。	领导者 (Leader)、追随者 (Follower)、候选者 (Candidate)。
角色关系	多个 Proposer 可以同时发起提案，角色是松耦合的。	系统有一个强领导者负责处理所有写入请求。
选举过程	没有显式的领导者选举机制，靠多轮提案竞争。	有明确的、基于超时机制的领导者选举（Leader Election）。
日志复制	通过两阶段提交（Prepare/Promise 和 Accept/Accepted）实现。	通过领导者单向追加日志（Append Entries）并复制到 Follower。
处理冲突	复杂，需要处理多个 Proposer 同时提案导致的活锁问题。	简单，领导者是唯一写入源，通过“前任领导者的日志不会变”的原则简化冲突处理。
算法复杂度	非常高，难以理解和实现（特别是 Multi-Paxos）。	相对较低，被称为“为了可理解性而设计的 Paxos 变体”。
工程实现	较少直接使用原始 Paxos，多为变体（如 Multi-Paxos, Fast Paxos）。	极其广泛，是许多现代分布式系统的首选共识算法（如 etcd, Consul, TiKV）。

核心机制对比详解

角色与领导者

Paxos：
- 没有固定的“领导”角色，任何节点（Proposer）都可以发起提案。
- 这导致一个问题：如果多个 Proposer 同时发起提案，可能会互相否决，形成活锁（Livelock）,永远无法达成一致。
- Multi-Paxos 的改进：选举一个“主 Proposer”（Distinguished Proposer），让其作为事实上的领导者，来避免活锁，但这本质上是在 Paxos 框架内手动添加了一个接近 Raft 的Leader概念,但实现细节和证明仍然复杂。
Raft：
- 设计的核心就是强领导者模型。
- 通过随机超时机制，让一个 Follower 先成为 Candidate，再通过获得多数投票成为 Leader。
- 所有写操作（客户端请求、日志复制）都必须经过 Leader，这极大地简化了算法流程,因为同一时刻几乎只有一个节点在主导决策。

日志复制流程

Paxos (经典 Basic Paxos)：
1. Phase 1 (Prepare): Proposer 发 Prepare(n) 给 Acceptors，n 是提案编号（全局唯一且递增）。
2. Phase 1 (Promise): Acceptor 承诺不接收编号小于 n 的提案,并回复它已接受的最大提案编号和值。
3. Phase 2 (Accept): Proposer 根据多数 Promise 回复，决定要提交的值（可能是自己提出的，也可能从上一步中得知的已接受的最大值），然后发送 Accept(n, value) 给 Acceptors。
4. Phase 2 (Accepted): Acceptor 接受该提案,除非它已经承诺了更大的编号。
这个流程非常严谨，但每个提案都需要两轮网络通信，延迟高，且需要编号管理。
Raft：
1. Append Entries: Leader 收到客户端请求后,将日志条目追加到自己的日志中。
2. 复制: Leader 并行地发送 AppendEntries RPC 给所有 Follower。
3. 提交: 当 Leader 收到多数 Follower（包括自己）的确认后，即可在本地提交该日志条目，并通知客户端成功，下次心跳或新的 AppendEntries RPC 会携带提交信息告诉 Follower。
流程是线性、一次性的（不需要 Prepare 阶段），因为 Leader 可以保证自己当前的日志版本是最新的，并且没有冲突。

处理冲突与安全性

Paxos：安全性是通过严格的数学证明（Quorum 的交集性质）保证的，两个不同编号的提案不可能被同时接受，但处理复杂的网络分区和节点宕机后,要手动推理日志的覆盖和补偿逻辑很困难。
Raft：引入了日志匹配特性和选举限制：
- 日志匹配：Leader 在选举时，会要求 Candidate 的日志不能比自己旧，这保证了新选出的 Leader 拥有所有已提交的日志,从而不会覆盖已提交的条目。
- 日志不一致处理：当 Follower 日志与 Leader 不一致（比如旧 Leader 崩溃后，新 Leader 发现Follower有自己未记录的条目）时，Leader 会强制让 Follower 删除冲突部分，并用自己的日志覆盖，这种“强行覆盖”的策略是简单且正确的，而 Paxos 需要更复杂的补偿机制。

为什么 Raft 更流行？

教学与理解成本低：Raft 把算法分解成了几个相对独立的子问题：领导者选举、日志复制、安全性，每个部分都可以单独学习和理解，学生和工程师能在几小时内理解 Raft 的核心原理，而 Paxos 可能需要几周。
工程实现确定性更强：Raft 的流程非常固定：只有一个Leader，写操作必须经过Leader，日志只在Leader处追加，不容易出现 Paxos 中的活锁、需要处理多个 Proposer 的并发难题。
工业界接受度极高：etcd (Kubernetes 的存储后端)、Consul、TiDB/TiKV 都使用 Raft 或 Raft 的修改版，这让它成为了实际上的“事实标准”。
完备的工程化：Raft 论文（《In Search of an Understandable Consensus Algorithm》）除了算法本身，还详细讨论了集群成员变更、日志压缩、快照等生产环境的必备机制，而 Paxos 论文（《The Part-Time Parliament》）对此笔力极少。

什么时候该用哪个？

如果你在寻找一个可靠、主流、易于实现的共识算法：选 Raft，这是现在绝大多数应用场景的首选，它的理解成本低，社区支持（库、实现参考）非常丰富。
如果你在研究共识理论、证明、或需要极致的理论灵活性：学习 Paxos，Paxos 的模型更抽象，其 Quorum 理论（不需要严格 Majority，可以进行优化如 Fast Paxos、Byzantine Paxos 等）是基础，一些高度定制化的场景，比如需要支持跨数据中心、极低延迟但不强求一致性模型时，Paxos 的变体仍有价值（如 Google 的 Spanner 使用 Paxos）。
特殊场景：
- 如果系统内节点经常宕机且需要快速恢复，Raft 的选举机制（超时重选）表现得很好。
- 如果你需要支持非对称的 Quorum（可以在 3 个节点中任意 2 个达成一致，这是 Raft 和 Basic Paxos 都支持的，但 Paxos 的理论允许更灵活的组合，Fast Paxos 通过增大 Quorum 降低时延）。
- 如果你需要一个去中心化（没有明确 Leader）的共识模型（虽然 Raft 也是去中心的，但有强 Leader），Paxos 的“多 Proposer”模式更适合这个想法,但很难用好。

一句话总结： 如果你是一个分布式系统工程师，需要构建一个可靠的分布式数据库、集群协调器或共识状态机，默认选择 Raft，它足够可靠、清晰、有大量现成实现供参考，而去深入理解 Paxos，会让你对 Raft 的设计选择有更深的理解，并在需要处理极端场景（如拜占庭容错、成员变更优化）时提供理论武器。