说明
1、简单介绍
Zookeeper 是分布式应用程序的高性能的协调服务。
Zookeeper 通过简单的接口服务，对象暴露了公共服务接口，比如：Naming，Configuration management。synchorization and group services。
你能够利用 Zookeeper 现成的服务实现 一致性（consensus），分组管理（group management），领导选举（leader election） 和 存在协议（presence protocols）。
你还能够构建属于自己的、独特的需求。
Zookeeper 被设计为简单的，易于编程实现的服务。
Zookeeper 的数据模型类似于文件系统的树形文件夹结构。
Zookeeper 执行在 Java 平台上。
协调服务是众所周知难以实现的。
由于特别easy出错，比如：条件竞争和死锁。Zookeeper出现的目标就是为了解决分布式系统从头開始自己实现协调服务的问题。
2、设计目标
2.1、Zookeeper 是一套易于理解的框架
命名空间由很多的数据注冊者（Data Register）构成。数据注冊者（Data Register）用Zookeeper的官方语言来描写叙述，则称为 Znoder（以我理解，这就是小动物）。
Znoder 类似于文件系统中的文件和文件夹。
不同于文件系统的地方在于，文件系统被设计用于存储数据。而Zookeeper的数据是存储在内存中的。
所以 Zookeeper 可以实现高吞吐量（High Throuphput）和低延迟（Low latency）。
Zookeeper 在高性能、高可用性、严格命令訪问方面有很好的实现。高性能方面。Zookeeper 能够用于大型的分布式系统；高可用性方面，Zookeeper 攻克了单点故障问题。严格命令訪问方面，
同意client实现复杂的同步原语。
2.2、Zookeeper 是一套冗余的机制
它们连同事务日志和快照一起在持久化存储中维持内存中一个图像的状态。
仅仅要大部分的Server是可用的。那么Zookeeper Service就是可用的。
client连接到单个 Zookeeper Server 时。client通过发送请求（Requests）、获取响应（Responses）、获取观察事件（Watch Events）、发送心跳（Heart beats）等方式来维护一个TCP连接。
假设client连接到 Zookeeper Server 的 TCP连接中断，那么client将会去连接到另外一个不同的 Zookeeper Server 。
2.3、Zookeeper 是顺序化的
随后的操作能够用顺序去实现高级的抽像。比方同步原语。
2.4、Zookeeper 是很快的
Zookeeper 应用程序执行在数千台机器上，表现最好的在方地于读而非写。读写的比率一般为10:1。
2.5、数据模型（Data Model）和分层命名空间（hierarchical namespace）
一个名称（Name）是一个由（/）分隔的路径元素序列（类似于文件系统的一个路径）。
每个节点（Node）在 Zookeeper 的命名空间中都是不同的路径。（命名空间中的每个节点都通过一个路径来标识）
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">
2.6、节点（Nodes）和短暂的节点（Ephemeral Nodes）
这一点就像文件系统中，一个节点既是文件又是文件夹。
Zookeeper 是被设计用于保存诸如状态、配置、位置等用于协调事务的数据，所以每一个节点保存的数据量都不大，一般约为几个至上千个字节的范围。
Zookeeper 官方语言中，Zookeeper 的数据节点称为 ZNode。
ZNode 维护一stat结构数据。同意缓存有效的数据和协调更新。
stat包含：数据变化版本、ACL变化版本、时间戳。
每次ZNode的数据更新，对应的版本会添加。
当client获取数据时。它也会获取到数据的版本。
每一个ZNode的数据读写是原子性的，读操作将读取整个节点的数据，写操作也是替换整个节点的数据。
每一个节点都有一个ACL，表明谁能做什么。
Zookeeper 中有短暂的节点的概念，这些短暂的节点与创建它的Session的生命周期一致，假设Session结束了，则这个节点也随着被删除。
2.7、条件更新和监视点（conditional updates and watches）
监视点被触发时，client将会收到一个包。告知其 ZNode 已经改变了。
假设这时。client与 Zookeeper Server 的连接中断了，client会收到一个本地的通知。
2.8、保障（Guarantees）
Zookeeper 提供了下面保障：
1）、顺序一致性：来自client的更新，依据发送的先后顺序实施。
2）、原子性：更新的结果仅仅有成功或失败。
3）、唯一系统镜像性：无论client连接到哪一台 Zookeeper Server , client仅仅会查看到同一个服务视图。
4）、可靠性：一旦实施了更新，就会一直保持更新的状态，直到client完毕覆盖更新。
5）、及时性：在一个确定的时间内，client看到的系统的状态是最新的。
2.9、简单的API
delete：删除节点；
exists：在某个位置检查是否存在节点；
get data：从一个节点读取数据；
set data：向一个节点写入数据。
get children：获取一个节点的子节点列表。
sync：等待数据传播完成。
2.10、实现（Implementation）
复本数据库（Replicated Database）：是一个内存数据库。存储整个数据树。为了可恢复性，更新数据会被写入到磁盘中。在被写入磁盘之前。数据存储在内存数据库中。
每一个 Zookeeper server都能够为client提供服务。
client仅仅须要连接上不论什么一台 Zookeeper server，并提交请求就能够了。
client的读请求。Zookeeperserver从本机的复本数据库中提供数据。
client的写请求，服务状态改动请求，则须要通过一个约定协议进行处理。
约定协议中有要求，全部client的写请求都被转送到一个叫首领（Leader）的server【剩下的server都叫做随从server（Followers）】。
随从server会收到首领server的改动请求。并允许数据传输。
消息层很关注领导server的状况，当领导server出现问题时，消息层会生产一个新的领导server来替代故障的领导server。然后同步告知全部的随从server。
Zookeeper 自己定义了一个原子性的消息协议。由于消息层的操作是原子性的，所以Zookeeper可以保证本地的复本数据库的数据的一致性。
当领导server接收到一个写请求时。它会先计算出写请求完毕后，系统状态是的样子，然后将操作写入到事务中，由事务去产生一个新的状态。
2.11、使用
2.12、性能（Performance）
在那些读操作远远大于写操作的场合，Zookeeper是很高性能的。
读操作大于写操作是协调服务典型的应用场合。
假设是写操作远远大于读操作的场合，则不然。由于写操作会导致全部server之间的同步操作。
官方团队性能測试-吞吐量图：Zookeeper Throughput as the read-write Ratio varies（3.2版本号的測试图）
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="" style="font-size:18px">
硬件环境：
cpu：dual 2Ghz Xeon
硬盘：2块SATA硬盘 15K RPM
server设置：
1块硬盘专用于 Zookeeper log；
另1块作为OS和 Zookeeper 快照；
Zookeeper ensemble 设置为不同意client连接。
測试目的：
同样读写请求比率下，添加server数量。吞吐量的增长情况；
同样server数量下，添加读请求的比率，吞吐量的增长情况。
假设有3台server，读写请求比率都是50%。那么 Zookeeper 服务的吞吐量大约是40000次/秒。
官方团队可靠性測试-存在故障的可靠性图：Reliabilityin the Presence of Errors
1）、一个follow发生问题及恢复
2）、还有一个follow发生问题及恢复
3）、leader发生问题
4）、两个follow发生问题及恢复
5）、还有一个leader发生问题
2.13、可靠（Rliability）
ZooKeeper依旧能承受高吞吐量。其次，leader选举算法考虑了系统高速恢复。避免使吞吐量下降太多，
ZooKeeper大约在200ms内选出了一个新leader。
第三。follower恢复后，一旦能处理新请求。ZooKeeper就提升了吞吐量。