Zookeeper是一个开源的分布式协同服务系统，为分布式应用提供协调服务的Apache项目。可用于服务发现、分布式锁、分布式领导选举、配置管理等。Zookeeper提供了一个类似于Linux文件系统的树形结构（可认为是轻量级的内存文件系统，但只适合存少量信息，完全不适合存储大量文件或者大文件），同时提供了对于每个结点的监控与通知机制。
Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接收观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。
Zookeeper=文件系统+监听通知机制
Zookeeper：一个领导者，多个跟随者组成的集群，基于主从复制的高可用集群
集群中只要有半数以上的节点存活，Zookeeper集群就能正常服务
全局数据一致：每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的
更新请求顺序进行，来自同一个Client的更新请求按其发送顺序依次执行
数据更新原子性，一次数据更新要么成功，要么失败
实时性，在一定时间范围内，Client能读到最新数据
Zookeeper角色：Leader、Follower、Observer
Leader：一个Zookeeper集群同一时间只会有一个实际工作的Leader，它会发起并维护与各Follower及Observer间的心跳；所有的写操作必须要通过Leader完成再由Leader将写操作广播给其他服务器。只要有超过半数节点（不包括Observer节点）写入成功，该请求就会被提交
Follower：一个Zookeeper集群可能同时存在多个Follower，它会响应Leader的心跳；Follower可直接处理并返回客户端的读请求，同时会将写请求转发给Leader处理；并且负责在Leader处理写请求时对请求进行投票
Observer：角色与Follower类似，但是无投票权。Zookeeper需保证高可用和强一致性，为了支持更多的客户端，需要增加更多Server；Server增多，投票阶段延迟增大，影响性能；引入Observer，Observer不参与投票；Observers接受客户端的连接，并将写请求转发给leader节点；加入更多Observer节点，提高伸缩性，同时不影响吞吐率。
ZAB协议
事务编号Zxid（事务请求计数器+epoch）
在ZAB（Zookeeper Atomic Broadcast）协议的事务编号Zxid设计中，Zxid是一个64位的数字，其中低32位是一个简单的单调递增的计数器，针对客户端每一个事务请求，计数器加1；而高32位则代表Leader周期epoch的编号，每个当选产生一个新的Leader服务器，就会从这个Leader服务器上取出其本地日志中最大事务的ZXID，并从中读取epoch值，然后加1，以此作为新的epoch，并将低32位从0开始计数
Zxid类似于RDBMS中的事务ID，用于标识一次更新操作的Proposal（提议）ID。为了保证顺序性，该zxid必须单调递增
epoch：当前集群所处的周期，leader变更之后，都会在当前值加上1。这样就算旧的leader崩溃恢复之后，也没有人听他的了，因为follower只听从当前年代的leader的命令
ZAB协议的两种模式：恢复模式（选主）、广播模式（同步）。当服务启动或者在leader崩溃后，ZAB就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态
ZAB协议4阶段
Leader election（选举阶段-->选出准Leader）：节点在一开始都处于选举阶段，只要有一个节点得到超半数节点的票数，它就可以当选准leader。只有到达广播阶段准leader才会成为真正的leader。这一阶段的目的就是为了选出一个准leader，然后进入下一个阶段
Discovery（发现阶段-->接受提议、生成epoch、接受epoch）：在这个阶段，followers跟准leader进行通信，同步followers最近接收的事务提议。这个阶段的主要目的是发现当前大多数节点接收的最新提议，并且准leader生成新的epoch，让followers接受，更新它们的accepted epoch。 一个follower只会连接一个leader，如果有一个节点f认为另一个follower p是leader，f在尝试连接p时会被拒绝，f被拒绝之后，就会进入重新选举阶段
Synchronization（同步阶段-->同步follower副本）：同步阶段主要是利用leader前一阶段获得的最新提议历史，同步集群中所有的副本。只有当大多数节点都同步完成，准leader才会成为真正的leader。follower只会接收zxid比自己的lastZxid大的提议
Broadcast（广播阶段-->leader消息广播）：到了这个阶段，Zookeeper集群才能正式对外提供事务服务，并且leader可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步
投票机制
每个server首先给自己投票，然后用自己的选票和其他server选票对比，权重大的胜出，使用权重较大的更新自身选票箱
1，每个Server启动以后都询问其他的Server它要投票给谁。对于其他Server的询问，server每次根据自己的状态都回复自己推荐的leader的id和上一次处理事务的zxid（系统启动时每个server都会推荐自己）
2，收到所有Server回复以后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下一次要投票的Server
3，计算这过程中获得票数最多的server为获胜者，如果获胜者的票数超过半数，则该server被选为leader。否则，继续这个过程，直到leader被选举出来
4，leader就会开始等待server连接
5，Follower连接leader，将最大的zxid发送给leader
6，Leader根据follower的zxid确定同步点，至此选举阶段完成
7，选举阶段完成Leader同步后通知follower已经成为uptodate状态
8，Follower收到uptodate消息后，又可以重新接受client的请求进行服务了
Zookeeper工作原理（原子广播）
1，Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做ZAB协议。ZAB协议有两种模式，分别是恢复模式和广播模式
2，当服务启动或者在领导者崩溃后，ZAB就进入了恢复模式，当领导者被选举出来，且大多数server完成了和leader的状态同步以后，恢复模式就结束了
3，状态同步保证了leader和server具有相同的系统状态
4，一旦leader已经和多数的follower进行了状态同步后，就可以开始广播消息了，即进入广播状态。这时候当一个server加入zookeeper服务中，它会在恢复模式下启动，发现leader，并和leader进行状态同步。待到同步结束，它也参与消息广播。Zookeeper服务一直维持在Broadcast状态，直到leader崩溃了或者leader失去了大部分的followers支持
5，广播模式需要保证proposal被按顺序处理，因此zk采用了递增的事务id号（zxid）来保证。所有的提议（proposal）都在被提出的时候加上了zxid
6，实现中zxid是一个64位的数字，高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch。低32位是个递增计数
7，当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的server都恢复到一个正确的状态
数据结构
Zookeeper的层次模型称作data tree。Data tree的每个节点叫作ZNode。每一个ZNode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识。不同于文件系统，每个节点都可以保存数据。每个节点都有一个版本（version）。版本从0开始计数。
应用场景
统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等。
统一命名服务：在分布式环境下，经常需要对应用/服务进行统一命名，便于识别
统一配置管理
分布式环境下，配置文件同步非常常见
（1）一般要求一个集群中，所有节点的配置信息是一致的，比如Kafka集群
（2）对配置文件修改后，希望能够快速同步到各个节点上
配置管理可交由ZooKeeper实现
（1）可将配置信息写入ZooKeeper上的一个Znode
（2）各个客户端服务器监听这个Znode
（3）一旦Znode中的数据被修改，ZooKeeper将通知各个客户端服务器
统一集群管理
（1）分布式环境中，实时掌握每个节点的状态是必要的，可根据节点实时状态做出一些调整
（2）ZooKeeper可以实现实时监控节点状态变化，可将节点信息写入ZooKeeper上的一个Znode，监听这个Znode可获取它的实时状态变化
服务器动态上下线
客户端能实时洞察到服务器上下线的变化
软负载均衡
在ZooKeeper中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求
典型应用场景：配置管理、DNS服务、组成员管理、各种分布式锁
ZooKeeper适用于存储和协同相关的关键数据，不适合用于大数据量存储