🤔 一、为什么需要共识
分布式系统里没有"全局时钟"、消息会丢会乱序，单台机器无法代表"全集群的事实"。共识（Consensus）解决的就是：即使在部分节点故障/网络异常时，存活节点仍能就某个值达成一致。
共识 ≠ 复制：复制是把数据拷贝到多机；共识是"在不确定环境里，大家先商量好一个值再复制"。选主、配置变更、事务提交本质上都是共识问题。
Paxos 保证：只要多数派（> N/2）节点存活，系统就能持续就一系列值达成一致，且一旦某值被选定（chosen），永远不会被改成别的值。
🎭 二、三类角色
Proposer 提议者
提出"值"的提案（编号 n + value），发起协议。
Acceptor 接受者
决策者，存储提案、投票；通常 2F+1 个以容忍 F 个故障。
Learner 学习者
被告知最终选定结果，不参与投票（可理解为"同步副本"）。
🔁 三、Basic Paxos：两阶段提交
Prepare：Proposer 发带编号 n 的准备请求
编号 n 全局递增，用于排序。Acceptor 只承诺"不再接受编号 < n 的提案"，并把自己已接受过的最高编号提案返回。
Promise：Acceptor 响应
若 n 大于它见过的最大编号，则承诺并回复"我已接受过的提案（若有）"；否则忽略。
Accept：Proposer 收齐多数派 Promise 后发 Accept
value 取"Promise 中编号最大的已接受值"（没有则用自己最初想提的值）——这保证不会覆盖已被选定的值。
Accepted：Acceptor 接受并通知 Learner
Acceptor 若没承诺更高编号，则接受该值；多数派接受后该值被选定，Learner 学习到结果。
核心技巧：Prepare/Promise 阶段"抢占"编号，Accept 阶段"继承历史值"。正是"用最大编号 + 继承已选值"的设计，让 Paxos 在并发提议下仍能收敛到唯一值。
📜 四、Multi Paxos：连续达成共识
Basic Paxos 每次就一个值达成共识，开销大。Multi Paxos 把"选一个 Leader"和"日志序号"固定下来，让后续的 Accept 阶段不用每次都 Prepare，从而连续、高效地就一串值（日志）达成一致。
Multi Paxos ≈ "先选一个稳定 Leader，之后的每个日志项基本只走 Accept 阶段"。这其实就是后来 Raft 的设计雏形——Raft 把"选主 + 日志复制"显式拆开，更易理解。
⚖️ 五、Paxos vs Raft
| 维度 | Paxos | Raft（见日志复制页） |
|---|---|---|
| 目标 | 理论正确、最小假设 | 工程可理解、易实现 |
| 结构 | 角色可重叠、难拆解 | 明确拆为 选举/日志/安全 三块 |
| 易实现度 | 难（论文晦涩） | 易（有详尽规范与图示） |
| 等价性 | 共识理论基石 | 与 Multi Paxos 等价的工程化 |
🎯 六、面试高频追问
Paxos 为什么需要两阶段？
单阶段无法应对并发提议与已选定值的冲突。阶段一"抢占+探明历史"，阶段二"在已知约束下提交"，二者配合保证安全性。
为什么是"多数派"？
任意两个多数派必有交集，保证"新提议能看到旧选定值"或"旧选定值已无法被推翻"，从而一致性成立。容错能力为 F 个故障需 2F+1 节点。
活锁（livelock）是什么？
两个 Proposer 不断用更高编号互相抢占，谁也定不下来。解法：选一个 Leader 专门提议，或用随机退避。
延伸阅读：Raft 日志复制与状态机 · ZAB 协议 · Raft 选举