【ZAB协议】

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先提交

读写请求处理流程

写请求流程

1. 客户端向任意节点发送写请求（如create /geekbang/time 456）
2. 备份节点将请求转发给主节点
3. 主节点生成zxid并顺序广播提案
4. 收到多数派确认后按zxid顺序提交
5. 返回响应给客户端

读请求优化

• 默认在任何节点都可读，但可能是稍旧数据
• 需要强一致性读时，先执行sync命令同步最新状态

故障恢复场景示例

当主节点故障时：

1. 新领导者选举会产生新的epoch
2. 新领导者会收集所有未提交提案
3. 按原zxid顺序重新提交这些提案
4. 确保即使故障恢复后操作顺序不变

与Raft的对比

虽然ZAB和Raft都保证顺序性，但ZAB：

• 更早提出（2007年 vs Raft的2013年）
• 使用zxid而非term+index作为提案标识
• 广播阶段设计更接近两阶段提交

实际应用验证

在ZooKeeper中创建嵌套节点的正确顺序：

create /geekbang 123  # 先创建父节点
create /geekbang/time 456  # 再创建子节点

ZAB确保这两个操作会严格按顺序执行，避免出现子节点先于父节点创建的错误。