ZooKeeper 数据模型与 ZAB 协议

Tue, 25 Aug 2026 00:00:00 +0000

ZooKeeper 的可靠性来源于其简洁的数据模型与强一致的 ZAB 协议。理解二者是正确使用 ZK 的前提。

数据模型 znode

ZK 维护一棵类似文件系统的层级树，每个节点称为 znode，可同时承载数据与子节点。其类型决定了生命周期与并发语义：

客户端与服务器建立 session，通过心跳保活，session 超时则服务器清理其临时节点。客户端可对节点注册 Watcher，节点发生变化（数据写、子节点变）时收到一次性通知，需重新注册才能继续监听。

ZAB（ZooKeeper Atomic Broadcast）是为 ZK 设计的崩溃恢复原子广播协议，保证所有事务以相同顺序被所有副本应用。

集群启动时或 Leader 宕机进入恢复阶段：选举产生新 Leader，并让各 Follower 补齐到与 Leader 相同的状态。选主依赖 zxid（事务 id）与 myid，zxid 越大代表数据越新，优先当选。

正常阶段采用类似 2PC 的广播：Leader 为每个写请求分配递增 zxid 并发起提议，Follower 写本地日志后 ACK，Leader 收到多数派 ACK 即提交并通知应用。

Tue, 25 Aug 2026 00:00:00 +0000

ZooKeeper 提供原语级的协调能力，几乎所有分布式协调需求都可基于「临时节点 + 顺序节点 + Watcher」组合实现。

每个候选者在 /election 下创建临时顺序节点，序号最小的即成为 Master。非最小节点监听其前一个节点，前驱消失时重新判断自己是否最小，从而实现故障自动转移：

/election
 ├── /n_0000000001 (master)
 ├── /n_0000000002 (watch 001)
 └── /n_0000000003 (watch 002)

将配置写入持久节点，客户端读取并注册 Watcher，配置变更时收到通知后热更新，无需重启应用。注意配置节点应控制体积，避免单次推送过大。

基于「临时顺序节点 + 监听前驱」实现公平排他锁，比简单 create 抢锁更健壮、可避免惊群。

若所有客户端都监听同一个锁节点，释放时会被同时唤醒并争抢，产生大量无效请求。正确做法是只监听比自己序号小的前一个节点，形成链式唤醒，将 O(N) 通知降为 O(1)。

etcd 基于 Raft，提供更强一致与租约（lease）、Watch 增量推送，API 更简单，云原生场景（Kubernetes）更主流；ZK 生态成熟、客户端丰富，但在超大规模 Watch 下存在性能瓶颈。新项目可优先考虑 etcd，存量 Dubbo/Hadoop 体系仍常用 ZK。