ZAB协议工作原理是什么?

ZAB（Zookeeper Atomic Broadcast）是 ZooKeeper 专门设计的一种原子广播协议，用于保证 数据一致性 和 故障恢复。

它主要用于 主从复制（Leader-Follower），并确保 写请求（事务）严格有序，同时保证集群在发生 Leader 失效 时能正确恢复。

ZAB 协议核心目标

保证数据一致性：

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

支持主从复制：

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

故障恢复（Crash Recovery）：

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

ZAB 工作流程

ZAB 主要由两个阶段组成：

崩溃恢复（Crash Recovery）阶段：

  • 当 Leader 崩溃或网络分区时，集群需要选举一个新的 Leader 并同步数据，确保一致性。

消息广播（Atomic Broadcast）阶段：

  • 当集群稳定后，Leader 通过 ZAB 协议进行事务同步，确保所有 Follower 都接收到相同的事务。

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

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

步骤

选举 Leader：

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

同步数据：

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

消息广播阶段（Atomic Broadcast）

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

写请求流程

客户端发送写请求到 Leader。

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

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

Leader 发送 PROPOSAL 给所有 Follower：

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

Follower 接收 PROPOSAL 并返回 ACK：

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

Leader 发送 COMMIT 并持久化：

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

ZAB 关键特性

ZXID（Zookeeper Transaction ID）

全局唯一事务 ID，格式如下：

1
ZXID = [epoch | counter]

epoch（时期）：每次 Leader 选举时递增，标记不同的 Leader 时代。

counter（计数器）：在同一时代内，每个事务递增，保证顺序。

示例

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

作用

通过 ZXID 选举 Leader（拥有最大 ZXID 的服务器会当选）。

事务严格按照 ZXID 顺序执行，确保一致性。

选举算法

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

选举过程中，服务器会向其他服务器发送投票，选择 ZXID 最大的节点 作为 Leader。

只有当超过半数（Quorum）的节点确认后，Leader 才能正式生效。

事务一致性

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

只有当 N/2 + 1 以上的 Follower 确认后，事务才会 COMMIT。

这样即使部分 Follower 宕机，事务仍然可以继续。

ZAB vs Paxos VS Raft

协议 用途 特点
ZAB ZooKeeper 强一致性 适用于 主从复制，支持崩溃恢复
Paxos 分布式共识协议 适用于 分布式数据库，但实现复杂
Raft 简化版 Paxos 适用于 分布式 KV 存储，选举更高效

总结

ZAB 主要用于 ZooKeeper 复制和一致性保证，由 崩溃恢复 + 原子广播 组成。

Leader 负责处理写请求，Follower 负责读请求，通过 ZAB 原子广播协议 保证数据一致。

事务采用 ZXID 严格有序提交，通过 过半确认（Quorum）机制 确保强一致性。

如果 Leader 崩溃，ZAB 进入恢复模式，选举最大 ZXID 服务器作为新的 Leader。

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