Zookeeper 有哪些典型的应用场景？如何实现分布式锁和服务注册发现？

核心场景与原理

Zookeeper 的典型应用场景本质是对三大能力的组合：临时节点（会话结束自动删除）、顺序节点（自带递增编号）、Watcher 机制（变更实时通知）。

分布式锁是面试追问最多的场景。实现方式：客户端在 /lock 下创建临时顺序节点，获取所有子节点后判断自己是否序号最小——最小则持锁，否则 Watch 前一个节点。释放时删除自身节点即可，会话断开临时节点也会自动清除，不会死锁。监听前序节点而非所有节点，是为了避免"羊群效应"。

服务注册与发现依赖临时节点 + Watch。服务上线创建临时节点注册地址，消费者 Watch 该目录获取实例列表。提供者宕机后节点自动消失，消费者收到通知更新列表。Dubbo 早期即用此方式做服务治理。

配置中心将配置写入持久节点，客户端 Watch 变更，改动实时推送，适合读多写少的强一致性场景。

Master 选举同样借助顺序节点——参与者各创建临时顺序节点，序号最小者成为 Master，其余 Watch 前序节点，故障时自动重选。Kafka Controller 选举便用此方式。

此外还有命名服务（顺序节点生成全局唯一 ID）、分布式队列（FIFO 与 Barrier 两种模型）、集群管理（临时节点感知成员上下线）。

生产实践要点

ZooKeeper 适合强一致性、读多写少、数据量小的协调场景，不适合海量存储或高并发写入。Kafka、HBase 仍依赖 ZK 做元数据管理和选举，但新系统更多选择 Nacos（注册+配置一体）、etcd（更轻量）等替代。

ZK 分布式锁比 Redis 锁更可靠——CP 模型保证主从切换不丢锁；代价是性能更低。金融等对锁可靠性要求高的场景优先选 ZK。

追问方向

• Watch 是一次性的，触发后须重新注册，通知有延迟，如何保证不丢事件？
• 临时顺序节点创建和序号判断之间网络分区会发生什么？
• ZK 集群 Leader 选举过程中能否对外提供服务？