当前位置：首页 > news >正文

分布式专题——19 Zookeeper分布式一致性协议ZAB源码剖析 - 指南

news 2026/6/11 2:08:11

1 ZAB 协议

Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）：
- ZAB 是 Paxos 算法的简化实现，并非直接采用 Paxos 来解决分布式一致性
- 专门为分布式协调服务 Zookeeper 设计，支持崩溃恢复和原子广播这两个关键能力，Zookeeper 正是基于该协议实现功能；
基于 ZAB 协议，Zookeeper 采用**主备模式（Leader-Follower 模式）**的系统架构，以此保持集群中各个副本之间的数据一致性；
- 客户端所有写入素材的处理，都先发送到Leader 节点；
- 接着由 Leader 负责将资料复制到Follower 节点，从而保证集群内数据的一致性；
  - 数据复制过程（类似两阶段提交 2PC，但有优化）；
  - ZAB 协议在数据复制时，只需要Follower（包含 Leader 自己的 ack）有一半以上返回 Ack 信息，就可以执行提交操作；
- 这种优化大大减小了同步阻塞，同时也提高了可用性；
ZAB 协议的两种核心模式（Zookeeper 在这两种模式间切换）：
- 消息广播模式：当 Leader 服务可以正常启用时，Zookeeper 进入消息广播模式，进行正常的数据广播等操作；
- 崩溃恢复模式：当 Leader 服务不可用时，Zookeeper 进入崩溃恢复模式，以恢复集群的正常服务能力。

当 Leader 崩溃（即 Leader 失去与过半 Follower 的联系）时，Zookeeper 会进入崩溃恢复模式。此时需要解决 Leader 崩溃后的素材一致性障碍，比如：
- 假设 1：Leader 在复制信息给所有 Follower 后，还没收到 Follower 的 ack 就崩溃；
- 假设 2：Leader 收到 ack 并提交自己，且发送了部分 commit 后崩溃；
ZAB 协议为崩溃恢复定义的两个原则
- 原则 1：ZAB 协议会丢弃那些只在 Leader 提出，但没有提交的事务；
- 原则 2：ZAB 协议确保那些已经在 Leader 提交的事务，最终会被所有服务器提交；
ZAB 协议设计了下面这个选举算法，用于崩溃恢复时新 Leader 的选举：
- 该选举算法要能确保提交已经被 Leader 提交的事务，同时丢弃已经被跳过的事务；
- 为满足这一要求，选举出的新 Leader 需要拥有集群中所有机器里 ZXID（事务 ID，全局递增唯一）最大的事务；
- 这样做的好处是：可以省去 Leader 服务检查事务的提交和丢弃工作这一步操作，提升恢复效率。