ZooKeeper 是如何实现服务注册与发现的？

简化版

ZooKeeper 用它的树形节点（ZNode）+ 临时节点 + Watcher 监听机制实现服务注册与发现：服务注册——提供者启动时，在某个服务路径下创建一个临时节点（Ephemeral Node），把自己的地址写进去；因为是临时节点，一旦提供者宕机、与 ZooKeeper 的会话断开，节点会被自动删除，天然实现下线剔除。服务发现——消费者获取服务路径下的子节点列表（就是所有可用实例地址），并注册一个 Watcher 监听该路径；一旦有实例上线/下线（子节点变化），ZooKeeper 会通知消费者，消费者刷新地址列表。

详细版

ZooKeeper 的数据模型：类似文件系统的树形结构，每个节点叫 ZNode，可以存数据、有子节点。

节点类型：

持久节点（Persistent）：创建后一直存在，除非主动删除。
临时节点（Ephemeral）：与创建它的客户端会话绑定，会话断开（客户端宕机/超时）则自动删除——服务注册用它。
顺序节点（Sequential）：节点名自动加递增序号。

实现流程：

服务注册：
  Provider 启动 → 在 /services/order-service/ 下创建【临时节点】
                  节点名/数据 = 实例地址（如 192.168.1.10:8080）
  Provider 宕机 → 会话超时 → 临时节点【自动删除】（自动下线）

服务发现：
  Consumer → getChildren("/services/order-service", watch=true)
             拿到所有子节点（实例地址列表）+ 注册 Watcher
  实例变化 → ZooKeeper 触发 Watcher → 通知 Consumer → 重新拉取列表

完整版教学

一、ZooKeeper 的数据模型：树形 ZNode

要理解 ZooKeeper 怎么做服务发现，先了解它的数据结构。ZooKeeper 的数据组织成一棵树，类似文件系统的目录结构，树上每个节点叫 ZNode：

每个 ZNode 有一个路径（如 /services/order-service/instance-1）。
每个 ZNode 可以存少量数据（如服务实例的地址）。
ZNode 可以有子节点。

服务发现正是巧妙利用了这个树形结构 + 节点的特性来组织服务信息。

二、关键：临时节点（Ephemeral Node）

ZooKeeper 的节点有几种类型，服务注册的核心是临时节点：

持久节点：创建后永久存在，除非显式删除。
临时节点（Ephemeral）：和创建它的客户端会话（session）绑定。客户端与 ZooKeeper 保持一个会话（靠心跳维持），一旦会话结束——客户端主动断开、或宕机导致心跳超时——这个临时节点会被 ZooKeeper 自动删除。

临时节点这个「会话断了节点就没了」的特性，正好完美匹配「服务实例挂了就该从注册中心消失」的需求——不需要额外的健康检查逻辑，实例宕机 = 会话断 = 临时节点自动删除 = 自动下线。这是 ZooKeeper 做服务发现的精髓。

三、服务注册：创建临时节点

服务提供者的注册过程：

提供者启动后，与 ZooKeeper 建立一个会话。
在约定的服务路径下（如 /services/order-service/）创建一个临时节点，节点名或节点数据里存放自己的地址信息（IP:端口）。
会话期间，提供者通过心跳维持这个会话，临时节点持续存在，表示「我在线」。

如果这个服务有多个实例，每个实例都在 /services/order-service/ 下创建各自的临时节点，形成一组子节点——子节点列表 = 该服务的所有在线实例。

自动下线：某个实例宕机或网络断开，它与 ZooKeeper 的会话超时，对应的临时节点被自动删除，它就从服务列表中消失了——无需任何额外操作。

四、服务发现：getChildren + Watcher 监听

服务消费者的发现过程：

消费者调用 getChildren("/services/order-service", watch=true)，获取该路径下所有子节点——也就是所有在线实例的地址列表。
同时注册一个 Watcher（监听器）在这个路径上。
消费者从地址列表里选一个实例（负载均衡）发起调用。

Watcher 机制（实时感知变化）：Watcher 是 ZooKeeper 的事件监听机制。消费者监听服务路径后，一旦该路径下的子节点发生变化（有新实例注册创建了节点、或有实例下线删除了节点），ZooKeeper 会主动通知监听的消费者。消费者收到通知后，重新拉取最新的子节点列表，更新自己缓存的地址列表。

