Zookeeper通知机制为啥用watch？他是怎样设计的
Zookeeper是一个广受大家喜爱的框架，他能搞定分布式锁，也能实现服务之间更好的调用，而他是通过通知机制来实现的，那么他是怎么实现的呢？下面就来一步一步聊一聊
根据上面的知识基础，我们基本了解了zookeeper的面貌，下面就是他的通知机制的设计
zookeeper的客户端向zookeeper发送要执行的任务，发完了之后一种设计是每次客户端都去查询这个任务有没有被执行，这样查很多遍显然是不够聪明的
所以zookeeper采用了通知的机制，这种机制就是在zookeeper上设置一个监视点，当客户端第一次访问的时候把监视点watcher放到zookeeper上，然后客户端就不用管，这时候消费者，访问了zookeeper，处理了这个任务，那么watch就登场了，他会主动向客户端发送消息，告诉客户端任务被处理了，然后watch自己就移除掉，这样就不用客户端来没一次查询了。
这个就是watch的意义，是一种很聪明的做法，依据他就知道为什么代用zookeeper要使用watch。
Zookeeper深入原理(2) - Watcher 监听机制
Zookeeper 提供了分布式 数据发布和订阅功能,一个典型的发布和订阅模型系统定义了一种一对多的订阅关系,能让多个订阅者同时监听某一个主题的对象,当这个主题对象自身状态变化时,会通知所有订阅者,使它们能够做出相应的处理。
Zookeeper中引入了Watcher机制来实现这种分布式通知的功能。Zookeeper允许客户端向服务端注册一个Watcher监听。当服务端的一些事件出发了Watcher监听机制,就会向指定得客户端发送一个事件通知来实现分布式的通知功能。
触发事件种类: 节点创建、节点删除、节点改变、子节点改变等。
总的来说可以概括Watcher分为以下三个过程: 客户端向服务端注册Watcher、服务端事件触发Watcher、客户端回调Watcher得到触发事件情况。
一次性触发
事件触发监听,一个Watcher Event 就会被发送到设置监听的客户端,这种效果是一次性的,后续再发生同样的事件,不会触发机制。
事件封装
Zookeeper使用WatchedEvent对象来封装服务端事件并传递。
WatchedEvent包含每一个事件的三个基本属性:
通知状态(keeperState) 、事件类型(EventType)、节点路径(path)
Event 异步发送
Watcher的通知事件是从服务端异步发送到客户端的。
先注册再触发
Zookeeper的Watch机制,必须客户端在服务端注册监听,服务器端触发监听机制,才会通知客户端。
同一个事件类型在不同的通知状态中代表的含义有所不同，下表列举了常见的通知状态和事件类型。
事件封装:Watcher得到的事件是被封装过的, 包括三个内容keeperState, eventType, path
其中连接状态事件(type=None, path=null)不需要客户端注册，客户端只要有需要直接处理就行了。
4.Shell 客户端设置Watcher
设置节点数据变动监听：
通过另一个客户端更改节点数据：
此时设置监听的节点收到通知：
5.ZooKeeperJava API操作
这里操作Zookeeper的JavaAPI使用的是一套zookeeper客户端框架 Curator ，解决了很多Zookeeper客户端非常底层的细节开发工作 。
Curator包含了几个包：
curator-framework ：对zookeeper的底层api的一些封装
curator-recipes ：封装了一些高级特性，如：Cache事件监听、选举、分布式锁、分布式计数器等
Maven依赖(使用curator的版本：2.12.0，对应Zookeeper的版本为：3.4.x，如果跨版本会有兼容性问题，很有可能导致节点操作失败)：
1. 引入maven坐标
2.节点的操作
