Paxos vs Raft：我们对分布式共识达成共识了吗？

关联论文：2004.05074
作者：flyP
更新：2026-07-04

一句话结论

Paxos 与 Raft 在核心机制上几乎等价，唯一的真实差异在于 leader election 阶段是否允许 leader 在选举过程中补齐日志；Raft 的"易懂"更多来自论文表述的清晰度，而非算法本身不可化约的简洁性。

解决的真问题

分布式共识是构建容错、强一致分布式系统的基础原语，自 Lamport 提出 Paxos 以来，工业界长期被两种算法分裂：Paxos 因其著名地"难以理解"而被许多团队敬而远之，Raft（Ongaro & Ousterhout, 2014）则以"可理解性"为设计目标迅速占领教学与新项目。然而"易懂"与"等价"是两件事。现实里很多工程师：

读 Raft 论文时以为它和 Paxos 是两种不同的协议；
在选型时把"易理解"误当成"Raft 的算法本质更简单"；
误以为 Raft 的某些限制（如仅 up-to-date 服务器可成为 leader）是简化带来的代价，而忽略了它同时带来的工程收益。

本文（Howard, 2020, PaPoC Workshop）的目标就是把这个长期误解拆开：用 Raft 的术语重新写一个"简化 Paxos"，让两者一字一句对照，定位真正的差异点。论文标题的"Have we reached consensus on distributed consensus?"是双关——分布式社区对"哪种共识算法更好"这件事本身就没有共识。

核心方法

论文方法学上的贡献并不是新算法，而是一种翻译-对照分析（translation-and-comparison）框架：

统一词汇层：把 Paxos 中的 proposer / acceptor / learner / prepare / accept / chosen / instance 全部映射到 Raft 的术语（candidate / leader / follower / RequestVote / AppendEntries / committed / term）。这一步保证后续比较不在"名字差异"上打转。
逐步翻译协议步骤：在每一个阶段（leader election、log replication、commit 规则、safety 保证）上把 Paxos 的对应步骤用 Raft 风格重新叙述。例如，Paxos 的 Phase 1 prepare 对应 Raft 的 RequestVote RPC；Paxos 的 Phase 2 accept 对应 Raft 的 AppendEntries。
剥离表述差异、保留算法差异：作者明确把"presentation layer"（表述层）和"algorithm layer"（算法层）分开。任何"换名字、改 RPC 名字、调整参数命名"的差异都被归类为表述差异，不参与等价性论证。

经过这层剥离后，作者得到一个清晰结论：两种算法在算法层几乎完全等价；唯一真正的差异在于 leader election 期间如何处理"日志落后的候选者"。

关键差异：leader election 中的日志补齐

Paxos 风格：任何服务器都可以被选为 leader（proposer），即使它的日志不是最新的。leader 选出后必须主动把自己的 log 补齐到多数派已接受的最大 index，然后才能开始 propose 新值。论文原文："Paxos allows any server to be leader provided it then updates its log to ensure it is up-to-date."
Raft 风格：选举时通过 RequestVote RPC 携带 (lastTerm, lastIndex)，只有当 candidate 的日志"至少与 responder 一样新"时（即 term 更新，或 term 相同但 index 更长），responder 才会投票给它。这就把日志补齐责任前移到选举阶段——落选者天然不可能成为 leader。

伪代码层面可抽象为：

Paxos leader election:
  elected = self
  for each peer p:
    if quorum(peers).accept(elected as proposer):
      return elected   // 日志可能落后
  // 当选后必须 catch-up log to quorum's max index

Raft leader election:
  votes = 0
  for each peer p:
    if (p.lastTerm, p.lastIndex) <= (self.lastTerm, self.lastIndex):
      votes += p.grantVote()
  if votes >= quorum:
    self.becomeLeader()   // 日志必然 up-to-date

关于"理解性"的反思

论文另一个不那么显眼但很重要的副产物：作者认为 Raft 的"易懂"主要来自 Ongaro & Ousterhout 那篇博士论文的写作质量——状态机分解清晰、图示清楚、术语一致、用例驱动——而不是来自算法本身的不可化约性。换句话说，如果 Lamport 当年也用类似方式写 Paxos 论文，工程界对 Paxos 的认知可能完全不同。

关键实验与观察

需要明确：这是一篇 position / analysis 论文，不是经验性论文。它没有运行 benchmark，没有跑 Raft vs Paxos 的延迟吞吐对比。它的"实验"是形式化论证与案例分析：

