ZooKeeper 是一种分布式，开源的协同服务。分布式应用能够基于其所提供的一些特性来实现服务同步，配置维护，服务分组及命名等。zookeeper是比较简单易用的，而且使用类文件系统树状结构组织数据结构。html
服务同步一直以来都是一个应用中的难点。尤为是在多线程环境中竟态条件及死锁情景极易发生的情景下。zookeeper的设计初衷就是为了减小分布式应用在服务协同方面所须要付出的成本。node
设计目标
ZooKeeper 很简单。ZooKeeper 容许分布式任务进程经过共享层级的命名空间（类文件系统）来实现服务协同。命名空间内部包含数据注册存储，zookeeper术语称之为znodes，这点和文件系统中的文件和文件夹很相似，所不一样的是，文件系统是为了数据存储，因此通常存储于硬盘，而zookeeper的数据存储在内存，这也就保障了zookeeper系统的高吞出，低延迟。数据库
The ZooKeeper 是一种高性能，高可用，严格有序的系统。高性能也就意味着则 zookeeper 能够用在大型，分布式应用系统。高可用则是避免了单点故障，严格有序则是实现复杂业务服务同步的基本特性。apache
ZooKeeper 复制。zookeeper 的目的是任务协同，同时，zookeeper自身也做为协同服务的一员参与协同。服务器
zookeeper服务中的每一个服务节点都须要有相互认知。每一个节点都在内存中维护者一份zookeeper服务的实时状态信息，而且在持久化存储中保存着事务日志信息及数据镜像。只要服务中的大多数服务节点可用，那么整个服务就可认为是可用的。数据结构
每一个客户端只链接到一个服务节点。客户端和zookeeper服务节点维护者一个TCP链接，用于收发请求，获取监听事件及发送心跳。若是客户端和服务节点的链接中断，客户端会从新链接zookeeper中另一个服务节点。多线程
ZooKeeper 是有序的。ZooKeeper 会给每个事务打上时间戳，用以标识顺序。分布式
ZooKeeper 很快。尤为是在以读为主的业务系统中，当读写比例为10:1时，性能优佳。性能
数据模型及层级命名空间
zookeeper的命名空间相似文件系统，每一个命名都是以“/”分割的路径，而且惟一。spa
ZooKeeper 的层级命名空间
节点及瞬时节点
zookeeper的节点及子节点均可以存储数据，称之为znode。zookeeper节点是设计用来存储服务协同数据，包括状态信息，服务配置，位置信息等，因此节点数据一般须要很小。
Znode 以版本信息维护数据，ACL及时间戳变动。版本会随着发生的变动而增长。
节点数据的读写是原子性的，读写操做都是针对节点的全部数据。每一个节点都维护者一份ACL（访问控制列表）信息用以控制数据访问。
ZooKeeper 瞬时节点，生命周期同节点建立的会话生命周期，会话结束，则节点会被删除。
条件更新及监控
ZooKeeper watch事件，客户端在zookeeper节点上设置watch，节点变化时watch被触发，而后被删除，watch触发后，客户端会收到节点变化的信息。客户端和服务节点断开后，客户端也会收到提醒。
服务保障
ZooKeeper 很快而且很简单，为了实现服务复杂业务系统的目的，zookeeper提供如下保障：
- 顺序一致性：更新会按客户端发送的顺序依次执行。
- 原子性：更新要么成功要么失败。
- 单一系统镜像：每一个客户端看到的zookeeper服务信息是一致的。
- 可靠性：更新只有在下一次更新复写以后才会消失。
- 实时性：客户端能实时获取zookeeper服务信息。
简单的 API
ZooKeeper 的设计目标之一即是提供简便的开发接口，所以其只是支持以下操做：
-
create : 建立节点
-
delete : 删除节点
-
exists : 判断节点是否存在
-
get data : 获取节点数据
-
set data : 设置节点数据
-
get children : 获取节点子节点数据
-
sync : 数据复制传递
实现
概览图：
复制型数据库是一种内存型数据库，存储着zookeeper服务完整的数据。更新会被记录日志到硬盘以便用以数据恢复。写操做在被应用到内存数据库以前会被先序列化到硬盘。
zookeeper的每个服务节点均可以做为客户端服务节点，每一个客户端链接到一个服务节点来发送请求。服务节点以本地数据副原本响应客户端请求，写请求则会经过zookeeper的一致性协议来处理。
一致性协议要求客户端的全部写请求都转发到一台服务器，咱们称之为领导者服务节点，其他的服务节点称之为跟随者。跟随者接收领导者提议消息，赞成或拒绝并回复。消息层协议用于领导者选举及跟随者同步。
ZooKeeper 原子广播协议。原子性也就保证了追着服务节点的本地数据副本的实时性，一致性。当zookeeper服务接收到写请求时，领导者应用写请求，而后获取将数据状态做为事务消息发送到跟随者。
性能
ZooKeeper 在读请求为主的应用中可以得到更好的性能（由于写操做涉及到数据及服务状态的同步）。
参考资料：ZooKeeper Throughput as the Read-Write Ratio Varies
可靠性
如上图所示：当跟随者宕机而后快速恢复，zookeeper在期间仍能保持较高的吞吐量。更重要的是，领导者选举协议保障了服务节点的快速恢复从而避免吞吐量急剧变化，一般领导者选举耗时不超过200ms。