ZooKeeper 配置、选主、锁与注册发现

ZooKeeper 的高级能力不是四套魔法 API，而是 znode、临时节点、顺序节点和 Watch 的组合。生产项目优先使用 Curator recipe，并补上 fencing token；不要手写一个“创建节点成功就是永远持锁”的实现。

Table of contents

四种组合

• 配置：持久节点保存版本化的小配置，Watch 唤醒客户端重新读取。
• 服务发现：实例创建临时节点，消费者监听实例目录。
• 选主：候选者创建临时顺序节点，序号最小者成为 Leader。
• 锁：与选主相似，但每个候选者只 Watch 前一个节点。

只监听前驱节点能避免羊群效应。羊群效应指一个节点变化唤醒所有等待者，造成瞬时请求洪峰。

锁为什么还需要 fencing token

客户端 A 获得锁后发生长时间停顿，会话过期；客户端 B 随后获得锁。A 恢复后若继续写数据库，两个“持锁者”会并发修改。解决方法是让锁服务返回单调递增的 fencing token，资源端只接受比已见 token 更大的请求。

A 获得 token=41 → 暂停并过期
B 获得 token=42 → 存储接受写入
A 恢复携带 41 → 存储拒绝旧持有者

因此“锁释放成功”不能成为业务正确性的前提。临界区操作还应幂等，资源端负责识别过期所有者。

哪些场景不要用

不要把大对象、高频业务数据、消息正文或秒级海量计数写入 ZooKeeper。它的优势是小规模、强一致的协调元数据。服务发现若已经由 Kubernetes Service 或注册中心承担，再加 ZooKeeper 会形成两份真相。

上线前演练会话过期、Leader 停顿、节点重复注册和 Watch 重建。指标至少包括会话状态、操作延迟、未完成请求、znode 数量和数据大小。参考 Apache Curator Recipes选择成熟实现。

下一步

继续阅读08-06 Leader 选举与 ZAB 协议，理解 ZooKeeper 集群怎样复制这些状态。