Zookeeper 的典型应用场景有哪些？

面试考察点

1. 核心能力理解：面试官不仅仅是想知道你背了几个场景名，更是想知道你是否理解 ZooKeeper 的底层能力（如临时节点、顺序节点、Watch 机制）是如何支撑这些场景的。
2. 实践经验：你是否在实际项目中用过 ZooKeeper？是直接用原生 API 还是基于 Curator 框架？踩过什么坑？
3. 技术选型意识：了解 ZooKeeper 的适用边界，知道哪些场景该用、哪些场景现在有更好的替代方案。

核心答案

ZooKeeper 的典型应用场景主要有 5 大类：

应用场景	核心原理	典型使用方
分布式锁	临时顺序节点 + Watch	需要互斥访问的业务
服务注册与发现	临时节点 + Watch	Dubbo、Kafka（旧版）
分布式配置中心	数据节点 + Watch	统一配置管理
分布式协调/通知	Watcher 机制	分布式事务、任务分配
分布式屏障	顺序节点 + Watch	并行任务汇合点

这 5 个场景的底层其实就依赖 ZooKeeper 的三大核心能力：临时节点（会话结束自动删除）、顺序节点（自带递增编号）、Watch 机制（变更实时通知）。理解了这仨，上面的场景都是组合运用。

深度解析

一、服务注册与发现

这个应该是大家最熟悉的场景了。Dubbo 默认就用 ZooKeeper 做注册中心。

上图展示了服务注册与发现的完整流程。关键点在于：

• Provider 注册：服务提供者启动时，在 /services/order 下创建一个临时节点，节点数据保存自己的 IP 和端口信息。
• Consumer 订阅：服务消费者启动时，读取 /services/order 下所有子节点，获取可用的 Provider 列表，同时在这些节点上注册 Watch。
• 自动摘除：Provider 宕机后，会话失效，临时节点自动删除，Consumer 通过 Watch 收到通知，更新本地服务列表。

为什么用临时节点？因为临时节点跟会话绑定，Provider 挂了之后节点自动消失，不需要手动做下线操作。这个设计确实优雅。

二、分布式锁

分布式锁是面试追问频率最高的场景。核心思路：利用 ZooKeeper 的临时顺序节点实现公平锁。

上图展示了基于临时顺序节点的分布式锁实现。核心流程：

• 创建节点：每个客户端在 /lock 下创建临时顺序节点（如 node-000001、node-000002）。
• 判断顺序：获取 /lock 下所有子节点，判断自己是否为序号最小的那个。最小则获得锁。
• 等待通知：如果不是最小的，就 Watch 自己前一个节点（注意，不是 Watch 所有节点，这叫"羊群效应"的优化）。
• 释放锁：客户端完成操作后删除自己的节点，或者会话断开后临时节点自动删除，下一个客户端收到通知。

用临时节点而不是持久节点的好处是：客户端崩溃后锁会自动释放，不会出现死锁。这个设计比基于数据库的分布式锁靠谱多了。

实际项目中推荐直接用 Curator 的 InterProcessMutex，它已经帮你处理好了可重入、锁超时等细节。

三、分布式配置中心

把配置存在 ZooKeeper 的数据节点上，客户端通过 Watch 机制监听配置变化，实现配置的动态更新。

这个场景比较直观，就不展开太多了。需要注意的是，ZooKeeper 做配置中心有个缺点：它不适合存储大量配置数据，因为 ZooKeeper 的设计初衷是存协调元数据，不是存业务数据。如果你的配置量很大，Apollo 或 Nacos 是更好的选择。

四、分布式协调与通知

利用 Watcher 机制，实现分布式系统各组件之间的协调和通知。

典型例子：

• 分布式任务分配：主节点将任务写入 ZNode，工作节点 Watch 任务节点，有新任务时收到通知并抢占。
• 集群选主：多个服务实例争抢创建同一个临时节点，创建成功的成为 Leader，其余的 Watch 这个节点，Leader 宕机后自动重新选举。
• 分布式屏障（Barrier）：所有参与者创建临时节点，当节点数达到阈值时，打开屏障，所有参与者同时开始执行。

五、集群管理与 Master 选举

上图展示了 Master 选举的过程。关键点：

• 所有服务实例尝试创建同一个临时节点 /master，只有一个能成功。
• 成功的就是 Leader，失败的在 /master 节点上注册 Watch。
• Leader 宕机后，临时节点自动删除，触发通知，其他实例再次竞争。

这种方案简单可靠，Kafka 旧版的 Controller 选举就是用的这个机制。

面试高频追问

1. ZooKeeper 分布式锁和 Redis 分布式锁有什么区别？怎么选？

   • ZooKeeper 是 CP 模型，强一致性，锁的可靠性更高；Redis 是 AP 模型，性能更好但在主从切换时可能丢失锁信息。
   • 对锁可靠性要求高（如金融场景）选 ZooKeeper；对性能要求高（如高并发限流）选 Redis。

2. ZooKeeper 的 Watch 机制有什么限制？

   • Watch 是一次性的，触发后需要重新注册。
   • Watch 通知是异步的，从事件发生到客户端收到通知有延迟。

3. 现在还有哪些替代方案？

   • 服务注册发现：Nacos、Consul、Eureka。
   • 配置中心：Apollo、Nacos。
   • 分布式锁：Redis（RedLock）、etcd。
   • 不过 ZooKeeper 在 Hadoop、Kafka、HBase 生态中仍然广泛使用。

常见面试变体

• "ZooKeeper 的临时节点和持久节点有什么区别？"
• "如何用 ZooKeeper 实现分布式锁？"
• "ZooKeeper 和 Nacos 做注册中心有什么区别？"
• "ZooKeeper 的 Watch 机制是怎样的？"

记忆口诀

五大场景一句话："注协锁配屏" —— 注册发现、协调通知、分布式锁、配置中心、屏障/选举。

核心能力三件套：临时节点（自动清理）、顺序节点（公平排队）、Watch（实时通知）。

总结

ZooKeeper 的典型应用场景本质上都是对其三大核心能力的组合运用：临时节点保证异常自动清理，顺序节点实现公平排序，Watch 机制实现实时通知。面试时先报出 5 大场景，再挑一两个展开说原理，面试官基本就满意了。别忘了一提技术选型意识，说明你知道 Nacos、etcd 这些替代方案，这会让面试官觉得你不只是会背八股文，还有真实的技术判断力。