Zookeeper是一个开源的分布式协调服务，由雅虎创建，是Google的Chubby的开源实现。Zookeeper的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。
1.1、Zookeeper介绍
1.1.1、Zookeeper是什么
Zookeeper是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。Zookeeper可以保证分布式一致性特性：
顺序性：同一个Client发起的事务请求，最终会严格根据其发起顺序被应用程序处理；
原子性：所有事务请求的处理结果在整个集群中所有Server上的应用情况一致，即同一个事务，要么所有Server都成功要么都失败；
一致性：无论Client连接到哪个Server，看到的服务端数据都是一致的；
可靠性：一旦一个事务被服务端应用，并完成对所有Client的响应，则该事务引起的状态变化将会被持久化，除非另一个事务请求对其进行修改；
实时性：Zookeeper仅保证在一定时间段内，Client最终一定可以从服务端上读取到最新的数据。
1.1.2、Zookeeper的设计目标
Zookeeper提供了一个高性能、高可用，且具有严格的顺序访问控制能力的分布式协调服务。Zookeeper很好的解决了分布式单点故障问题，并且，客户端可以基于Zookeeper实现复杂的同步原语。
简单的数据模型：Zookeeper提供了一个共享的、树型结构的名字空间（Zookeeper服务器内存中的数据模型），由一系列被称为Znode的数据节点组成。Zookeeper的数据模型类似于文件系统，ZNode之间的层级关系类似于文件系统的目录结构。
可以构建集群：一个Zookeeper集群通常由一组机器组成，每个机器都会在内存中维护氮气的服务器状态，并且每台机器之间都互相保持通信。
顺序访问：对于Client的请求，Zookeeper会分配一个全局唯一的递增编号，此编号为事务操作的先后顺序。
高性能：Zookeeper将所有数据存储在内存中，并且直接服务于Client的所有非事务请求，尤其适用于以读操作为主的应用场景。
1.2、Zookeeper基本概念
1.2.1、集群角色
领导者（Leader）：领导者不接受Client的请求，负责进行投票的发起和决议，最终更新状态；
跟随者（Follower）：Fllower用于接收客户请求并返回客户结果，参与Leader发起的投票；
观察者（Observer）：Oberser接收Client连接，将写请求转发给Leader，但是Observer不参与投票，只同步Leader的状态；
学习者（Learner）：和Leader进行状态同步，Fllower和Observer都是Learner。
1.2.2、会话
Zookeeper中，客户端连接是指客户端和服务器之间的一个TCP长连接。Zookeeper对外的服务端口时2181，客户端启动时，首先与服务器建立一个TCP连接，从第一次连接建立开始，客户端会话（session）的生命周期就开始了。
Session的sessionTimeout用于设置客户端会话的超时时间。如果由于服务器压力大、网络故障或客户端主动端口连接等各种原因导致客户端连接中断，只要在sessionTimeout规定的时间内能够重新连接到集群中的任意一台服务器，那么值钱创建的会话仍然有效。
1.2.3、数据节点（Znode）
Zookeeper将所有数据存储在内存中，数据模型是一棵树，由斜杠（/）进行分割的路径，每个Znode节点都会保存自己的数据内容和一系列属性信息。
在Zookeeper中，Znode分为永久节点和临时节点
临时节点：生命周期依赖于Session，一旦客户端Session失效，则客户端创建的所有临时节点都会被删除。临时节点对所有客户端可见。
永久节点：节点生命周期不依赖于会话，一旦被创建，就必须由客户端主动删除才行。
另外，Znode还有另一个属性：SEQUENTIAL，一旦节点被标记为这个属性，则节点在创建的时候，Zookeeper会自动在其后面追加一个整型数字（由父节点维护）。
1.2.4、版本
Zookeeper中的每个Znode都会维护一个叫作Stat的数据结构，Stat中记录了这个节点的三个数据版本：version（当前版本）、cversion（当前子节点的版本）和aversion（当前节点的ACL版本）。
1.2.5、Watcher
Zookeeper运行客户端在指定节点上注册Watcher（事件监视器），当事件触发时，Zookeeper服务端会将事件通知给注册了相应Watcher的客户端。
1.2.6、ACL
Zookeeper采用ACL（Access Control List）策略进行权限控制，类似于Unix文件系统权限控制。Zookeeper定义了五种权限：
Create允许Create子节点；
Read允许对本节点执行GetChildren和GetData操作；
Write允许对本节点执行SetData操作；
Delete允许Delete子节点；
Admin允许对本节点执行setACL操作；
其中，Create和Delete是针对子节点的权限控制。
1.3、Zookeeper运行模式
Zookeeper服务有两种运行模式：独立模式（standalone mode）和集群模式，其中，独立模式只有一个Zookeekper服务器，适合于测试环境，不保证高可用性和恢复性；集群模式运行在一个服务器集群中，如图1.1所示。
图1.1 Zookeeper集群模式
Zookeeper通过复制来实现高可用性，只要集群中ookeepe的机器可用，它就能提供服务。例如，在一个5个节点的集群中，每个Follower节点的数据都是Leader节点数据的副本，五个节点的视图都是一样的，可以同时对外提供服务，并且集群中任意2个节点出现故障，Zookeeper仍然可以保证提供服务。
注意：6个节点的集群也只能容忍2个节点出现故障，因为如果3个节点出现故障，则剩余的3个节点没有超过集群的半数，基于这个原因，一个集群通常包含奇数个节点。
从理论上说，Zookeeper所做的工作就是确保对Znode树的每个修改都会被复制到集群中超过半数的节点上。如果少于半数的节点出现故障，则至少Leader会保存最新的状态，其他副本最终也会更新到这个状态；如果Leader故障，由于其他节点保存了Leader的副本，则可以从中选取一个节点作为新的Leader继续提供服务。
1.4、Zookeeper读写机制
Zookeeper的核心思想是提供一个非锁机制的互斥服务用语分布式系统同步，如图1.2所示。
图1.2 非锁机制的互斥
如图1.2所示，Zookeeper利用Znode的version属性实现了非锁机制的互斥。
Zookeeper集群中有一个Leader和多个Follower，客户端可以连接到任意节点上读写数据，如图1.3所示。
图1.3 Zookeeper集群服务
如图1.3所示，Zookeeper集群中每个节点都保存一份数据副本，Zookeeper基于以下两条同步策略来保证数据的一致性：
① 全局串行执行所有的写操作：所有的写操作都路由到Leader节点执行
② 保证同一客户端的执行FIFO执行（以及消息通知的FIFO）
所有的读请求由Zookeeper节点本地响应；而所有的写请求都转发到Leader，有Leader串行执行，如图1.4所示。
图1.4 Zookeeper事务写请求数据流动图
Zookeeper设计初衷的工作服装的读写比例是2:1以上，由于读操作是由节点本地数据的副本直接响应的，因此，增加集群节点的数量是可以提供集群的容错性和读吞吐量。而写操作都必须转发到Leader节点串行执行，所以，增加集群节点数量并不能增加写吞吐量。
