Paxos 和 Raft 到底是什么关系？2020 年那篇 6 页短文，让半个分布式圈松了口气

关联论文：2004.05074

如果你做过分布式系统，肯定听过两座大山：Paxos 和 Raft。

Lamport 在 1998 年提出 Paxos 时，写了一篇以"难懂"闻名的论文（连审稿人都吐槽过）。后来 Ongaro 和 Ousterhout 2014 年提出 Raft，明确喊出"我们就是要让你看懂"的口号，迅速成了 etcd、Consul、TiKV 的事实标准。

但有个隐含问题困扰了工程界十几年：Raft 比 Paxos 易懂 ≠ Raft 比 Paxos 更简单。很多团队选型时把"易理解"当成算法本身的优势，这其实是个误会。

2020 年那篇 arXiv 2004.05074（Howard, "Paxos vs Raft: Have we reached consensus on distributed consensus?", PaPoC Workshop 2020）做了一件很聪明的事——用 Raft 的术语把 Paxos 重新写一遍，然后一字一句对照，定位两个算法真正的差异点。

结论出人意料：两种算法在算法层几乎完全等价；唯一真正的差异在 leader election 阶段——是否允许日志落后的候选者当选。

到 2026 年 9 月，这篇被引 88 次（S2 88 + OpenAlex 0 + 影响力 3），影响力被引偏低但被分布式系统教学领域广泛引用——它本质上是一篇"分布式共识的对照翻译工程"，给所有想搞懂 Paxos 又不敢读 Lamport 原文的人一条更短的路径。

为什么这事值得每个分布式工程师知道

Paxos 和 Raft 是构建容错、强一致分布式系统的"基石原语"。从 etcd 到 Chubby、从 Spanner 到 TiKV，几乎所有强一致存储都跑在这两种算法上。

现实里工程团队面临的真实问题：

新人入职看不懂 Paxos——Lamport 的"鸽子"比喻、希腊小岛故事让很多人敬而远之；
选型时把"易理解"当成"Raft 算法更简单"——但 2020 那篇论文告诉你，这是个误会；
维护遗留 Paxos 系统没资料——老 Chubby、老 Spanner 团队需要一份"用现代术语解释 Paxos"的资料；
面试时画 Raft 状态机——但说不清 Raft 和 Paxos 到底什么关系。

2020 那篇 6 页短文把这四个问题一次性回答了。

两个算法唯一的真实差异

Paxos 风格：日志补齐责任在"当选后"

Paxos leader election:
  elected = self
  for each peer p:
    if quorum(peers).accept(elected as proposer):
      return elected   // 当选，但日志可能落后
  // 当选后必须主动 catch-up log 到多数派最大 index

任何服务器都可以被选为 leader，即使它的日志不是最新的。当选后必须主动把自己的 log 补齐到多数派已接受的最大 index，才能开始 propose 新值。

Raft 风格：日志补齐责任前移到"选举时"

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

选举时通过 RequestVote RPC 携带 (lastTerm, lastIndex)，只有当 candidate 的日志"至少与 responder 一样新"时才能拿到票。这样落后的候选者天然不可能当选，选举结束即可开始写日志。

这就是两种算法唯一的真实差异——把日志补齐的责任，从"leader 当选后"前移到"candidate 选举中"。

工程 trade-off 怎么选

Paxos 风格：选举宽松，任何节点都可能当选，但当选后需要一次 catch-up round-trip 才能开始写日志。跨数据中心高延迟场景下，catch-up 延迟可能成为瓶颈。
Raft 风格：选举严格，只有日志最新节点能当选，选举后立即可以写日志。但网络分区恢复时，选举可能需要多轮投票才能选出 leader，延长不可用窗口。

为什么 Raft 看起来"易懂"？

2020 那篇论文的另一个不那么显眼但很重要的副产物：

Raft 的"易懂"主要来自 Ongaro & Ousterhout 那篇博士论文的写作质量——状态机分解清晰、图示清楚、术语一致、用例驱动——而不是来自算法本身的不可化约性。

换句话说：如果 Lamport 当年也用类似方式写 Paxos 论文，工程界对 Paxos 的认知可能完全不同。

这是个对所有写协议论文的人都有启发的观察——你的算法再漂亮，写不清楚就等于半成品。表述层（presentation layer）和算法层（algorithm layer）必须分开看。

那到底选 Paxos 还是 Raft？

2020 那篇论文的答案很明确：算法层等价，决定因素是工程生态。

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

但有几个重要边界要注意：

算法等价 ≠ 实现等价——etcd（Raft 实现）有 40k+ stars、生产案例丰富；一个糟糕的 Raft 实现可能比精心实现的 Paxos 更不稳定。选型应看实现成熟度而非算法本身。
Single-decree vs Multi-decree 是不同的工程问题——2020 那篇论文只覆盖 single-decree Paxos；真实工业系统（Chubby、Spanner）用的是 Multi-decree Paxos，与 Raft 的等价性不能直接套用。
EPaxos 等变体不在讨论范围——EPaxos（Ongaro 后续工作）追求低延迟跨数据中心部署，与 Raft/Paxos 有显著性能差异。
Byzantine 容错完全不在讨论范围——PBFT、RBFT 等拜占庭容错算法与 Paxos/Raft 是完全不同的安全模型，不可混用。

这篇短文适合谁读

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

一句话总结

Paxos 和 Raft 几乎等价——Raft 的"易理解"主要来自博士论文的写作质量，而不是算法本质的简化。选型时看工程生态，不看算法"信仰"。

三个标题变体

Paxos 和 Raft 是不是一回事？2020 年那篇 6 页短文给出了答案
分布式系统选 Paxos 还是 Raft？20 年争论被这篇论文终结
从 etcd 到 Spanner：99% 的工程师都不知道 Paxos 和 Raft 是同一种算法

📱 小红书风格卡片文案

🛰️ 做分布式系统的人，都被 Paxos 和 Raft 折磨过——一个难懂到劝退，一个易懂到封神。

但 2020 年那篇 arXiv 2004.05074（Howard, PaPoC Workshop 2020）做了一件聪明事：用 Raft 的术语把 Paxos 重新写一遍，一字一句对照。结论出乎意料——两种算法几乎完全等价，唯一的真实差异只在 leader election 阶段怎么处理"日志落后的候选者"。

Paxos 风格：选举宽松，任何节点都可能当选，但当选后需要主动 catch-up 日志。
Raft 风格：选举严格，只有日志最新节点才能当选，当选后立即可写日志。

还有个更重要的副产物：Raft 的"易懂"主要来自 Ongaro & Ousterhout 那篇博士论文的写作质量——状态机分解清晰、图示清楚、术语一致——而不是算法本质的简化。

翻译成大白话：如果 Lamport 当年也用这种方式写 Paxos，整个分布式圈对 Paxos 的认知可能完全不同。

这篇论文被引 88 次，是分布式系统教学领域引用最高的对照工程。它告诉我们两件事——协议论文的表述层和算法层要分开看；选型决定因素是工程生态，不是算法信仰。

📌 关键词：分布式共识 / Paxos / Raft / etcd / Chubby / Spanner / 协议选型 / 论文解读

分布式系统 #Paxos #Raft #etcd #系统工程 #协议设计 #论文解读 #科技科普