Multi-Paxos与ZAB协议的核心差异
Multi-Paxos仅能保证值一旦被选定后不再更改，但无法保证：
- 选定值的内容是否符合业务逻辑（如必须先创建父节点）
- 多个操作的执行顺序性（如X必须在Y之前执行）
ZAB协议通过以下设计解决这些问题：
- 主节点（Leader）作为唯一提案者，避免并发提案
- 为每个提案分配全局唯一且递增的事务ID（zxid）
- 严格按zxid顺序提交提案
ZAB保证操作顺序性的关键机制
主节点唯一性
所有写请求必须由主节点处理，备份节点收到写请求时会转发给主节点。这避免了多节点并发提案导致的顺序混乱。
事务标识符（zxid）设计
zxid由两部分组成：
- 高32位：epoch（任期编号），领导者变更时递增
- 低32位：counter（计数器），同一任期内每个新提案递增
示例：
- 第一个提案zxid为<1,1>
- 第二个提案zxid为<1,2>
- 新领导者上任后第一个提案zxid为<2,1>
顺序广播
主节点通过TCP协议按zxid顺序广播提案，确保：
- 网络层保证消息先发先到
- 节点接收提案的顺序与发送顺序一致
顺序提交
主节点必须按zxid顺序提交提案：
- 只有前一个提案提交后，才会提交后一个提案
- 即使提案Y先到达多数派，也必须等待提案X先提交
读写请求处理流程
写请求流程
- 客户端向任意节点发送写请求（如
create /geekbang/time 456） - 备份节点将请求转发给主节点
- 主节点生成zxid并顺序广播提案
- 收到多数派确认后按zxid顺序提交
- 返回响应给客户端
读请求优化
- 默认在任何节点都可读，但可能是稍旧数据
- 需要强一致性读时，先执行
sync命令同步最新状态
故障恢复场景示例
当主节点故障时：
- 新领导者选举会产生新的epoch
- 新领导者会收集所有未提交提案
- 按原zxid顺序重新提交这些提案
- 确保即使故障恢复后操作顺序不变
与Raft的对比
虽然ZAB和Raft都保证顺序性，但ZAB：
- 更早提出（2007年 vs Raft的2013年）
- 使用zxid而非term+index作为提案标识
- 广播阶段设计更接近两阶段提交
实际应用验证
在ZooKeeper中创建嵌套节点的正确顺序：
create /geekbang123# 先创建父节点create /geekbang/time456# 再创建子节点ZAB确保这两个操作会严格按顺序执行，避免出现子节点先于父节点创建的错误。
