Paxos 和 Raft 是分布式系统中解决共识问题（Consensus）的两个核心算法

Paxos 和 Raft 是分布式系统中解决共识问题（Consensus）的两个核心算法，用于确保多个节点在不可靠网络环境下对某个值或状态达成一致。它们是构建分布式数据库、分布式锁、容器编排等系统的基石。

---

核心概念：分布式共识问题

想象一群分散在不同地点的人（节点），需要通过可能丢失信息的信使（网络）达成一个共同决定。挑战在于：

• 有人可能失联（节点故障）

• 信使可能迷路（消息丢失）

• 可能出现虚假消息（拜占庭故障）

• 必须保证：所有活人最终意见一致，且意见有效

---

Paxos：理论完备但晦涩的"元老"

Paxos 由 Leslie Lamport 于1990年提出，是首个被数学证明正确的共识算法。

核心特点

• 理论优雅：数学上极其严谨，安全性（Safety）和活性（Liveness）都有证明

• 晦涩难懂：出了名的难以理解，Lamport 本人都说"它简单到连实现都不需要"

• 工程噩梦：没有明确实现细节，导致"一千个人有一千种 Paxos 实现"

简化流程（两阶段）

阶段1 - 准备：
提案者 → "我要提编号为N的方案" → 接受者
接受者 → "承诺不收更小编号，返回已接受的最大编号" → 提案者

阶段2 - 接受：
提案者 → "这是编号N的真实内容V" → 接受者
接受者 → 多数接受则达成共识

致命问题：活锁（两个提案者反复抢占，永远无法成功）、实现复杂、缺乏工程指导

---

Raft：为可理解性设计的"现代标准"

Raft 由 Diego Ongaro 和 John Ousterhout 于2014年提出，设计目标是：可理解性优先。

"如果一个系统复杂到无法理解，就无法信任它。"

三大核心机制

1. 领导者选举（Leader Election）

• 节点三状态：Leader（主）、Follower（从）、Candidate（候选）

• Leader 定期发送心跳，超时未收到则触发选举

• 任期（Term） 递增机制确保每个任期最多一个 Leader

2. 日志复制（Log Replication）

• 所有写操作必须经过 Leader

• Leader 并行发送日志到 Followers，多数确认后才提交

• 严格顺序保证：日志索引连续，永不跳过

3. 安全性（Safety）

• 选举限制：Candidate 必须包含所有已提交日志，防止数据回滚

• 日志匹配：相同索引和任期的日志必定一致

• 状态机安全：已提交的日志永远不会被覆盖

---

Paxos vs Raft 对比表

维度	Paxos	Raft
可理解性	★☆☆☆☆（需数学直觉）	★★★★★（清晰状态机）
工程实现	困难，陷阱多	直接，有参考实现
日志顺序	不保证全局顺序	严格顺序保证
角色分工	动态、模糊	固定（Leader/Follower）
配置变更	复杂，易出错	内置 Joint Consensus 机制
性能	理论上更灵活	略低但完全可接受
工业采用	少数巨头（Google）	事实标准（etcd、Consul、TiDB）

---

应用场景

Paxos 应用

• Google Spanner：全球分布式数据库（TrueTime + Paxos）

• Chubby：分布式锁服务

• 仅适用于有顶尖分布式团队的场景

Raft 应用（占95%以上）

• etcd：Kubernetes 核心存储，保存整个集群状态

• Consul：服务发现与配置中心

• TiKV：PingCAP 的分布式数据库底层

• CockroachDB：云原生分布式 SQL 数据库

• 几乎所有新分布式系统

---

直观类比

Paxos → 像古希腊直接民主：

• 没有主席，任何人随时提案

• 需要精通议事规则才能参与

• 可能陷入无限辩论

Raft → 像现代议会制：

• 选出总理（Leader），任期制

• 总理提出法案，议员表决

• 规则清晰，普通人能懂

---

总结建议

场景	推荐
学术研究	理解 Paxos 的理论基础
生产开发	无脑选 Raft，生态成熟，避免踩坑
学习路径	先掌握 Raft，再回头看 Paxos 会豁然开朗

Raft 的出现让共识算法从"黑魔法"变成了"工程师的标准工具"，是现代分布式系统的首选方案。