Multi Paxos靠选主把并发提案竞争简化为主节点单向复制

[[Basic-Paxos的活锁问题及为何不直接用于工业实践]]的根源是所有提案节点 完全平等、可以随时并发抢占同一个值的修改权。Multi Paxos的改进思路不是 打破”节点平等”这个原则，而是在平等节点之间选出一个临时的”意见领袖”： 节点通过心跳定时探测是否存在主节点，一旦超时未发现主节点，就用Basic Paxos的准备/批准两轮交互竞选主节点，竞选成功后，只有主节点能够提出 提案，其他节点收到客户端请求都转发给主节点处理。选主完成后，后续所有 提案本质上都是对同一个提案ID的连续批准，因此不再需要每次都重新走一遍 准备阶段——相当于把”多方并发竞争”的场景转换成了”单一有序操作”的场景， 只需一次批准交互即可达成一致，从根源上消除了活锁的可能。这也让二元组 （id, value）变成三元组（id, 任期编号, value）——任期编号严格单调递增， 用于应对主节点网络分区后重新选主的场景：分区恢复后，全体节点只承认 任期编号更大的那个主节点，旧主节点的未提交变更全部回滚。可以证明”如何 选主”“如何复制数据”“如何保证过程安全”这三个子问题被同时解决时，就等价 于达成了共识——这正是Raft论文采用的分解思路，Raft、ZAB都被认为是Multi Paxos的等价派生实现。

结构图：

flowchart TD
    A[心跳超时未发现主节点] -->|用Basic Paxos两轮交互竞选| B[选主成功: 任期编号+1]
    B --> C[之后只有主节点能提案]
    C --> D[其他节点收到请求全部转发给主节点]
    D --> E[只需一次批准交互, 无须重复准备阶段]
    E -->|主节点分区后重连| F[全体只承认任期编号更大的主节点<br/>旧主未提交变更回滚]