1.Watch机制
所有对 ZooKeeper 的读操作，都可附带一个 Watch 。一旦相应的数据有变化，该 Watch 即被触发。
Watch 有如下特点：
主动推送：Watch被触发时，由 ZooKeeper 服务器主动将更新推送给客户端，而不需要客户端轮询。
一次性：数据变化时，Watch 只会被触发一次。如果客户端想得到后续更新的通知，必须要在 Watch 被触发后重新注册一个 Watch。
可见性：如果一个客户端在读请求中附带 Watch，Watch 被触发的同时再次读取数据，客户端在得到 Watch 消息之前肯定不可能看到更新后的数据。换句话说，更新通知先于更新结果。
顺序性：如果多个更新触发了多个 Watch ，那 Watch 被触发的顺序与更新顺序一致。
2.Zookeeper服务器角色
Leader:一个Zookeeper集群同时有且只能有一个Leader工作，它负责处理维护和Follower和Observer之间的心跳连接，所有的写操作必须通过Leader处理，然后由Leader将写操作广播到其他服务器.
Follower:一个Zookeeper集群可以存在多个Follower,它会响应Leader的心跳，所有的Follower可以直接处理读请求并返回给客户端，同时会把写请求转发给Leader处理，参与Leader投票。
Observer:角色和Follower类似，但是没用投票权。
3.Zookeeper如何保证数据一致性
为了保证写操作的一致性与可用性，ZooKeeper专门设计了一种名为原子广播（ZAB）的支持崩溃恢复的一致性协议。基于该协议，ZooKeeper实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致性。
根据ZAB协议，所有的写操作都必须通过Leader完成，Leader写入本地日志后再复制到所有的Follower节点。
一旦Leader节点无法工作，ZAB协议能够自动从Follower节点中重新选出一个合适的替代者，即新的Leader，该过程即为领导选举。该领导选举过程，是ZAB协议中最为重要和复杂的过程。
Leader写操作
1.客户端向Leader发起写请求
2.Leader将写请求以Proposal的形式发给所有Follower并等待ACK
3.Follower收到Leader的Proposal后返回ACK
4.Leader得到过半数的ACK（Leader对自己默认有一个ACK）后向所有的Follower和Observer发送Commmit
5.Leader将处理结果返回给客户端
Follower和Observer写操作
Follower/Observer均可接受写请求，但不能直接处理，而需要将写请求转发给Leader处理
除了多了一步请求转发，其它流程与直接写Leader无任何区别
