ZooKeeper 分布式协调实战

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

选主（Master Election）

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

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

配置中心

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

分布式锁

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

羊群效应（Herd Effect）

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

临时节点的坑

• 客户端 GC 停顿或网络抖动可能导致 session 超时，临时节点被误删而锁提前释放。需结合合理的 sessionTimeout 与心跳。
• 持锁方崩溃后锁自动释放，但业务未提交，需保证操作幂等。

与 etcd 的取舍

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