本文是大数据系列第 31 篇，深入剖析 ZooKeeper 的 Leader 选举机制和 ZAB（ZooKeeper Atomic Broadcast）协议实现原理。

完整图文版（含截图）：CSDN 原文 | 掘金

ZooKeeper 核心特性回顾

ZooKeeper 提供以下分布式一致性保证：

  • 顺序一致性：所有更新操作按提交顺序执行
  • 原子性：更新要么全部成功，要么全部失败
  • 单一系统视图：所有客户端看到一致的数据状态
  • 可靠性：一旦更新完成，结果持久保存直到被覆盖
  • 时效性：客户端在有限时间内必然读到最新数据

数据模型采用类似 Unix 文件系统的 ZNode 树形结构，节点默认最多存储 1MB 数据，分为持久节点（PERSISTENT）和临时节点（EPHEMERAL）两种类型，临时节点在会话结束后自动删除。

Watcher 监听机制

客户端可以向节点注册 Watcher，当节点数据或子节点列表发生变化时收到通知。Watcher 是一次性触发的，收到通知后需要重新注册。

典型应用场景

场景实现方式
服务注册发现Dubbo Provider 在 /dubbo/com.example.Service/providers 下创建临时节点
配置管理应用监听 /config/myapp 节点，动态感知配置变更
消息队列生产者创建顺序节点，消费者监听新节点出现
分布式锁多个客户端竞争创建同一临时节点，成功者获得锁
集群管理临时节点代表存活节点，节点下线后自动删除

Leader 选举机制

核心原则

  • 过半原则：集群超过半数节点存活时才能正常对外提供服务
  • 奇数节点：推荐部署 3、5、7 等奇数节点，以最大化容错效率
  • 角色划分：集群中只有一个 Leader，其余全部为 Follower

初始启动选举（5 节点示例）

以 5 节点集群为例，说明首次启动时的选举过程：

  1. 节点 1 启动：发出选举提案，由于没有其他节点响应，进入 LOOKING 状态
  2. 节点 2 启动：与节点 1 交换选票，ID 较大的节点 2 胜出，但仍未达到半数 → 继续 LOOKING
  3. 节点 3 启动：三个节点达成共识，节点 3 ID 最大，获得 3 票超过半数 → 节点 3 成为 LEADER
  4. 节点 4 启动：感知到已存在 Leader → 直接成为 FOLLOWER
  5. 节点 5 启动：同上，直接加入为 FOLLOWER

非初次选举

集群运行过程中 Leader 宕机后的重新选举，优先选举 ZXID（事务 ID）最高的节点作为新 Leader，ZXID 反映了节点持有的最新数据。

ZAB 协议详解

协议概述

ZAB（ZooKeeper Atomic Broadcast）是专为 ZooKeeper 设计的原子广播协议，基于 Paxos 思想优化而来，保证：

  • 消息要么原子性地投递到所有节点，要么一个都不投递
  • 全局严格的消息有序性
  • 可靠的最终一致性

主备架构

所有客户端的写请求都必须经过 Leader 节点，Leader 负责将更新复制到所有 Follower。读请求可以由任意 Follower 直接处理。

消息广播三阶段

阶段一：Proposal（提案）

Leader 为每个写请求分配唯一的 ZXID，将请求封装为事务提案，通过 FIFO 队列依次发送给所有 Follower。

阶段二：ACK（确认）

每个 Follower 接收提案后，先写入本地事务日志，再向 Leader 回复 ACK。Leader 等待超过半数节点（含自身）的 ACK。例如 5 节点集群需要至少 3 个 ACK。

阶段三：Commit（提交）

Leader 在本地提交事务，然后向所有 Follower 广播 Commit 消息，Follower 收到后将提案应用到本地状态机。

与经典二阶段提交的区别：采用多数派而非全员确认，避免单节点故障导致阻塞。

Leader 故障恢复

故障影响

  • 重新选举期间服务暂时中断
  • 客户端收到 ConnectionLoss 异常，需要实现重试逻辑
  • 进行中的事务可能被中断

ZAB 恢复保证

  • 已提交事务：新 Leader 通过比较各节点 ZXID，确保已被多数节点确认的事务最终应用到所有节点
  • 未提交事务：仅被少数节点（如 2/5）确认的事务将被新 Leader 丢弃，保持一致性

恢复时间：典型 Leader 重新选举耗时 200~400 毫秒。

生产部署建议

  • 节点数量：推荐奇数节点，常见 3 节点（容忍 1 个故障）或 5 节点（容忍 2 个故障）
  • 容错能力：N 个节点的集群可容忍 (N-1)/2 个节点故障
  • 写入路由：所有写操作经 Leader，读操作可分散到 Follower 提升吞吐
  • 客户端重试：业务代码必须处理 ConnectionLoss，实现幂等重试

小结

ZooKeeper 通过 ZAB 协议的 Leader 选举和原子广播机制实现了企业级分布式协调能力。“过半数节点”的仲裁原则结合 ZXID 排序，在保证强一致性的同时提供了良好的容错能力，是生产级分布式系统协调服务的成熟选择。