在实际中我们客户端希望能够时时感知到数据的变化，这时候ZK的watch机制就起了很重要的作用。
一、ZooKeeper 的watch机制
ZooKeeper支持 Watch，客户端可以在znode上设置 Watch。
znode更改时，将触发并删除监视。触发监视后，客户端会收到一个数据包，说明znode已更改。
3.6.0中的新增功能：
客户端还可以在znode上设置永久性的递归监视，这些监视在触发时不会删除，并且会以递归方式触发注册znode以及所有子znode的更改。
支持 Watch的 客户端命令：
- stat path [watch]
- ls path [watch]
- ls2 path [watch]
- get path [watch]
新版本的方式：
- stat -w path
- ls -w path
- ls2 -w path
- get -w path
二、ZooKeeper 的watch栗子
使用命令get -w <path>进行监听：
如果使用get /test/test1 watch，也能够监听，但是会有一个警告：
此时使用另外一个客户端去更改 /test/test1 节点的数据，我们就可以看到原来的客户端自动收到了一个WATCHER 通知。
如果我们在进行set操作，并没有再次受到通知，这个就是ZK的一个监听机制决定的：znode更改时，将触发并删除监视，也就是说只能监听一次。
如果我们监听的是节点/test，但是我们修改的是/test/test1的节点的话，这个是监听不到的。
在3.6.x版本中支持：在znode上设置永久性的递归监视，这些监视在触发时不会删除，并且会以递归方式触发注册znode以及所有子znode的更改。那么这个怎么呢？
先看下我们当前的ZK版本是否满足3.6.x：
满足的情况下，那么要怎么操作呐？使用help看下说明：
使用方式：addWatch [-m mode] path
可选模式是[PERSISTENT，PERSISTENT_RECURSIVE]之一-默认为PERSISTENT_RECURSIVE。
PERSISTENT：只有当前监听的节点有变化了，才能收到通知，会持续的收到每次的通知。
PERSISTENT_RECURSIVE：当前节点和子节点有变化了，就会收到通知，会持续的收到每次的通知。
三、watch监听的事件类型和状态类型
事件类型：（znode节点相关的）：
EventType.NodeCreated
EventType.NodeDataChanged
EventType.NodeChildrenChanged
EventType.NodeDeleted
状态类型：（是跟客户端实例相关的）：
KeeperState.Disconnected
KeeperState.SyncConnected
KeeperState.AuthFailed
KeeperState.Expired
四、watch特性
wather的特性：一次性，客户端串行执行，轻量。
一次性（3.6.x支持永久递归监视）：对于ZK的watcher，你只需要记住一点：zookeeper有watch事件，是一次性触发的，当watch监视的数据发生变化时，通知设置了该watch的client，即watcher，由于zookeeper的监控都是一次性的，所以每次都必须监控。
客户端串行执行：客户端watcher回调的过程是一个串行同步的过程，这为我们保证了顺序，同时需要开发人员注意一点，千万不用因为一个watcher的处理逻辑影响了整个客户端的watcher回调。
轻量：WatcherEvent是ZooKeeper整个Watcher通知机制的最小通知单元。整个单元结构只包含三部分：通知状态，事件类型和节点路径。也就是说Watcher通知非常的简单，只会告诉客户端发生了事件而不会告知其具体内容，需要客户自己去进行获取，而不会直接提供具体的数据内容。
