一、请描述一下 Zookeeper 的通知机制是什么？
Zookeeper 允许客户端向服务端的某个 znode 注册一个 Watcher 监听，当服务端的一些指定事件触发了这个 Watcher ，服务端会向指定客户端发送一个事件通知来实现分布式的通知功能，然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。
大致分为三个步骤：
客户端注册 Watcher
1、调用 getData、getChildren、exist 三个 API ，传入Watcher 对象。
2、标记请求request ，封装 Watcher 到 WatchRegistration 。
3、封装成 Packet 对象，发服务端发送request 。
4、收到服务端响应后，将 Watcher 注册到 ZKWatcherManager 中进行管理。
5、请求返回，完成注册。
服务端处理 Watcher
1、服务端接收 Watcher 并存储。 2、Watcher 触发 3、调用 process 方法来触发 Watcher 。
客户端回调 Watcher
1、客户端 SendThread 线程接收事件通知，交由 EventThread 线程回调Watcher 。
2、客户端的 Watcher 机制同样是一次性的，一旦被触发后，该 Watcher 就失效了。client 端会对某个 znode 建立一个 watcher 事件，当该 znode 发生变化时，这些 client 会收到 zk 的通知，然后 client 可以根据 znode 变化来做出业务上的改变等。
二、 Zookeeper 对节点的 watch 监听通知是永久的吗？
不是，一次性的。无论是服务端还是客户端，一旦一个 Watcher 被触发， Zookeeper 都会将其从相应的存储中移除。这样的设计有效的减轻了服务端的压力，不然对于更新非常频繁的节点，服务端会不断的向客户端发送事件通知，无论对于网络还是服务端的压力都非常大。
三、 Zookeeper 集群中有哪些角色？
在一个集群中，最少需要 3 台。或者保证 2N + 1 台，即奇数。为什么保证奇数？主要是为了选举算法。
四、 Zookeeper 集群中Server有哪些工作状态？
LOOKING
寻找 Leader 状态；当服务器处于该状态时，它会认为当前集群中没有 Leader ，因此需要进入Leader 选举状态
FOLLOWING
跟随者状态；表明当前服务器角色是 Follower
LEADING
领导者状态；表明当前服务器角色是 Leader
OBSERVING
观察者状态；表明当前服务器角色是 Observer
五、 Zookeeper 集群中是怎样选举leader的？
当Leader崩溃了，或者失去了大多数的Follower，这时候 Zookeeper 就进入恢复模式，恢复模式需要重新选举出一个新的Leader，让所有的Server都恢复到一个状态LOOKING 。Zookeeper 有两种选举算法：基于 basic paxos 实现和基于 fast paxos 实现。默认为 fast paxos由于篇幅问题，这里推荐：选举流程。
六、 Zookeeper 是如何保证事务的顺序一致性的呢？
Zookeeper 采用了递增的事务 id 来识别，所有的 proposal （提议）都在被提出的时候加上了
zxid 。 zxid 实际上是一个 64 位数字。高 32 位是 epoch 用来标识 Leader 是否发生了改变，如果有新的 Leader 产生出来， epoch 会自增。 低 32 位用来递增计数。 当新产生的 proposal 的时候，会依据数据库的两阶段过程，首先会向其他的 Server 发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行。
七、 ZooKeeper 分布式锁怎么实现的？
如果有客户端1、客户端2等N个客户端争抢一个 Zookeeper 分布式锁。大致如下：
1. 大家都是上来直接创建一个锁节点下的一个接一个的临时有序节点
2. 如果自己不是第一个节点，就对自己上一个节点加监听器
3. 只要上一个节点释放锁，自己就排到前面去了，相当于是一个排队机制。
而且用临时顺序节点的另外一个用意就是，如果某个客户端创建临时顺序节点之后，不小心自己宕机了也没关系， Zookeeper 感知到那个客户端宕机，会自动删除对应的临时顺序节点，相当于自动释放锁，或者是自动取消自己的排队。
本地锁，可以用 JDK 实现，但是分布式锁就必须要用到分布式的组件。比如 ZooKeeper、Redis。网上代码一大段，面试一般也不要写，我这说一些关键点。
几个需要注意的地方如下。
死锁问题：锁不能因为意外就变成死锁，所以要用 ZK 的临时节点，客户端连接失效了，锁就自动释放了。
锁等待问题：锁有排队的需求，所以要 ZK 的顺序节点。
锁管理问题：一个使用使用释放了锁，需要通知其他使用者，所以需要用到监听。
监听的羊群效应：比如有 1000 个锁竞争者，锁释放了，1000 个竞争者就得到了通知，然后判断，最终序号最小的那个拿到了锁。其它 999 个竞争者重新注册监听。这就是羊群效应，出点事，就会惊动整个羊群。应该每个竞争者只监听自己前面的那个节点。比如 2 号释放了锁，那么只有 3 号得到了通知。
