如图：在ZooKeeper中，使用Watcher机制来实现通知功能。ZooKeeper允许客户端向服务端注册一个Watcher监听。客户端将watcher对象存储在WatchManager的同时，会向Zookeeper服务器注册Watcher。当ZooKeeper服务器端触发Watcher事件后，会向客户端发送通知，客户端线程从WatchManager中取出对应的Watcher对象来执行回调逻辑。
事件类型
NodeCreated Watcher监听的节点被创建
NodeDeleted Watcher监听的节点被删除
NodeDataChanged Watcher监听的节点内容变化
NodeChildChanged Watcher监听的节点的子节点内容变化
Watcher接口
定义了时间通知的相关逻辑：通知状态KeeperState、事件类型EventType、回调方法：process（WatchedEvent event）。
process方法的参数WatchedEvent包含了事件的三个基本属性：通知状态（keeperState），事件类型（EventType）和节点路径（path）。ZooKeeper使用WatchedEvent对象来封装服务端事件并传递给Watcher，从而方便回调方法process对服务端事件进行处理。
WatchedEvent和WatcherEvent表示其实的是同一个事物，作用都是对一个服务端事件的封装。不同的是，WatchedEvent是一个逻辑事件，其作用是描述服务端和客户端程序执行过程中所需的逻辑对象，而WatcherEvent实现了序列化接口，用于网络传输。
服务端在生成WatchedEvent事件之后，会调用getWrapper()方法将自己包装成一个可序列化的WatcherEvent事件，以便通过网络传输到客户端。客户端在接收到服务端的这个事件对象后，首先会将WatcherEvent还原成一个WatchedEvent事件，并传递给process方法处理，回调方法process根据入参就能够解析出完整的服务端事件了。
可以看到，WatchedEvent和WatcherEvent对ZooKeeper服务端事件的封装都是很简单的。服务端只会发送给客户端一个事件类型，通知状态和节点路径，客户端无法直接从该事件中获取到对应数据节点的原始数据内容以及变更后的新数据内容，也就是说需要客户端在此主动去重新获取数据。
工作机制
ZooKeeper的watcher机制，可以概括为以下三个过程：客户单注册Watcher，服务端处理Watcher和客户端回调Watcher
客户端注册Watch
public ZooKeeper（String connectString，int sessionTimeout,Watcher watcher）;
在创建一个ZooKeeper客户单的实例时可以向构造方法中传入一个默认的Watcher，这个Watcher将作为这个ZooKeeper会话期间的默认Watcher，会一直被保存在客户端ZKWatchManager的defaultWatcher中。另外，ZooKeeper客户端也可以通过getData，getChildren和exist三个接口来向ZooKeeper服务器注册Watcher，无论使用哪种方式，注册Watcher的工作原理都是一致的，这里我们以getData这个接口为例来说明。getData接口用于获取指定节点的数据内容，主要有两个方法：
public byte[] getData(String path,boolean watch,Stat stat)
public byte[] getData(final String path,Watcher watcher,Stat stat)
这两个接口上都可以进行Watch的注册，第一个接口通过一个boolean参数来标识是否使用上文提到的默认Watcher来进行注册，具体的注册逻辑和第二个接口是一致的。
在向getData接口注册Watcher后，客户端首先会对当前客户端请求request进行标记，将其设置为“使用Watcher监听”，同时会封装一个Watcher的注册信息WatchRegistration对象，用于暂时保存数据节点的路径和Watcher的对应关系，具体的逻辑代码如下：
其中的cnxn是clientcnxn对象，几个重要参数需要解释一下，h是存放的类型，比如这里是getdata，调用exist的情况下这里就是exist，request封装了getdata方法中传递的path(节点路径)和watcher。在ZooKeeper中，Packet数据包是最小的通信协议单元，用于进行客户端与服务端之间的网络传输，任何需要传输的额对应都需要包装成一个Packet对象。因此，在ClientCnxn中WatchRegistration又会被封装到Packet中，然后放入发送队列（outgoingquen）中等待客户端发送。
随后，ZooKeeper客户端向服务端发送这个请求，同时等待请求的返回。完成请求发送后，会由客户端SendThread线程的readResponse方法负责接收来自服务端的响应，finishPacket方法会从Packet中取出对应的Watcher并注册到ZkWatchManager中去。
客户端将Watcher对象给ZKWatchManager，最终保存到dataWatches中去。ZKWatchManager.dataWatches是一个Map<String,Set<Watcher>>类型的数据结构。这样就完成了客户端的注册。主要做了两件事情，1.封装发送到服务端的注册Watcher请求，并且发送。2.请求发送后，客户端的SendThread线程的readResponse方法接收到服务端的响应后注册Watcher到客户端的ZkWatchManager中。
服务端处理Watcher
服务端接收Watcher后的存储过程：
case OpCode.getData:{
...
byte b[] = zks.getZKDatabase().getData(getDataRequest.getPath(), stat, getDataRequest.getWatch()?cnxn:null);
rsp = new GetDataResponse(b,stat);
break;
}
从getData请求的处理逻辑中，我们可以看到，当getDataRequest.getWatch()为true的时候，ZooKeeper就认为当前客户端请求需要进行Watcher注册，于是就会将当前的ServerCnxn对象和数据节点路径传入getData方法中去。那么为什么要传入ServerCnxn呢？ServerCnxn是一个ZooKeeper客户端和服务器之间的连接接口，代表了一个客户端和服务器的连接。ServerCnxn接口的默认实现是NIOServerCnxn，同时从3.4.0版本开始，引入了基于Netty的实现：NettyServerCnxn。无论采用哪种实现方式，都实现了Watcher的process接口，因此我们可以把ServerCnxn看作是一个Watcher对象。数据节点的节点路径和ServerCnxn最终会被存储在WatcherManager的watchTable和watch2Paths中。
WatchManager是ZooKeeper服务端Watcher的管理者，其内部管理的watchTable和watch2Pashs两个存储结构，分别从两个维度对Watcher进行存储。
watchTable是从数据节点路径的粒度来托管Watcher
watch2Paths是从Watcher的粒度来控制事件触发需要触发的数据节点。
同时，WatchManager还负责Watcher事件的触发，并移除那些已经被触发的Watcher。注意，WatchManager只是一个统称，在服务端，DataTree中会托管两个WatchManager，分别是dataWatches和childWatches，分别对应数据变更Watcher和子节点变更Watcher。在本例中，因为是getData接口，因此会被存储在dataWatches中。
事件触发
setdata()会触发NodeDataChanged事件。其中调用了triggerWatch方法，我们来看triggerWatch方法中又做了什么：
这个方法主要是做了事件的触发。其过程如下：
第一步：封装WatchedEvent
第二步：检测watchTable中是否有对应的Watcher
根据数据节点路径从watchTable中取出对应的Watcher。如果没有，说明没有任何客户端在该数据节点上注册过Watcher，直接退出。而如果找到了这个Watcher，会将其提取出来，同时会直接从watchTable和watch2Paths中将其删除——从这里我们也可以看出，Watcher在服务端是一次性的，即触发一次就失效了。
第三步.调用process方法来触发Watcher。
在这一步中，会逐个依次地调用从步骤2中找出的所有Water的process方法。那么这里的process方法究竟做了什么呢？在上文中我们已经提到，对于需要注册Watcher的请求，ZooKeeper会把当前请求对应的ServerCnxn作为一个Watcher进行存储，因此，这里的process方法，事实上就是ServerCnxn的对应方法：
标记“-1”，标识当前是一个通知。
将WawtchedEvent包装成WatcherEvent。
通过sendResponse向客户端发送通知。
客户端回调Watcher
客户端收到服务端的响应，通过SendThread.readResponse（）处理，解析到replyheader为-1，就知道这是一个通知了，通知事件主要是通过EventThread来处理的，所以这里再去调用EventThread.queueEvent方法。类似于服务端，queueEvent方法首先会根据该通知事件，从ZKWatchManager中取出所有相关的Watcher。
获取到相关的额所有Watcher后，会将其放入waitingEvents这个队列中去。WaitingEvents是一个待处理Watcher队列，EventThread的run方法会不断对该队列进行处理。
