[深度对比] 分布式共识的双雄：Paxos 与 Raft，为何 Raft 成为了工程界的宠儿？

在分布式系统的浩瀚宇宙中，“共识（Consensus）” 是最核心的难题之一。如何让一堆可能随时宕机、网络延迟的机器对某个值达成一致？这个问题困扰了计算机科学家几十年。

在这个领域，有两位绝对的主角：一个是理论界的“神” Paxos，另一个是工程界的“救世主” Raft。

很多开发者都知道，现在主流的分布式组件（如 Etcd, Consul, TiKV, Kafka的新版本）大多选择了 Raft。那么，Paxos 到底输在哪里？Raft 又为何如此容易实现？本文将带你深入剖析两者的区别与优劣。

一、核心设计哲学的差异

要理解它们的区别，首先要看它们诞生的初衷：

Paxos (Leslie Lamport, 1990)：旨在发现共识问题的数学规律。它从数学角度证明了在分布式系统中达成一致的充要条件。它追求的是理论的完备性和一般性。
Raft (Diego Ongaro & John Ousterhout, 2013)：旨在提供一个可理解（Understandable）且易于实现的算法。它的设计目标非常明确：就是为了解决 Paxos 太难懂、太难实现的问题。

如果把 Paxos 比作量子力学（解释了世界的本质，但很难直接用来造桥），那么 Raft 就是牛顿力学（在特定约束下，给了你一套造桥的标准公式）。

二、为什么 Raft 更容易实现？

这是 Raft 能够后来居上的最大原因。Raft 并不是在理论上超越了 Paxos，而是通过增加约束和分解问题，极大地降低了工程落地的复杂度。

1. 问题的分解（Decomposition）

Paxos 将选举、日志复制、确认提交等逻辑混杂在一起，牵一发而动全身。
Raft 强制将共识问题拆解为三个独立的子模块：

Leader Election（选主）：先选出老大，别的什么都不干。
Log Replication（日志复制）：老大负责同步数据，Follower 负责接收。
Safety（安全性）：确保数据一旦提交，就永远存在。

这种解耦使得开发者可以独立编写和测试每个模块。

2. 强 Leader 模型（Strong Leader）

这是 Raft 简化的杀手锏。

Paxos：允许所有节点同时发起提案（虽然 Multi-Paxos 也会优化为单 Leader，但协议本身允许并发）。这导致需要处理极其复杂的“冲突解决”和“日志乱序”问题。
Raft：是独裁的。日志流向只能是 Leader -> Follower。Follower 绝对不会修改 Leader 的日志，Leader 也永远不会覆盖自己的日志。这种单向数据流消除了大量边缘状态。

3. 强制日志连续（Log Continuity）

Paxos：允许日志有“空洞”。比如节点 A 确认了第 1、2、5 号日志，缺了 3 和 4。Paxos 允许这种情况存在，后续再通过复杂的逻辑把空洞补齐。
Raft：不允许空洞。Follower 必须按顺序接收日志。如果 Follower 缺了第 4 号日志，Leader 绝不会发第 5 号给它，而是会强制回退（利用 PrevLogIndex 检查），直到找到一致的点，然后覆盖同步。这让状态机的实现变得极其简单——按顺序执行即可。

4. 选主限制：拥有最新日志者才能当选

在 Paxos 中，任何节点都可能成为 Leader，哪怕它的数据很旧。上位后，它需要先学习历史数据，补全自己的知识，然后才能开始工作。
Raft 规定：只有拥有所有已提交日志的节点，才有资格当选 Leader。 这意味着新 Leader 上任的第一刻起，它就不需要去问别人“我是不是缺数据了”，直接接受新写入即可。

总结

Raft 之所以容易实现，是因为它剥夺了节点的自由：

不准乱序提交（消灭了复杂的并发合并逻辑）。

不准 Follower 质疑 Leader（消灭了双向同步逻辑）。

不准旧节点当 Leader（消灭了 Leader 上位后的补数据逻辑）。

三、 Paxos 与 Raft 的优缺点权衡

既然 Raft 这么好，Paxos 是不是一无是处？并非如此。两者在不同的维度各有千秋。

1. Paxos 的优点（对比 Raft）

理论的极致与通用性：Paxos 是共识算法的基石。Google 的 Chubby、Spanner 底层依然是 Paxos 的变种。事实上，Raft 可以被看作是 Paxos 的一个特定约束下的子集。
更高的写入并发潜力：由于 Paxos 允许日志乱序确认（Out-of-Order Commit），在不依赖强顺序的场景下（或者使用 EPaxos 等变种），它的理论吞吐量可以高于 Raft。Raft 必须一个接一个顺序提交，存在队头阻塞（Head-of-Line Blocking）风险。
无 Leader 的生存能力：Basic Paxos 不需要 Leader，在网络极其不稳定、无法维持稳定 Leader 的极端环境下，Basic Paxos 依然能工作，而 Raft 会陷入反复选主的死循环（不可用）。

2. Raft 的优点（对比 Paxos）

可理解性（Understandability）：这是 Raft 的核心竞争力。一个普通的工程师阅读 Raft 论文两遍可能就能写出原型；而阅读 Paxos 论文十遍可能还是一头雾水。
工程细节完备：Paxos 论文只讲了如何达成共识，没讲如何增删节点、如何压缩日志（Snapshot）。Raft 对这些工程痛点都给出了标准解决方案（如 Joint Consensus 成员变更算法）。
调试与排错：由于 Raft 的状态转换路径非常清晰（且有限），当系统出现 Bug 时，更容易复现和定位。

四、总结：如何选择？

特性	Paxos (Multi-Paxos)	Raft
设计目标	理论证明	工程实现、可理解性
日志结构	允许空洞，并发确认	必须连续，顺序确认
数据流向	多点可能（复杂）	Leader 单向流向 Follower
实现难度	极高（容易写出 Bug）	中等（有标准参考）
工业界现状	Google Spanner, Zookeeper (ZAB 类似)	Etcd, Consul, TiKV, CockroachDB