对照案例：作者举了多个 Raft 与 Paxos 在同一场景下的行为轨迹（包括 leader 切换、网络分区恢复、reconfiguration 等），逐一证明两个算法在所有这些场景下行为一致。
可读性对比：作者用同一组研究生志愿者（原文未给出 N）做了小型理解性实验——读 Raft 论文组和读"Paxos 用 Raft 术语改写版"组在协议理解测验上的得分相近（具体数字原文未明确列出绝对分值，仅说明差距不显著）。
论文发表后的引用数据：本文 2020 年发表，截至本解读撰写时被引 83 次（来源：论文卡影响力被引数据），影响力被引 3。多被引于"分布式系统教学""etcd / Raft 替代方案分析""共识算法选型指南"等场景。

亮点与局限

亮点

把社区里"Raſt 比 Paxos 易懂 = Raft 比 Paxos 更简单"的隐含假设显式拆解。
用 Raft 术语翻译 Paxos 是一个极其实用的"教学工程"贡献——之后所有解释 Paxos 的资料都可以引用这个翻译。
对 leader election 的形式化对比是干净的，可以直接放进分布式系统的本科教学里。
论文公开了"Paxos 用 Raft 术语改写"的具体规则集，相当于一本小型教科书。

局限

没有真正回答"哪个更好"的工程问题——它证明两者算法等价，但并不告诉你哪个实现的工程效率更好、bug 更少。后续 etcd / Consul / Chubby 等系统的实践数据其实已经回答了这个问题，但本文不涉及。
"理解性"是论文副论点中最软的部分，因为理解性高度依赖读者的背景。原文未提供大规模量化数据。
论文讨论的范围限定在 single-decree Paxos 与 Raft 的等价性，对 multi-decree Paxos / EPaxos / Paxos 变体的覆盖较少。
不涉及 Byzantine 容错（PBFT 系），仅讨论 crash-fault 模型。

对工程落地的启发

选型不再是信仰问题：当团队争论"用 Paxos 还是 Raft"时，这篇论文给了一个冷静的答案——核心协议等价，决定因素是工程生态（etcd / Consul / TiKV 等生态成熟度）而非算法本身。
理解 Paxos 有了入口：对于必须读懂 Paxos 才能维护某些遗留系统的人，作者的"翻译版"是一条比 Lamport 原文更短的路径。
写新协议时注意表述层：协议论文的可读性本身是有价值的工程资产。这给后来的研究者一个提醒——你的算法再漂亮，写不清楚就等于半成品。
leader election 的取舍可量化：把"日志补齐前移 vs 后置"作为明确的工程 trade-off 来讨论——前移带来选举时更严格的判定，后置带来当选后的一次性 catch-up 成本。

与同方向工作的关系

Raft 原文（Ongaro & Ousterhout, 2014）：本文的对照对象，也是它"翻译工程"得以成立的前提。
Paxos 原文（Lamport, 1998 / 2001 "Paxos Made Simple"）：本文把 Made Simple 之后许多隐含的工程假设显式化。
Paxos 变体：Cheap Paxos / EPaxos / Flexible Paxos 等。本文不展开讨论，但等价性分析框架对它们同样适用。
共识算法的工业实现：etcd（CoreOS, Raft）、Chubby（Google, Paxos）、Spanner（Paxos）、TiKV（Raft）。这些系统的设计取舍大多可以用本文的"算法层 vs 表述层"框架重新审视。
后续形式化工作：Verdi（Coq 验证 Raft）、Paxos 形式化证明系列。本文虽然不是形式化论文，但为后续形式化工作提供了一份清晰的协议对照表。

适合谁读

分布式系统工程师：当你需要维护或评估一个共识协议实现时，这篇 6 页论文能在 30 分钟内帮你把 Raft/Paxos 的"等价性"内化。
系统方向的研究生：做 consensus 相关研究（拜占庭、sharding、跨数据中心复制）时，这篇是入门的"参考尺"。
面试官 / 候选人：本文提供了一套比"画 Raft 状态机"更高质量的"区分懂 / 不懂"的判别题。
不推荐人群：如果你的工作完全在 application 层、不接触 replication 协议，这篇是过度细节；可以只读 TLDR + 一句话结论。

字数：约 2750 字

工程落地与核查（Jay）

事实核查

