ZooKeeper

Difficulty: Advanced
Status: Stable
Last reviewed: 2026年8月

This content is not available in your language yet.

ZooKeeper 用有序更新、临时节点和一次性 Watcher 提供协调原语；源码主线是客户端请求进入 ZooKeeperServer，由 Leader 通过 ZAB 提交，再由各节点的 DataTree 应用。

本册问题地图

ZooKeeper 要沿着“会话、写入、通知、恢复”四条线阅读：

ZAB 为什么需要 Leader 和多数派确认？ 写请求必须形成有序 proposal，并在多数节点确认后提交，保证不同节点不会各自提交冲突历史。
日志和快照为什么并存？ 日志保留增量操作，快照提供快速恢复点；恢复时先加载快照，再重放其后的日志。
Session 如何影响临时节点？ 临时节点的生命周期绑定会话，连接短暂断开不一定立即删除，超时后服务端才判定会话失效。
Watcher 为什么是一次性通知？ 它只报告状态变化，不替客户端保存持续订阅；收到通知后必须重新读取并重新注册。
读请求是否都线性一致？ 本地读可能看到本节点视角，写入通过 Leader 顺序提交；需要强一致读时必须使用相应同步语义。

版本快照

项	值
仓库	`apache/zookeeper`
本地路径	`E:\source\java\base\zookeeper`
分支	`master`
Commit	`1b6a4c20`（2026-08-10）
最近 tag	—

模块地图

模块	职责	关键入口
`zookeeper-server`	服务端、选举、ZAB、数据树	`QuorumPeerMain`、`ZooKeeperServer`
`zookeeper-client`	Java/C 客户端协议与连接	`ZooKeeper`、`ClientCnxn`
`zookeeper-jute`	请求、事务和响应序列化	`Record`、`BinaryInputArchive`
`zookeeper-specifications`	ZAB 与系统模型	`Zab.tla`

读码入口

QuorumPeerMain#runFromConfig 启动 quorum。
QuorumPeer#run 在 LOOKING/FOLLOWING/LEADING 间切换。
Leader#propose、Leader#commit 追踪 ZAB 提案。
ZooKeeperServer#submitRequest 进入请求处理链。
DataTree、WatchManager、FileTxnSnapLog 分别对应状态、通知、持久化。

本册目录

横向对照

对象	对照点
etcd	都用共识保证线性化，但 etcd 以 Raft/MVCC 为主，ZooKeeper 以 ZAB/有序 zxid 为主
Nacos	都提供注册协调，ZooKeeper 的临时节点和 Watcher 更接近底层协调原语