这样消费者就能近实时地感知服务实例的上线和下线，始终使用最新的可用地址。

注意：ZooKeeper 的 Watcher 是一次性的——触发一次后就失效，消费者需要重新注册 Watcher 才能继续监听下次变化。所以实现里通常在「收到通知、重新 getChildren」时再次带上 watch=true。

五、这套机制的优缺点

优点：

临时节点自动下线：实例宕机自动清理，简洁可靠，不用单独的健康检查。
Watcher 实时通知：实例变化能及时推送给消费者。
强一致（CP）：所有消费者看到的服务列表一致（基于 ZAB 协议）。

缺点：

CP 特性带来的可用性问题：ZooKeeper 是 CP 的，Leader 选举期间不可用，此时无法注册和发现服务（见「注册中心 CP vs AP」专题）——这是它作为注册中心的最大短板。
Watcher 一次性 + 大量监听的性能压力：海量服务和消费者时，Watcher 通知的开销较大。
羊群效应：大量客户端监听同一节点，节点一变所有客户端同时被通知、同时来拉取，可能造成瞬时压力。

正因这些（尤其 CP 的可用性问题），现在服务发现更多用 Nacos（AP）等，ZooKeeper 更适合分布式锁、选主等强一致场景。

六、常见误区与追问

这道题面试时最容易丢分的地方，是把「ZooKeeper 服务发现」答成一段泛泛的组件介绍。更稳的答法是先给结论，再沿着服务注册与发现链路拆清楚流程，最后补上异常场景、数字边界和选型取舍。

回答层次	要讲清的内容	容易漏掉的边界
核心定义	ZooKeeper 常用临时节点表示服务实例，用 Watch 监听实例上下线变化	不要停在名词解释
流程机制	Provider 创建临时顺序节点 -> Consumer 读取服务目录 -> Consumer 设置 Watch -> Provider 会话断开 -> 临时节点删除并触发通知	说明谁触发、谁存储、谁通知、谁兜底
工程取舍	服务 /services/order/instance-1 作为临时节点存在，实例会话断开后节点自动删除，消费者收到 Watch 后刷新列表	注册信息不是业务数据，短暂不一致通常靠客户端缓存、重试和健康检查兜底

ZooKeeper 服务发现 面试拆解：
1. Provider 创建临时顺序节点
2. Consumer 读取服务目录
3. Consumer 设置 Watch
4. Provider 会话断开
5. 临时节点删除并触发通知

记忆钩子：先区分注册、发现、心跳、剔除和本地缓存，再说明一致性与可用性的取舍；回答时一定要落到题目中的「ZooKeeper 服务发现」，不要把相邻中间件的能力混着讲。

误区：ZooKeeper 会转发业务请求。 它只保存服务元数据和通知变化，业务请求仍由消费者直连服务实例。
误区：Watch 会一直自动触发。 ZooKeeper Watch 通常是一次性的，收到通知后需要重新注册监听。
误区：临时节点删除没有延迟。 它依赖会话超时判断，网络抖动时会有一定延迟或会话过期风险。
追问：为什么用临时节点表示实例？ 因为实例进程或连接失效后节点会自动删除，天然适合表达存活状态。
追问：ZooKeeper 做注册中心的不足是什么？ 强一致带来写入成本，频繁上下线和大规模 Watch 会形成压力。
追问：如何避免 Watch 风暴？ 控制实例规模、做本地缓存、分层订阅，避免所有客户端频繁全量读取。

七、加强记忆

ZooKeeper 用树形 ZNode + 临时节点 + Watcher 实现服务注册发现。服务注册：提供者启动时在服务路径下创建临时节点（Ephemeral）存地址，临时节点与会话绑定——实例宕机/会话超时则自动删除，天然实现下线剔除（无需额外健康检查）；一个服务的多个实例 = 该路径下的一组子节点。服务发现：消费者 getChildren 拉取子节点（实例地址列表）并注册 Watcher 监听，实例上下线（子节点变化）时 ZooKeeper 主动通知消费者刷新列表（Watcher 一次性，需重新注册）。优点：临时节点自动下线、Watcher 实时、强一致。缺点：CP 特性使 Leader 选举期间不可用、羊群效应。口诀：临时节点管注册（断线自动删）、Watcher 管发现（变化即通知）。

简化版

详细版