从 Paxos 到 Multi-Paxos：分布式共识的演进之路

可视化演示

展示Paxos两阶段协议(Prepare/Promise→Accept/Ack)、Multi-Paxos Leader选举与日志复制、Quorum容错分析，通过三模式交互演示分布式共识核心机制。

共识问题引入

假设公司三个部门要定团建餐厅。行政说火锅，运营说日料，研发说烧烤。每个人都有自己的偏好，如果没有人让步，会议就僵住了。现实里大家会举手投票，看哪个方案获得多数派支持。分布式系统的共识问题，本质上就是这场“团建投票”——多台机器对一个值达成一致。

真实世界里，三台服务器同时收到不同的写请求，它们需要选出一个确定的值写入副本。网络可能延迟、节点可能宕机，根本没有一个“全局时钟”能保证所有人同时看到同一画面。于是科学家想到：不必让全票通过，只要一个超过半数的集体认可某个值，这个值就是共识。

多数派为什么行得通？因为任意两个多数派集合必有交集。只要两个集合都超过半数节点，它们必然共享至少一个节点。这个节点可以证明哪个值先被选定，从而避免两个不同的值同时成为共识。

这就是多数派原则的数学基础：任何两条不同的共识决议不可能同时获得法定多数，因为多数派必有交集，而交集节点记住了谁先谁后。一场会议，最终永远只能有一个赢家。

基础Paxos协议

公司决定给会议立一套正式规则。规则分出三类角色：有人负责发起议题（提案者），有人负责举手投票并记住结果（接受者），有人负责旁听并把结果传达给其他人（学习者）。没有规则，会议就没法高效推进。

Paxos 协议中的三种角色正好对应这个比喻。提案者（Proposer）提出带编号的提案；接受者（Acceptor）对编号做出承诺并接受值；学习者（Learner）从多个接受者处学习最终选定的值。真正的工程实现里一台节点可以同时扮演多个角色，但逻辑上三者必须分开。

提案编号是这套规则中最关键的设计。编号必须单调递增且全局唯一。编号就像一个“优先级数字”：越晚提出的提案编号越大，在表决中越占优先权。这使得两个并发提案不会因为顺序问题互相踩踏，也让接受者能明确判断“我现在该听谁的”。

编号规则让会议永远有清晰先后：任何人发起新提案都必须使用比当前更大的编号，就像开会时“请按议题顺序发言”一样，提案者不需要争夺话筒，只需要自报更大的编号。

第一阶段准备

拿到话筒的提案者没有直接宣布最终方案，而是先做一次摸底调查：“在场各位，你们之前有没有已经定过的结论？如果我现在提出一个更高编号的方案，你们愿意优先考虑吗？”这就是 Prepare 阶段的工作。

提案者广播 Prepare(n) 给所有接受者。接受者检查这个编号 n 是否大于自己承诺过的最大编号 promised_id。如果大于，接受者就更新承诺，并回复一个 Promise 消息，同时把自己已接受过的旧提案（编号和值）带上；如果编号不够大，则直接拒绝或忽略。

这个阶段的意义在于“锁定状态”：接受者承诺不再响应任何编号更小的 Prepare 请求。这样一来，后到的提案者能够确定，在他摸底之后不会再有人携带旧编号来搅局，他拿到了一个干净的协商窗口。

摸底调查是 Paxos 的灵魂：它让新提案者知道团队之前是否有既定结论，同时用编号锁住所有接受者的承诺。有了这一步，后面的“最终表决”才不会推翻别人已经达成的协议。

第二阶段接受

摸底完成后，提案者整理出最终方案。如果他发现之前有人接受过旧值，就必须沿用旧值，而不是另起炉灶；如果所有人都没有接受过任何值，他才能自由提出自己的方案。这就是接受（Accept）阶段。

提案者把编号 n 和值 v 打包成 Accept 请求广播给接受者。接受者发现编号 n 仍不小于自己的承诺编号，就接受这个值，并返回 Accepted 反馈。当提案者收到多数派的 Accepted 时，共识达成，值 v 被正式选定。

“限制性选择”是这个阶段最反直觉也最精妙的设计。它的目的只有一个：防止两个不同的提案者各自提出不同值，导致系统分裂。因为多数派必然相交，提案者 A 的多数派答案一定会被提案者 B 的多数派看到，B 必须延续 A 的结论。

限制性选择让共识有了“先来后到”的惯性：一旦某个值被多数接受，后续一切新提案都会自然而然地延续它。就像会议已经定了火锅，后来的议题安排就不该再推翻火锅店，而是围绕火锅店规划。

Multi-Paxos演进

公司每天要开十几次会，如果每次会议都重新走一遍“举手确认流程”，效率低得可怕。于是团队推选了一位固定主持人，把议事规则一次性确认好，后续每个议题只要挨个过即可，流程开销大幅下降。

Basic Paxos 每次只能对一个值达成共识，真实系统却需要连续处理成千上万个写请求。Multi-Paxos 的核心思路是：先选举一个稳定的 Leader（主持人），让它在一次 Prepare 中获得一个足够大的编号；之后所有日志条目的共识都复用这个编号，只执行 Accept 阶段。

