概念卡片：Zookeeper 协调服务

一句话机制：Zookeeper 是一个分布式协调服务——核心是「树形节点 + Watch 监听」，客户端在节点上创建临时节点（会话断开自动删除）+ 注册 Watcher（节点变化异步通知），靠这两个机制实现注册中心、配置中心、分布式锁、选举、队列等一切「协调」场景。

六大应用场景

场景	实现方式
配置中心	发布/订阅：节点存配置，客户端加 Watcher，变更后推拉结合获取新值
负载均衡	动态 DNS：域名节点存 IP 列表，Watcher 监听 IP 变动
分布式协调	Watcher 异步通知 + 临时节点，做集群管理/上下线
Master 选举	抢建临时节点，创建成功者当 Master，失败者监听
分布式锁	抢建临时节点，成功者获锁，释放/宕机删节点，其余 Watcher 抢占
分布式队列	临时顺序节点，FIFO 或 Barrier 屏障

临时节点（Ephemeral）：会话断开自动删除 → 天然用于「存活探测 + 抢锁 + 选举」
Watch 监听：一次性触发，节点变化异步通知客户端 → 推拉结合

方案	机制	问题
方式 1：抢建同一节点	成功者获锁，失败者监听该节点	惊群效应（释放时唤醒一堆线程抢锁）
方式 2：顺序节点	每个客户端建顺序节点，只监听前一个节点	无惊群，更优

⚠️ 分布式锁的隐患：客户端获锁后与 ZK 连接断开，临时节点被删，其他客户端抢到锁，但原客户端业务还在跑 → 两客户端同时访问资源（需配合「锁续期/校验」）。

现象：分布式锁场景下，客户端 1 获锁后网络闪断，客户端 2 抢到锁，两者同时操作资源。原因：临时节点随会话断开被删，但客户端 1 的业务线程没感知。解决：锁内加「持有者校验」或续期心跳。