为何ZooKeeper选用ZAB而非Paxos？一致性与消息顺序疑问

1. 什么是消息重排？为何Paxos无法处理它？ #

• 消息重排：指分布式网络中，发送方按顺序发出的多条消息，因网络延迟、路由差异、节点处理速度不同等原因，到达接收节点的顺序与发送顺序不一致的现象。比如节点A先发送指令X再发Y，但副本节点B却先收到Y，后收到X。
• Paxos无法处理的原因：
  基础Paxos本质是单值共识协议，仅解决单个提案的一致性问题，没有原生支持多提案的全局顺序约束。即便Leader为提案分配编号，一旦出现Leader崩溃切换，新Leader可能会处理之前未完成的提案，此时不同阶段的提案编号可能交叉，加上网络消息重排，会导致副本日志出现临时的顺序混乱。而且基础Paxos没有机制强制所有副本必须按完全一致的全局顺序去应用提案——它只保证最终所有副本会达成相同的共识值，但不保证达成共识的过程中以及应用阶段的顺序严格一致。

2. Paxos原本并非用于原子广播？原子广播旨在实现全序，但通过为副本日志分配相同索引，Paxos最终是否能实现全序？ #

• 首先，基础Paxos确实不是为原子广播设计的。原子广播的核心要求是：所有存活节点都能收到消息（可靠性）、每条消息仅被处理一次（完整性）、所有节点按完全相同的顺序处理消息（全序）。基础Paxos的设计目标只是解决单个值的分布式共识，并非针对连续消息的广播与全序同步。
• 其次，通过Multi-Paxos（基础Paxos的扩展）为副本日志分配相同索引，确实能实现最终的全序。Multi-Paxos通过稳定的Leader为连续的提案分配递增的日志索引，确保所有副本最终会拥有索引一致、内容相同的日志，从而实现全序。但要注意：
  • 这是扩展后的Multi-Paxos才能做到的，基础Paxos本身不支持多提案的全序；
  • ZooKeeper选用ZAB而非Multi-Paxos，是因为ZAB针对ZooKeeper的特定场景做了优化——比如崩溃恢复阶段能更快地同步日志、保证Leader切换后集群能快速恢复服务，同时ZAB更贴合ZooKeeper的主备复制模型与强会话一致性需求，在性能和场景适配性上比通用的Multi-Paxos更优。

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