一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第20天，点击查看活动详情。
我们前面两讲举例说明了zookeeper的一些应用场景，在这两个场景中我们都能发现我们对zookeeper操作的时候无处不在的会出现Watcher接口的身影； 如果一个节点创建成功，ZooKeeper服务器会触发exists调用留下的路径上的watch，在create的时候，会校验我们的path， 然后将 chroot 添加到客户端路径生成serverpath（如果存在）。这里生成的serverpath方法在你getdata的时候依然会用，它会是你请求的参数属性值;request.setPath(serverPath);
那么为什么需要watcher呢，我们往下看；我们看前两讲的内容，watcher它的process里的参数WatchedEvent表明这是个事件处理方法，变成参数那说明这个是接收到了来自服务器的响应，也就是存在一个监听的过程；我们看下官方的注释：WatchedEvent表示观察者能够响应ZooKeeper上的更改，WatchedEvent可以准确地表示发生了什么、ZooKeeper的当前状态以及事件涉及的znode的路径（咦，观察者模式）；
该事件有getState()和getType()两个方法;（getWrapper()和getPath()我这里就不说了，感兴趣的自己实践下），分别表示zk客户端的连接状态和zk节点状态变化；
getState()对应的是Watcher里Event接口的枚举KeeperState；
- Unknown(-1), 不清楚原因，弃用，服务器也不会生成
- Disconnected(0), 未连接状态
- NoSyncConnected(1), 弃用，服务器不会生成
- SyncConnected(3), 连接状态
- AuthFailed(4), 身份验证失败（有身份验证？我不清楚）
- ConnectedReadOnly(5), 连接到只读服务器
- SaslAuthenticated(6), 通知客户端他们已通过 SASL 身份验证，以便他们可以使用其 SASL 授权的权限执行Zookeeper操作
- Expired(-112), 当次会话过期
- Closed(7) 客户端已关闭，
由客户端生成 getType()对应的是Watcher里Event接口的枚举EventType，我们看看它的几个状态；
- None(-1), 无 当zk客户端的连接状态发生变更
- NodeCreated(1), 节点建立
- NodeDeleted(2), 节点删除
- NodeDataChanged(3), 节点数据改变
- NodeChildrenChanged(4), 节点子节点改变（只有子节点增删才会，数据内容变化不会影响）
- DataWatchRemoved(5), 数据删除
- ChildWatchRemoved(6), 子节点删除
- PersistentWatchRemoved (7);持久化的节点删除
这是最简单的一些概念，但可以让我们知道Watcher动作是基于什么来达到接收服务器通知并作出动作的，下一讲我们细细看它的实现；
