在说Zookeeper之前需要先理解一下Paxos算法，理解完Paxos算法之后我们在看Zookeeper，以及ZAB协议和Paxos算法的共性。

Zookeeper是一个开源的分布式协调服务，Google Chubby的开源实现，是分布式数据一致性的解决方案。

拥有几个特性

顺序一致性，事务的提交是有先后顺序的

原子性，一个事务在集群中所有的服务器上，要么都提交成功，要么都没成功

单一视图，所有服务器所看到的数据模型是一样的

可靠性，事务一旦提交就永久有效，除非下一个事务进行更改

实时性的，在一定时间范围之内，每个服务器上的数据是一致的

其设计目标是

一、简单的数据模型，分布式程序可以通过一个共享的、树形结构的命名空间也就是节点（ZNode）相互协调，类似文件系统的目录结构，但与之不同的是数据模型存在内存中，以提高吞吐量、减少延迟；

二、可以构建集群，由3台以上的基数台机器构建集群遵循“过半”原则，客户端可以和集群中任意一台机器构建TCP连接，一旦连接断开，客户端则会被自动连接到其他正常运行的机器；

三、顺序访问，客服端向Zookeeper发出事务请求时，会被分配一个全局唯一的递增编号（ZXID），ZXID反映了执行事务的先后顺序，Zookeeper根据ZXID进行同步事务；

四、高性能，Zookeeper将全量数据存储在内存中，并直接服务于客户端的非事务请求，尤其适用于以读为主的场景，有网友人测试3台3.4Zookeeper服务器，100%读的压力测试结果为12w 的 QPS

Zookeeper的核心概念

一、集群角色，颠覆了传统的Master/Slave（写/读）概念，引入了Leader、Follower、Observer三种角色，Leader为客户端提供写和读操作，Follower和Observer都提供读操作，两者唯一的区别是，Observer不参与选举也不参与“过半写成功”的策略，提升读性能；

二、会话，客户端和服务器之间建立的是TCP长连接，默认端口2181，通过心跳监测保持有效会话，并且客户端能够接受到服务器发送watch事件通知，设置sessionTimeout（session超时时间）可以使连接中断到重连在一定范围时间内会话仍然有效；

三、数据节点，Zookeeper中的“节点”分为两类，第一类是构成集群的机器即机器节点，第二类是指数据模型中的数据节点ZNode。数据模型之前说过是存储在内存中一棵树（ZNode Tree），其中斜杆（/）分割的路径就是数据节点ZNode，保存数据内容和一系列属性。数据节点分为永久节点和临时节点，永久节点一旦创建之后就会永久存在，除非客户端进行节点删除操作，而临时节点的生命周期和客户端会话进行绑定，随会话的失效而被移除。Zookeeper还允许用户为每个节点添加一个特殊属性（SEQUENTIAL），作为节点标记，由父节点维护的自增的整形数字；

四、版本，对于每个Znode Zookeeper都会维护一个Stat的数据结构，Stat记录了三个版本version(ZNode的版本)、cversion（ZNode的子节点版本）、aversion（ZNode的ACL版本）

五、Watcher（时间监听器），是Zookeeper的一个重要特性，Zookeeper允许用户在指定节点是注册一些Watcher，并且在一些特定事件触发的时候，Zookeeper会将事件通知到感兴趣的客户端去，该机制是Zookeeper实现分布式协调服务的重要特性

六、ACL（Access Control Lists），Zookeeper通过ACL进行权限控制，类似于UNIX文件系统的权限控制，有5种权限：CREATE（创建子节点）、READ（获取节点数据和子节点列表）、DELETE（删除子节点）、WRITE（更新节点数据）、ADMIN（设置节点ACL的权限），需要注意创建和删除都是操作子节点,类似母亲只能生自己的孩子不能生自己

为什么选择Zookeeper：首先它性能、稳定性、易用性都达到了工业产品的水平；其次开源、免费、应用广泛（Hadoop、HBase、Storm、Solr都将Zookeeper作为核心组件）

===============================================

    未完待续，下一章ZAP协议