共识：Paxos 与 Raft

**共识（consensus）**让一组节点就一个值达成一致，是状态机复制（每台机器执行同样的命令序列）的底座。本章讲共识解决什么问题、Paxos 的两阶段、Raft 的分解与设计取舍（→ 并发与同步）。

共识解决什么问题

状态机复制：把一个确定的状态机复制到 $N$ 台机器，每台执行同样的命令序列——状态就一致。共识的任务：让所有机器对命令序列的顺序达成一致。

正式定义的三个性质：

为何需要多数派（quorum）： $2f+1$ 个节点容忍 $f$ 个故障——多数派交集保证安全性：任何两个多数派至少共享一个节点，它携带旧决议，防止"两个值都被选"。写入要等多数派确认，读多数派信息（或租约）——共识的一切代价都来自多数派。

Paxos 解决"单个值"的共识，两个角色（提议者/接受者）两个阶段：

不变式：一旦某个值被多数派接受，之后任何提议都会选它——安全性由此成立。活性靠领导者（避免提议冲突）：Multi-Paxos 优化为"稳定的领导者跳过 prepare 阶段"，每个值一轮 accept——这就是工程中实际跑的形态。

Paxos 以难以理解著称：正确性证明绕（不变式隐藏在两阶段的承诺里）、角色与优化多、论文本身晦涩——Lamport 自己都写了 "Paxos Made Simple" 还是不够。

Raft（2014）显式以可理解性为目标：把共识分解为选举、复制、安全三个子问题，每个独立可理解。

领导者接收命令 → 追加到本地日志 → 并行发给跟随者 → 多数派确认即提交 → 应用到状态机、通知跟随者。日志按序复制——状态机复制的命令序列。

Raft 的取舍：更强的领导者（一切经领导者，跟随者被动）换可理解性；Paxos 更对称但绕。Raft 的正确性可读、可证、可实现——工程主流（etcd、TiKV、CockroachDB、Consul）都选了 Raft。

共识的代价是至少一轮跨节点往返：

每次写要多数派确认——延迟受最慢的多数派成员约束；
节点数增加：容错更强、延迟略增（3 或 5 个是常见选择）；
共识不便宜，能不用就不用——单一协调者 + 持久化（够用时）比集群共识快；共识用在必须容错强一致的地方：元数据、锁、配置（→ 协调服务与实践模式）。