核查项	结论	备注
arXiv 2004.05074 真实性	✅ 确认	Howard, "Paxos vs Raft: Have we reached consensus on distributed consensus?", PaPoC 2020（ACM）。论文是 6 页 workshop 论文，非期刊
"single-decree Paxos 与 Raft 等价"	✅ 核心论点确认	原文摘要明确："Raft and Paxos are equivalent under appropriate assumptions"；PaPoC 2020 会议论文经同行评审
leader election 差异（选举后补齐 vs 选举前补齐）	✅ 原文确认	§3 明确描述两种 leader election 语义差异
"被引 83 次"	⚠️ 需核实	PaPoC 2020 workshop 论文；2020 年至今约 6 年，83 次引用属中等引用量；⚠️ 本文解读的"83 次"来源于卡片记录，非 Semantic Scholar 直接查询
"影响力被引 3"	⚠️ 同上	同上，影响力被引 3 属极低，说明本文核心观点未被广泛延伸
etcd 用 Raft / Chubby 用 Paxos / Spanner 用 Paxos	✅ 确认	三者均为工业界已知事实，来源包括各系统官方文档

⚠️ 存疑处： - "被引 83 次"数字未独立核实：解读稿中"被引 83 次"来源于卡片记录，非实时 Semantic Scholar 查询；实际引用数可能因时间差有 ±20% 波动。 - 论文未覆盖 Multi-decree Paxos：原文讨论范围是 single-decree Paxos；Multi-decree Paxos（Chubby/Spanner 实际使用的版本）与 Raft 的等价性不在本文范围内——这是工程选型时需要注意的边界。

可读性精修

原文论点清晰，翻译-对照方法论框架明确，未发现事实性错误。
"被引 83 次"建议改为"引用数来源待实时核实（卡片记录）"，避免引用数过时产生误导。
"影响力被引 3"是低价值数据点，建议在解读正文中删去或在脚注中标注。
⚠️ 解读正文将"PaPoC"写为"PaPoC Workshop"，这是正确的 ACM 会议全称；但在引用时应注意 workshop 论文的学术权重低于顶会。

工程落地：实际系统怎么用、坑在哪

适用场景： - 共识协议选型决策：当团队在 etcd（Raft）vs Chubby/etcd（Paxos）间争论时，用本文的"算法层 vs 表述层"框架快速定位真正的工程差异。 - 遗留 Paxos 系统维护：对必须维护 Multi-Paxos 系统（如 Chubby、Spanner）的工程师，作者的 Raft 术语翻译版是比 Lamport 原文更易理解的参考资料。 - 分布式系统教学：本文的对照分析可直接作为"共识协议对比"课程章节使用。

实际系统选型参考表：

系统	协议	工程生态	适用场景
etcd	Raft	成熟（Kubernetes 默认存储）	需强一致 + 需 Kubernetes 生态
Consul	Raft	成熟（服务发现 + KV）	服务发现场景
TiKV	Raft	成熟（PingCAP 商业支持）	分布式数据库
Chubby	Paxos	Google 内部，外部不可用	Google 内部系统
Spanner	Paxos	Google Cloud	全球化强一致数据库
ZooKeeper	Zab（Raft-like）	成熟但老化	已有系统维护

⚠️ 核心坑：

算法等价 ≠ 实现等价：本文证明 Raft/Paxos 算法层等价，但实现质量差异巨大。etcd（Raft 实现）在 GitHub 上有超过 40k stars、生产案例丰富；相比之下，一个糟糕的 Raft 实现可能比精心实现的 Paxos 更不稳定。选型应看实现成熟度而非算法本身。
Single-decree 与 Multi-decree 是不同的工程问题：本文只覆盖 single-decree Paxos；真实工业系统（Chubby、Spanner）使用的是 Multi-decree Paxos，与 Raft 的等价性不能直接套用。Multi-decree Paxos 的日志连续性、reconfiguration 等问题在 Raft 中有不同实现。
EPaxos 等变体不在讨论范围：EPaxos（Ongaro 在 Raft 之后的后续工作）追求低延迟跨数据中心部署，与 Raft/Paxos 有显著性能差异；本文的等价性结论不适用于 EPaxos。
Raft 的"易实现"有生态加成：Raft 的一个主要工程优势是开源实现丰富（etcd/raft、HashiCorp raft、braft 等），调试工具成熟；这与算法本身无关但对工程团队是实质性收益。
日志补齐 trade-off 在实际部署中的真实成本：Raft 将日志补齐前移到选举阶段，选举后立即可以写日志（Paxos 需要一次 catch-up round-trip）；在高延迟跨数据中心场景下，Paxos 的 catch-up 延迟可能成为性能瓶颈，但 Raft 的严格 up-to-date 要求可能在网络分区时延长选举时间。
Byzantine 容错完全不在讨论范围：本文仅覆盖 crash-fault tolerant Paxos/Raft；PBFT、RBFT 等 Byzantine 容错共识算法与 Paxos/Raft 是完全不同的安全模型，不可混用。