这个演进看似简单，实际上改变了 Paxos 的效用：Basic Paxos 是“开一次会，决定一件事”；Multi-Paxos 是“选一次主持人，连续过整个议程”。Leader 还负责分配日志槽位、决定提交顺序，让分布式系统真正具备连续处理请求的能力。

主持人机制的本质，是用一次高质量的准备换取了后续所有提案的速度。每一个新日志条目不需要再重新询问“大家愿意吗”，只需要直接说“按这个来”，因为 Leader 的权威已经在选主时确认过了。

日志复制机制

有了主持人，会议还需要一份清晰的纪要。主持人把每个议题标上序号：第 1 条、第 2 条……所有部门都按这份纪要的顺序执行工作。谁也不能说自己先执行第 3 条，因为纪要的顺序就是所有人的共识顺序。

Multi-Paxos 中的“纪要”就是日志。每个共识实例对应一个日志槽位（slot），槽位里放着一个值。多个节点通过 Multi-Paxos 对同一个槽位达成一致，就得到了相同的有序日志。后续每个节点把日志按顺序应用到自己的状态机上，就保证了副本数据完全一致。

槽位编号必须严格单调递增，因为日志的顺序就是提交顺序。数据库、配置中心等系统的操作语义都依赖这个顺序：先加订单再扣库存，和先扣库存再加订单，结果完全不同。Multi-Paxos 通过槽位把并发操作串行化，从而保证状态机的确定性。

日志槽位就是会议纪要的页码。所有部门都从第 1 页读到第 N 页，执行的顺序完全相同。这样即使某个节点中途宕机重启，只要日志还在，它就能从上次的位置继续，回到与其他节点一致的状态。

优化与对比

复盘整个流程：过去每个议题都要从 Prepare 开始，两个往返才能决定一个值；现在主持人选定时消耗一次 Prepare，后续 N 个议题每个只需要一个 Accept 往返。吞吐量大幅提升，这正是 Multi-Paxos 在工程中被广泛采用的原因。

与 Raft 对比，Raft 把 Multi-Paxos 的思路进一步“工程简化”：强约束的 Leader、任期编号、心跳续约，以及日志匹配机制。Raft 的 Leader 更接近“强主持人”模型——所有写入必须经过 Leader，Leader 定期心跳维持权威，因此实现起来比原始 Paxos 直观得多。

工程实践上，etcd、TiKV、CockroachDB 等系统都实现了类 Raft 协议；而 Google 的 Chubby、Spanner 则采用了更贴近 Multi-Paxos 的工程化方案。理解 Paxos 与 Multi-Paxos 的演进，能让你看懂这些系统底层的一致性内核设计。

一条公式概括了 Multi-Paxos 的全部收益：准备费用摊薄到整个日志序列上。正如会议主持人前期花一点时间定规则，后面所有议题都顺着规则高效推进，这正是分布式系统最需要的工程智慧。

AI 应用场景

Python 演示

class PaxosNode:    """模拟一个接受者：记录承诺编号与每个日志槽位的已接受值"""    def __init__(self, name):        self.name = name        self.promised_id = 0        self.accepted = {}     def prepare(self, nid):        if nid > self.promised_id:            self.promised_id = nid            return "promise"        return "reject"     def accept(self, slot, nid, val):        if nid >= self.promised_id:            self.promised_id = nid            self.accepted[slot] = (nid, val)            return "ok"        return "reject"  def run_multi_paxos(nodes, leader_id, slot, value):    chosen = value    for node in nodes:        if slot in node.accepted:            chosen = node.accepted[slot][1]            break    acks = 0    for node in nodes:        if node.accept(slot, leader_id, chosen) == "ok":            acks += 1    if acks < 2:        return None    return chosen  def demo():    nodes = [PaxosNode("n%d" % i) for i in range(3)]    promises = sum(1 for n in nodes if n.prepare(500) == "promise")    if promises < 2:        print("Leader 选举失败")        return    print("Leader 编号 500 已确定，后续槽位只走 Accept")    for slot, val in enumerate(["创建订单表", "写入订单ID=1", "更新库存"]):        result = run_multi_paxos(nodes, 500, slot, val)        print("槽位%d -> %s" % (slot, result))  if __name__ == "__main__":    demo()

1. if nid > self.promised_id:只有更大的编号才值得承诺，防止旧请求干扰。
2. self.accepted[slot] = (nid, val)记录某个日志槽位已接受的值，供后续提案参考。
3. if slot in node.accepted:如果槽位上已有旧值，新提案必须沿用，这是限制性选择。
4. node.accept(slot, leader_id, chosen)直接跳过 Prepare，用同一个 Leader 编号接受新值。
5. sum(1 for n in nodes if n.prepare(500) == "promise")一次性选主，为后续所有槽位预热。
6. if acks < 2:接受者未达到多数派（3 节点中至少 2 个）则本次提案失败。

常见误区

面试题