一、Zookeeper简介
Zookeeper是一个开源的分布式协调服务，Zookeeper的设计目标是将那些复杂且容易出错的分布式一致性封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。
Zookeeper是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于Zookeeper实现诸如数据发布/订阅，负载均衡，命名服务，分布式协调/通知，集群管理，Master选举，分布式锁和分布式队列等功能。
Zookeeper一个最常用的使用场景就是用于担任生产者和服务消费者的注册中心，提供发布/订阅服务。服务生产者将自己提供的服务注册到Zookeeper中心，服务消费者在进行服务调用的时候先到Zookeeper中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据，如在Dubbo中，Zookeeper就担任注册中心的角色。
在使用Zookeeper的时候，最好使用集群版Zookeeper，而且最好使用集群版服务器构成Zookeeper集群。Zookeeper容错中，当宕调几个Zookeeper服务器后，剩下的个数必须大于宕掉个数，整个Zookeeper才能依然使用。假如集群中有n台Zookeeper服务器，那么也就是剩下的服务器数必须大于n/2，所以当n是奇数的时候则宕掉的最多为(n-1)/2,当n为偶数时，宕掉的最多为n/2，而剩下的最多的数量都是一样的。比如假如我们有3台，那么最大允许宕掉1台zookeeper服务器，如果我们有4台的的时候也同样只允许宕掉1台。假如我们有5台，那么最大允许宕掉2台zookeeper服务器，如果我们有6台的的时候也同样只允许宕掉2台。所以使用奇数台zookeeper就够了。
二、Zookeeper的概念
1、重要概念
（1）Zookeeper本身就是一个分布式程序，主要半数以上节点存活，Zookeeper就能正常服务。
（2）为了保证高可用，最好以集群方式不是Zookeeper，这样只要集群中大部分机器是可用的，Zookeeper本身仍然可用。
（3）Zookeeper将数据保存在内存中，保证了高吞吐和低延迟，但是内存限制了能够存储的容量不太大，限制了Znode中存储的数据量较小的进一步原因。
（4）Zookeeper是高性能的，在读多于写的应用程序中尤其的高性能，因为写会导致所有服务器同步状态。
（5）Zookeeper有临时节点的概念，当创建临时节点的客户端会话一直保持活动，瞬时节点就一直存在，而当会话终结时，瞬时节点被删除。持久节点是指一旦这个ZNode被创建，除非主动进行ZNode的移除操作，否则这个ZNode将一直保存在Zookeeper上。
（6）Zookeeper底层其实提供了两个功能，管理用户程序提交的数据；为用户程序提供节点监听服务。
2、Seesion-会话
Session是指Zookeeper服务器与客户端会话。在Zookeeper中，一个客户端连接是指客户端和服务器之间的一个TCP长连接。客户端启动的时候，首先会与服务器建立一个TCP连接，从第一次连接建立开始，客户端会话的生命周期就开始了。通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能够像Zookeeper服务器发送请求并接受响应，同时还能够通过该连接接收来自服务器的Watch事件通知。
Session的sessionTimeout可以设置客户端会话的超时事件。由于服务压力大，网络故障或者客户端主动断开连接等各种原因导致客户端连接断开时，只要在sessionTimeout规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。
在为客户端创建会话之前，服务端首先会为每个客户端都分配一个sissionID,由于sessionID是Zookeeper会话的一个重要标识，许多与会话相关的运行机制都是基于sessionID的，因此，无论是哪台服务器为客户端分配的sessionID,都需要保证全局唯一。
3、ZNode
在Zookeeper中，节点分为两类，第一类是指构成集群的机器，称为机器节点，第二类是指数据模型中的数据单元，称为数据节点-ZNode。
Zookeeper将所有数据存储在内存中，数据模型是一棵树，由/进行分割的路径，就是一个Znode，每个节点上都会保存自己的数据内容，同时还会保存一系列属性信息。
Zookeeper中node 分为两类，分为持久节点和临时节点。同时Zookeepe还允许为每个节点添加一个属性：SEQUENTIAL。一旦节点被标记上这个属性，那么这个节点被创建的时候，Zookeeper会自动在其节点名后追加上一个整型数字，这个整型数字是由一个父节点维护的自增数字。
4、版本
Zookeeper的每个ZNode上都会存储数据，对应于每个ZNode，Zookeeper都会为其维护一个State数据结构，Stat中记录了这个ZNode的三个数据版本，分别是Version-当前ZNode的版本，cversion-当前ZNode子节点的版本和aversion-当前ZNode的ACL版本。
5、watcher
Watcher-事件监听器，是Zookeeper中一个很重要的特性。Zookeeper允许用于在指定节点上注册一些Watcher，并且在一些特定事件触发的时候，Zookeeper服务端会将事件通知到感兴趣的客户端上去，该机制是Zookeeper实现分布式协调服务的重要特性。
6、ACL
Zookeeper采用ACL策略来进行权限控制，分为：
（1）CREATE：创建子节点的权限。
（2）READ：获取节点数据和子节点列表的权限。
（3）WRITE：更新节点数据的权限。
（4）DELETE：删除子节点的权限。
（5）ADMIN：设置节点的ACL权限。
其中CREATE和DELETE这两种权限都是针对子节点的控制权限。
三、Zookeeper的特点
1、顺序一致性
从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到Zookeeper中去。
2、原子性
所有竖起轻轻的处理结果在整个集群中所有机器上的应用情况时一直的，就是说，要么整个集群中多有的机器都成功应用了某一个事务，要么都没有应用。
3、单一系统映像
无论客户端连到哪一个zookeeper服务器，其看到的服务器数据模型都是一致的。
4、可靠性
一旦一次更改请求被应用，更改结果就会被持久化，直到被下一次更改覆盖。
四、Zookeeper的设计目标
1、简单的数据模型
ZooKeeper 允许分布式进程通过共享的层次结构命名空间进行相互协调，这与标准文件系统类似。 名称空间由 ZooKeeper 中的数据寄存器组成 - 称为znode，这些类似于文件和目录。
2、可构建集群
为了保证高可用，最好是以集群形态部署Zookeeper，这样只要集群中大部分机器是可用的，那么zookeeper本身仍然可用。
3、顺序访问
对于来自客户端的每个更新请求，Zookeeper都会分配一个全局唯一的递增编号，这个编号反应了所有事物操作的先后顺序，应用程序可以使用Zookeeper这个特性来实现更高层次的同步原语，这个编号也叫时间戳-zxid。
4、高性能
Zookeeper是高性能的，在读多于写的应用程序中尤其的高性能，因为写会导致所有服务器同步状态。
五、Zookeeper集群角色
Zookeeper中分为Leader，Follower，Observer三种角色。
Zookeeper集群中所有的机器通过一个Leader选举过程来选定一台Leader机器，Leader既可以为客户端提供写服务又能提供读服务。Follower和Observer都只提供读服务。Follower和Observer唯一的区别是Observer不参与Leader的选举过程，也不参与写操作的“过半写成功”策略，因此Observer机器可以在不影响写性能的情况下提升集群的读性能。
当Leader服务器出现网络中断、崩溃退出或者重启等异常情况时，ZAB协议就会进入恢复模式并选举产生新的Leader服务器。
选举Leader的过程如下：
（1）Leader election-选举阶段，节点在一开始都处于选举节点，只要有一个节点得到超半数节点的票数，它就可以当选准leader。
（2）Discovery-发现阶段，follower和准Leader进行通信，同步follower最近接受的事务提议。
（3）Synchronization-同步阶段，利用Leader在前一阶段获取到的最新提议历史，同步集群中所有副本，同步完成后，准Leader才成为真正的Leader。
（4）Broadcast-广播阶段，Zookeeper集群正式对外提供事务服务，并且Leader可以进行消息广播，同时如果有新节点加入，还需要对新节点进行同步。
六、ZooKeeper &ZAB 协议&Paxos算法
1、 ZAB 协议&Paxos算法
Paxos 算法应该可以说是 ZooKeeper 的灵魂了。但是，ZooKeeper 并没有完全采用 Paxos算法 ，而是使用 ZAB 协议作为其保证数据一致性的核心算法。另外，在ZooKeeper的官方文档中也指出，ZAB协议并不像 Paxos 算法那样，是一种通用的分布式一致性算法，它是一种特别为Zookeeper设计的崩溃可恢复的原子消息广播算法。
2、ZAB 协议介绍
ZAB（ZooKeeper Atomic Broadcast 原子广播） 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。 在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。
3、 ZAB 协议两种基本的模式：崩溃恢复和消息广播
ZAB协议包括两种基本的模式，分别是崩溃恢复和消息广播。当整个服务框架在启动过程中，或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进人恢复模式并选举产生新的Leader服务器。当选举产生了新的 Leader 服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式。其中，所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和Leader服务器的数据状态保持一致。
当集群中已经有过半的Follower服务器完成了和Leader服务器的状态同步，那么整个服务框架就可以进人消息广播模式了。当一台同样遵守ZAB协议的服务器启动后加人到集群中时，如果此时集群中已经存在一个Leader服务器在负责进行消息广播，那么新加人的服务器就会自觉地进人数据恢复模式：找到Leader所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。正如上文介绍中所说的，ZooKeeper设计成只允许唯一的一个Leader服务器来进行事务请求的处理。Leader服务器在接收到客户端的事务请求后，会生成对应的事务提案并发起一轮广播协议；而如果集群中的其他机器接收到客户端的事务请求，那么这些非Leader服务器会首先将这个事务请求转发给Leader服务器。