MultiPaxos与Basic Paxos核心差异、排序机制及图解咨询

一、核心差异对比 #

先抓最本质的区别：Basic Paxos是单实例共识算法，每次只能搞定一个决策的共识；MultiPaxos是多实例批量共识算法，通过稳定Leader复用流程，把多个共识任务串起来高效处理，这也是它能落地到生产系统（比如etcd、ZooKeeper）的原因。

具体差异点：

• 任务处理模式：Basic Paxos一次只处理一个共识实例，每个实例都要完整走「Prepare → Accept → Learn」三轮通信；MultiPaxos可以连续处理N个实例，大部分时候跳过Prepare阶段，直接走Accept。
• Leader角色：Basic Paxos没有固定Leader，每次共识都可能临时选Proposer，容易出现冲突；MultiPaxos依赖长期稳定的Leader，所有实例的提议都由Leader发起，避免冲突。
• 效率表现：Basic Paxos通信开销大，适合单决策场景；MultiPaxos把通信轮次从每个实例3轮降到大部分实例2轮，吞吐量提升数倍。

二、MultiPaxos的排序机制运作 #

MultiPaxos的排序本质是靠Leader分配全局唯一且递增的实例编号（Instance ID），再通过稳定流程把每个实例的值绑定到编号上，最终所有节点按编号顺序得到一致的序列。具体步骤：

1. Leader竞选：先用Basic Paxos流程选出一个Leader，这个Leader会拿到所有Acceptors的当前共识状态（已接受的最高编号实例）。
2. 实例编号分配：Leader为每个待处理的共识任务分配一个比之前所有编号都大的Instance ID，保证编号严格递增。
3. 快速共识流程：Leader直接给Acceptors发「Accept请求」，携带Instance ID和对应的值。只要Acceptors没收到更高优先级的Prepare请求（也就是没有新Leader抢权），就会接受这个提议，回复确认。
4. 状态同步与Leader切换：如果Leader挂了，新的Proposer会发起Prepare请求，收集所有Acceptors手里已接受的最高编号实例和对应值，确保自己掌握最新的共识进度，然后成为新Leader，继续按递增编号处理后续实例。

三、MultiPaxos核心流程文本图示 #

┌─────────────┐       ┌─────────────┐       ┌─────────────┐
│  Leader     │       │  Acceptor   │       │  Learner    │
│  (Proposer) │       │    (多个)    │       │    (多个)    │
└─────────────┘       └─────────────┘       └─────────────┘
         │                          │                          │
         │ 1. 竞选Leader（Basic流程）│                          │
         │─────────────────────────>│                          │
         │                          │ 回复同意+已接受实例状态  │
         │<─────────────────────────│                          │
         │                          │                          │
         │ 2. 发Accept请求（ID+值）  │                          │
         │─────────────────────────>│                          │
         │                          │ 回复接受确认             │
         │<─────────────────────────│                          │
         │                          │                          │
         │ 3. 通知Learner结果       │                          │
         │────────────────────────────────────────────────────>│
         │                          │                          │
         │ 4. 重复2-3处理下一个实例  │                          │
         │─────────────────────────>│                          │
         │                          │                          │
         │ （Leader故障时）          │                          │
         │ 新Proposer发Prepare请求  │                          │
         │─────────────────────────>│                          │
         │                          │ 回复最高已接受ID+值      │
         │<─────────────────────────│                          │
         │ 成为新Leader，续接流程    │                          │

这个图示里，Leader正常工作时跳过了Prepare阶段，这是MultiPaxos高效的核心；只有Leader变更时才会触发Prepare，用来同步全局状态，保证不会丢数据或者出现不一致。

四、关键概念拆解 #

• 实例（Instance）：每个要达成共识的任务就是一个实例，比如一条日志、一个配置项，每个实例对应唯一的ID，按ID顺序排列就是最终的共识序列。
• Leader稳定性：Leader越稳，MultiPaxos效率越高，因为频繁切换Leader会导致每次都要走Prepare流程，回到Basic Paxos的低效率状态。
• 安全性保障：不管Leader怎么换，新Leader都会先通过Prepare拿到所有Acceptors的最新状态，确保不会覆盖已经达成共识的实例，保证全局一致性。

内容的提问来源于stack exchange，提问作者anonymousM