ZooKeeper ZAB协议工作原理是什么？

### **ZooKeeper 的 ZAB（Zookeeper Atomic Broadcast）协议工作原理** 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** | **协议** | **用途** | **特点** | |------|------|------| | **ZAB** | ZooKeeper **强一致性** | 适用于 **主从复制**，支持崩溃恢复 | | **Paxos** | 分布式共识协议 | 适用于 **分布式数据库**，但实现复杂 | | **Raft** | 简化版 Paxos | 适用于 **分布式 KV 存储**，选举更高效 | ## **5. 总结** - **ZAB 主要用于 ZooKeeper 复制和一致性保证**，由 **崩溃恢复 + 原子广播** 组成。 - **Leader 负责处理写请求，Follower 负责读请求**，通过 **ZAB 原子广播协议** 保证数据一致。 - **事务采用 `ZXID` 严格有序提交**，通过 **过半确认（Quorum）机制** 确保强一致性。 - **如果 Leader 崩溃，ZAB 进入恢复模式，选举最大 `ZXID` 服务器作为新的 Leader**。 💡 **总结一句话：** ZAB **通过 Leader-Follower 复制 + 事务广播**，确保 ZooKeeper 在 **高可用、强一致** 的分布式环境下正确运行。