Multi-Paxos 相比 Basic Paxos 改进了什么？
简化版
Multi-Paxos 是把 Basic Paxos 从“单个值共识”扩展到“连续日志共识”的工程化方案。它通常先选出一个稳定 Leader，由 Leader 负责连续发起日志提案。只要 Leader 稳定，后续每条日志可以省掉重复的 Prepare 阶段，直接进入 Accept 阶段，从而把多数写入从两轮通信优化成一轮通信，吞吐和延迟都更适合真实系统。
详细版
Basic Paxos 每决定一个值都要经历 Prepare 和 Accept 两个阶段。如果系统要复制一条不断增长的操作日志，每个日志位置都完整跑两阶段，成本很高，也容易被多个 Proposer 冲突影响。
Multi-Paxos 的核心优化是稳定 Leader。Leader 先通过类似 Prepare 的过程获得一个较高任期或提案编号的领导权，其他节点承诺不接受更小编号的提案。之后在 Leader 没有失效的情况下，每个日志槽位都由这个 Leader 发起 Accept 请求。由于已经完成过领导权确认，后续日志不需要反复 Prepare。
它解决的是性能和活性问题，但安全性仍来自 Paxos 的多数派交集和编号规则。Leader 不是绝对可信的，如果 Leader 故障或网络分区，需要新 Leader 用更大编号重新 Prepare，收集各槽位历史，再继续推进未完成日志。
完整版教学
一、为什么需要 Multi-Paxos
Basic Paxos 只决定一个值，适合解释共识安全性，但真实数据库、配置中心、元数据服务需要的是一串有序操作。比如写入 key=a、删除 key=b、更新成员列表，这些操作必须以同样顺序复制到所有副本。如果每个日志位置都完整跑 Basic Paxos 的 Prepare 和 Accept，系统每写一次都至少两轮网络往返，多个提议者还可能抢编号，性能会很差。
Multi-Paxos 的思路是：既然大多数时间只有一个主节点负责写入，那就让它稳定地当 Proposer。第一次确认 Leader 权限比较重，后续连续写入就走轻量路径。它不是推翻 Paxos，而是把 Paxos 放进日志复制场景里做工程优化。
二、核心改进是稳定 Leader
Multi-Paxos 通常会选出一个 Leader，由 Leader 负责接收客户端写请求，并为每个日志槽位分配顺序。Leader 先用较大的提案编号完成一次 Prepare，拿到多数 Acceptor 的承诺。这个承诺表示：只要没有更大编号的 Leader 出现，Acceptor 不会接受旧编号或更小编号的提案。
完成这一步后，Leader 可以连续为 slot1、slot2、slot3 发起 Accept 请求。每个 slot 代表日志中的一个位置，每个位置只能选定一个值。由于领导权已经建立，后续写入不需要每次都重新探测历史。这样性能从“两轮提交一个日志”变成“稳定期一轮提交一个日志”。
三、省掉 Prepare 不等于不要安全性
很多候选人会误以为 Multi-Paxos 为了性能牺牲安全性，其实不是。它省掉的是稳定 Leader 期间重复的 Prepare，而不是 Paxos 的安全约束。每条日志仍要被多数 Acceptor 接受后才算选定；如果出现更大编号的 Leader，旧 Leader 的请求会被拒绝；新 Leader 上任时仍要收集历史，处理未完成槽位。
换句话说，Multi-Paxos 的安全性仍然来自两个基础：编号单调递增和多数派交集。Leader 只是降低冲突、减少通信轮次的手段，不是安全性的来源。Leader 可以挂，可以被替换，但替换过程必须尊重旧日志历史。
四、新 Leader 上任时怎么处理旧日志
最容易出问题的是 Leader 切换。旧 Leader 可能已经把某些日志发给部分节点，但还没形成多数；也可能已经形成多数，但自己还没来得及通知所有节点。新 Leader 不能简单从自己的本地日志继续写，否则可能覆盖已提交日志。
正确做法是新 Leader 用更大编号执行 Prepare，向多数节点收集各个日志槽位已接受的值。对于已经有历史值的槽位，尤其是最大编号接受值，新 Leader 要优先沿用并补齐；对于没有历史的空槽位，才可以写入新请求或填充 no-op。这个过程保证 Leader 切换后日志不会断裂，已选定的值不会被其他值替换。
五、与 Raft 的关系
Raft 和 Multi-Paxos 在工程形态上很像：都有 Leader，都复制日志，都用多数派提交，都要处理 Leader 切换后的日志恢复。但 Raft 把规则设计得更直观，比如明确任期、角色、日志新旧比较、提交规则；Multi-Paxos 更像一族 Paxos 工程实现，具体细节在不同系统里会有差异。
面试中可以说：Raft 是为了可理解性重新组织出来的共识算法，Multi-Paxos 是 Paxos 在多日志场景下的 Leader 化优化。两者背后的多数派思想相通，但协议表述和工程约束不同。
六、面试追问与工程边界
追问常见在“Multi-Paxos 是否必须有 Leader”。严格说 Paxos 可以多 Proposer，但没有稳定 Leader 会导致频繁冲突和性能抖动；工程中的 Multi-Paxos 几乎都会引入 Leader，让写路径收敛。另一个追问是“Leader 提交后少数节点没写怎么办”。答案是已被多数接受即可认为日志选定，落后的节点后续通过日志补齐或快照追赶。
还要注意，Multi-Paxos 只是共识核心，完整系统还要处理成员变更、日志截断、快照、磁盘持久化、读一致性、Leader 租约、流控和慢节点隔离。这些细节决定系统能不能在线上稳定运行。
七、常见误区与追问
这道题不能只背概念，要把「Multi-Paxos」放回真实分布式系统里解释：参与方是谁、状态怎么流转、失败后怎么恢复，以及它在一致性、性能、可用性之间做了什么取舍。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | Multi-Paxos 通过稳定 Leader 省掉多数日志条目的 Prepare 阶段，用连续 Accept 提升效率 | 不要停在名词解释 |
| 流程机制 | 选出稳定 Leader -> Leader 完成一次 Prepare 获得任期领导权 -> 后续日志直接发送 Accept -> 多数派接受后提交 -> Leader 故障重新选举并恢复日志 | 说明触发方、存储方、确认点和兜底 |
| 工程取舍 | Leader 稳定时，每条日志通常只需一轮 Accept 多数派确认，比 Basic Paxos 每个值两阶段更高效 | 一致性协议用延迟和可用性换确定顺序，不能只背 Paxos/Raft 名词 |
Multi-Paxos 面试拆解：
1. 选出稳定 Leader
2. Leader 完成一次 Prepare 获得任期领导权
3. 后续日志直接发送 Accept
4. 多数派接受后提交
5. Leader 故障重新选举并恢复日志记忆钩子：先说明故障模型和多数派，再拆选主、日志复制、提交、恢复和安全性边界；回答时要紧扣「Multi-Paxos」这道题，不要把相邻概念混成一段泛泛的分布式套话。
- 误区：Multi-Paxos 是另一个完全不同协议。 它是 Paxos 在多值日志复制场景的工程优化。
- 误区：Leader 存在就不需要多数派。 Leader 只是减少协商成本，提交仍要多数派确认。
- 误区：Leader 故障会丢已提交日志。 已提交日志在多数派上有记录，新 Leader 必须继承这些日志。
- 追问：为什么 Multi-Paxos 更高效？ 稳定 Leader 复用 Prepare 成果，连续日志只走 Accept。
- 追问：什么情况下退化？ 频繁 Leader 切换、网络抖动、竞争提案会增加重新准备成本。
- 追问：和 Raft 日志复制像不像？ 工程效果相似，都通过 Leader 管理日志顺序，但安全证明和术语不同。
八、加强记忆
Multi-Paxos 可以记成“Basic Paxos 加稳定 Leader 加连续日志”。第一次通过 Prepare 建立领导权，后续稳定期每个日志位置直接 Accept，多数接受后提交。它提升性能和活性，但安全性仍靠编号和多数派交集。Leader 换届时必须收集旧日志历史，先补旧账，再写新账。