不是吧！不会还不懂Zookeeper的watcher机制吧！一文深入源码分析

我们可以使用 zookeeper 作为注册中心来实现服务的注册与发现，curator 框架提供了 curator-x-discovery 扩展实现了开箱即用的服务注册发现，但更多时候我们还是选择自己去实现，那这个时候我们需要额外关注 zookeeper 的 1 个特性，即 wathcer。

在微服务场景中，watcher 机制主要提供了服务通知功能，比如 Instance1 这个实例在 Service1 服务节点下注册了一个 emphemeral 子节点后，它的某个服务消费者根据依赖配置在 Service1 节点上注册了一个子节点 watcher，就如图中的红钥匙。子节点类型的 watcher 会观测 Service1 的子节点，即 InstanceX 节点，但不会观测孙子节点 config1。那么当 Instance1 节点挂掉之后，watcher 可以做到通知给注册自身的那个服务消费者，通知完一次后 wacther 也就被销毁了。

 

wacther 原理框架

 

zookeeper 的 watcher 主要由 client、server 以及 watchManager 之间配合完成，包括 watcher 注册以及触发 2 个阶段。

在 client 端注册表为 ZkWatchManager，其中包括了 dataWatches、existWatches 以及 childWatches。在 server 端的注册表在 DataTree 类中，封装了 2 类 WatchManager，即 dataWatches 和 existWatches。dataWatches 代表当前节点的数据监听，childWathes 代表子节点监听，与 client 比少的 existWatches 也很容易理解，因为节点是否存在需要客户端去判断。

注册阶段客户端的 getData 和 exists 请求可以注册 dataWatches，getChilden 可以注册 childWatches。而触发阶段，setData 请求会触发当前节点 dataWatches，create 请求会触发当前节点 dataWatches 以及父节点的 childWatches，delete 请求则会触发当前节点、父节点、子节点的 dataWatches，以及父节点的 childWatches。

watchManager包含两个非常重要的数据结构：watchTable和watch2Paths。前者表示path-set<watcher>，后者表示watcher-set<path>。注意这里的watcher含义表示