ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
ZooKeeper的核心是原子广播，保证了每个server之间的同步，实现这个机制的协议是zab协议。zab协议有两种模式：恢复模式（选主）和广播模式（同步）
ZooKeeper的三大角色，也就是ZooKeeper服务器的三种节点类型，领导者（leader），追随者（follower），观察者（observer）。
领导者（leader）：负责提案的提出和更新请求状态
追随者（follower）：接受客户端的请求并向客户端响应，如果是写请求会将写请求发给leader进行处理编号，参与投票选举
观察者（observer）：大致作用和追随者（follower）一样，唯一区别就是不参与投票选举
恢复模式：
在服务刚启动时或leader崩溃时就会进入恢复模式---选出leader
选主过程：
的leader，如果某个leader提议被（N/2）+1个服务器提议那么它就被选举出来的Leader
打个比方：现在有A、B、C三个人
A提出说我要做老大，得到了B、C的肯定，那么A就是老大了。
A说要做老大，B通过了，C不同意，那么就会重复的进行选举，直至选出老大为止。
所以从这个我们也可以得出一个结论：在部署zookeeper集群服务器的时候，只要部署奇数个就好了。部署3台服务器，挂了一台，那么还是满足（N/2）+1。部署4台服务器，挂了一台，满足（N/2）+1，挂了两台的话就不满足了，集群就挂了。
补充点：这个协议包含以下几部分数据：
1.所选举的leader的id，在初始阶段每台服务器的这个值都是自己的id
zookeeper严格遵守FIFO原则（先入先出队列，这是一种传统的按序执行方法，先进入的指令先完成并引退，跟着才执行第二条指令。），这个值越大说明该服务器离主越近。
zxid：zookeeper使用的一种事务Id，所有提案都会有一个zxid标记，它代表了提案的整体顺序。它由两部分组成：周期（epoch）和和计数器（counter），zxid是一个64位整数，高32位为epoch，低32位为counter，因此zxid也可以记为一个整数对(epoch, count)。epoch的值代表了leader的该变，每当选举产生一个新的leader就会生成一个它独有的epoch编号。
3.逻辑时钟的值，也就是epoch，每次选举出leader这个值都会加1
4.服务器在当前选举过程中的状态：LOOKING(选举状态)，LEADING(当前服务器即为选出的leader)，FOLLOWING:leader已经选出，当前服务器与leader进行同步
广播模式：
一旦leader和多数的follower进行状态同步，leader就开始广播消息，进入广播状态。
leader会接收所有服务器发来的最大的zxid值，确定同步点，leader发送它们所缺失的提案，如果缺失的很多就会发送一个完整的快照。所有每一台的server的数据都是一致的。
还有一种特殊的情况，就是leader已经选出了，又新加了一台zookeeper服务器A，A也发出了一个提案B，因为zookeeper的消息是有序的，是按顺序来接收的，因此提案B一定有一个比leader还大的zxid，理论来说它应该被选举成leader，但是已经提交的提案必须要被所有的服务器获知，而那些选出leader的follower并不知道提案B，所以该提案一定是没有提交的提案，是可以的被抛弃的，然后leader就会去通知A放弃提案B。
