网易二面：ZooKeeper的ZAB协议工作原理是什么？

文章内容收录到个人网站，方便阅读：hardyfish.top/

ZAB（Zookeeper Atomic Broadcast）是 ZooKeeper 专门设计的一种原子广播协议，用于保证 数据一致性 和 故障恢复。它主要用于 主从复制（Leader-Follower） ，并确保 写请求（事务）严格有序，同时保证集群在发生 Leader 失效 时能正确恢复。

1. ZAB 协议核心目标

1. 保证数据一致性

   • ZooKeeper 采用 强一致性（Linearizability） ，所有写入（事务）按顺序执行。

2. 支持主从复制

   • 通过 Leader 负责写操作，Follower 只进行读操作，确保数据同步。

3. 故障恢复（Crash Recovery）

   • 发生故障后，保证恢复一致状态，并选举新 Leader 继续服务。

2. ZAB 工作流程

ZAB 主要由两个阶段组成：

1. 崩溃恢复（Crash Recovery）阶段：当 Leader 崩溃或网络分区时，集群需要选举一个新的 Leader 并同步数据，确保一致性。
2. 消息广播（Atomic Broadcast）阶段：当集群稳定后，Leader 通过 ZAB 协议进行事务同步，确保所有 Follower 都接收到相同的事务。

2.1 崩溃恢复阶段（Leader 选举 & 数据同步）

如果 ZooKeeper 发现 Leader 宕机或发生了网络分区，它会进入 恢复模式，重新选举新的 Leader 并确保数据一致。

步骤

1. 选举 Leader：

   • 使用 ZAB 选举算法（基于 ZXID 最大值）。
   • 拥有最大事务 ID（ZXID）的节点 优先成为 Leader。
   • 选举完成后，Leader 进入 "LOOKING" 状态，等待 Follower 连接。

2. 同步数据：

   • Follower 连接到新的 Leader，检查 Leader 最新的数据状态。
   • 如果 Follower 落后于 Leader，Leader 发送缺失的事务日志，Follower 进行同步。
   • 只有当大多数（Quorum）Follower 完成同步后，Leader 才能进入 BROADCAST（广播）模式，开始正常处理请求。

2.2 消息广播阶段（Atomic Broadcast）

当 Leader 进入 正常状态（Broadcasting） 后，它会通过 ZAB 原子广播协议 处理事务请求。

写请求流程

1. 客户端发送写请求到 Leader。

2. Leader 生成全局递增的事务 ID（ZXID） ：

   • ZXID = [epoch(时期) | counter(递增计数)]
   • 确保所有事务有全局唯一的执行顺序。

3. Leader 发送 PROPOSAL 给所有 Follower ：

   • 事务以 PROPOSAL 形式广播给所有 Follower。

4. Follower 接收 PROPOSAL 并返回 ACK：

   • 当过半 Follower (Quorum) 确认后，Leader 发送 COMMIT。

5. Leader 发送 COMMIT 并持久化：

   • Leader 持久化事务日志 并发送 COMMIT 给所有 Follower。
   • Follower 执行事务 并返回确认。

示例

客户端  -> Leader  -> Follower1, Follower2, Follower3
   写请求  ->  事务 ZXID=0x10001 (Proposal)  ->  Ack
              <-   事务已提交 (Commit)    <-

3. ZAB 关键特性

3.1 ZXID（Zookeeper Transaction ID）

• 全局唯一

  事务 ID，格式如下：

  ZXID = [epoch | counter]
  

  • epoch（时期） ：每次 Leader 选举时递增，标记不同的 Leader 时代。
  • counter（计数器） ：在同一时代内，每个事务递增，保证顺序。

示例

• 0x10000001 代表 epoch=1, counter=1
• 0x10000002 代表 epoch=1, counter=2

作用

• 通过 ZXID 选举 Leader（拥有最大 ZXID 的服务器会当选）。
• 事务严格按照 ZXID 顺序执行，确保一致性。

3.2 选举算法

ZooKeeper 采用 Fast Leader Election（FLE） 选举算法：

• 选举过程中，服务器会向其他服务器发送投票，选择 ZXID 最大的节点 作为 Leader。
• 只有当超过半数（Quorum） 的节点确认后，Leader 才能正式生效。

3.3 事务一致性

ZAB 采用 过半确认机制（Quorum） ，确保 Leader 提交事务前，至少半数 Follower 先收到：

• 只有当 N/2 + 1 以上的 Follower 确认后，事务才会 COMMIT。
• 这样即使部分 Follower 宕机，事务仍然可以继续。

4. ZAB vs Paxos vs Raft

5. 总结

• ZAB 主要用于 ZooKeeper 复制和一致性保证，由 崩溃恢复 + 原子广播 组成。
• Leader 负责处理写请求，Follower 负责读请求，通过 ZAB 原子广播协议 保证数据一致。
• 事务采用 ZXID 严格有序提交，通过 过半确认（Quorum）机制 确保强一致性。
• 如果 Leader 崩溃，ZAB 进入恢复模式，选举最大 ZXID 服务器作为新的 Leader。

总结一句话： ZAB 通过 Leader-Follower 复制 + 事务广播，确保 ZooKeeper 在 高可用、强一致 的分布式环境下正确运行。