简述Zookeeper

1 Zookeeper概念

Zookeeper是一个分布式开源的分布式应用程序协调服务，它实现是依赖于ZAB协议，实现一种主备模式的架构来保持集群中数据的一致性。Zookeeper可用于服务发现，分布式锁，分布式领导选举，配置管理等。Zookeeper体统了一个类似于Linux文件系统的树形结构：可认为是轻量级的内存文件系统，只能存少量信息。Zookeeper的所有数据都存在内存中，且每个节点的内存大小默认为1M。同时它还提供了对于每个节点的监控与通知机制。Zookeeper集群中的任何一台机器都可以响应客户端的读操作。每一台机器都可以接收客户端的写操作，在接收到写操作之后，会将请求转发给leader处理，再由leader把事务提交到集群中各节点。

2 Zookeeper角色

Zookeeper集群是一个基于主从赋值的高可用集群。集群中包括三种角色：leader、follower、observer。其中leader是通过选举确定的一台机器，为客户端提供读写功能。follower与observer可以在不影响写性能的前提下提升集群的读性能。

2.1 Leader

1. 一个Zookeeper集群同一时间只会有一个实际工作的Leader，他会发起维护与各Follower及Observer间的心跳。
2. 所有的写操作必须要通过Leader完成再由Leader将写操作广播给其他服务器。只要有超过半数节点（不包括observer节点）写入成功，该请求就会被提交。

2.2 Follower

1. 一个Zookeeper集群可能同时存在多个Follower，他会响应Leader的心跳。
2. Follower可直接处理并返回客户端的读请求，同时会将写请求转发给Leader处理。
3. 负责在Leader处理写请求时对请求进行投票。

2.3 Observer

Zookeeper需要保证高可用和强一致性，为了支持更多客户端，需增加Server。但是server增多投票延迟增大，影响性能，这时就引入了Observer。Observer不参与投票，也不参与过半写成功策略。仅接受客户端的连接，并将写请求转发给leader。角色与Follower类似，但是无投票权。提高伸缩性同时不影响吞吐率。

3 Zookeeper工作原理（原子广播）

Zookeeper的核心是原子广播，这个机制保证了各个server的数据一致性。实现这个机制的协议叫ZAB（zookeeper atomic broadcast zookeeper原子广播协议）。ZAB有两种模式，分别是恢复模式和广播模式。当服务启动或者在leader崩溃的时候，ZAB就进入了恢复模式，当leader被选出且超过半数的follower与leader完成状态同步之后，恢复模式就结束了，并且进入广播模式。如果有新的server加入集群，他会一恢复模式启动，发现leader，状态同步，同步结束后加入广播。zookeeper一直保持broadcast状态，直到leader崩溃或者超过半数follower与leader断开联系。广播模式需要保证proposal被按顺序处理，因此，zk采用了递增zxid来实现这个功能。所有的proposal被提出的时候加上了递增的zxid。zxid是一个64位的数字，高32为是epoch，用来标识leader的年代，每更换一次leader，epoch+1。低32位是一个递增的计数器，每跟换一次leader，计数器清零一次。

watcher机制

watcher：watcher 在 ZK 是一个核心功能，watcher 可以监控目录节点的数据变化以及子目录的变化，一旦这些状态发生变化时，服务器就会通知所有设置在这个目录节点上的 watcher，从而每个客户端都很快知道它所关注的目录节点的状态发生变化，而做出相应的反应。