ZooKeeper官方文档
博客地址：http://blog.csdn.net/java_yes/article/details/78668460
ZooKeeper：分布式应用程序的分布式协调服务
ZooKeeper是面向分布式应用程序的分布式开源协调服务。它公开了一组简单的原语，分布式应用程序可以利用这些原语来实现更高级别的服务，以实现同步，配置维护以及组合命名。它被设计为易于编程，并且使用在文件系统熟悉的目录树结构之后的样式的数据模型。它运行在Java中，并具有Java和C的绑定。
协调服务是非常难以正确的。他们特别容易出现诸如（由于两个或者多个进程竞争使用不能被同时访问的资源，使得这些进程有可能因为时间上推进的先后原因而出现问题，这叫做竞争条件）Race Condition和（死锁）deadlock等错误。ZooKeeper背后的动机是为分散的应用程序减轻从零开始实施协调服务的责任。
设计目标
ZooKeeper是简单的。ZooKeeper允许分布式进程通过与标准文件系统类似组织的共享分层名称空间相互协调。名称空间由数据寄存器（称为znode）组成，以ZooKeeper的说法 – 它们类似于文件和目录。与典型的用于存储的文件系统不同，ZooKeeper数据保存在内存中，这意味着ZooKeeper可以实现高吞吐量和低延迟数量。
ZooKeeper实现对高性能，高可用性，严格有序的访问非常重要。ZooKeeper的性能方面意味着它可以用于大型分布式系统。可靠性方面使它不能成为单一故障点。严格的排序意味着可以在客户端实现复杂的同步原语。
ZooKeeper是可复制的。就像它所协调的分布式进程一样，ZooKeeper本身也被复制到一组称为集合的主机上。
image
构成ZooKeeper服务的服务器必须全部相互了解。他们维护一个内存状态的图像，以及一个持久存储中的事务日志和快照。只要大部分服务器都可用，ZooKeeper服务将可用。
客户端连接到一台ZooKeeper服务器。客户端维护一个TCP连接，通过它发送请求，获取响应，获取监视事件并发送心跳。如果到服务器的TCP连接中断，客户端将连接到不同的服务器。
ZooKeeper是有序的。ZooKeeper使用反映所有ZooKeeper事务顺序的数字来标记每个更新。后续操作可以使用该命令来实现更高级别的抽象，例如同步原语。
ZooKeeper是很快的。在“读取主导”的工作负载中，这个速度特别快。ZooKeeper应用程序在数千台机器上运行，并且在读取比写入更为普遍的情况下，性能表现最佳，比例约为10：1。
数据模型和分层名称空间
ZooKeeper的分层命名空间
ZooKeeper提供的名称空间与标准文件系统非常相似。名称是由斜杠（/）分隔的一系列路径元素。ZooKeeper名称空间中的每个节点都由一个路径标识。
节点和短暂节点
与标准文件系统不同，ZooKeeper名称空间中的每个节点都可以有与其相关的数据以及子节点。这就像有一个文件系统，允许一个文件也是一个目录。（ZooKeeper被设计用于存储协调数据：状态信息，配置，位置信息等，因此存储在每个节点的数据通常很小，在字节到千字节范围内）。我们使用znode这个词 来表示我们正在谈论ZooKeeper数据节点。
Znodes维护一个统计结构，其中包括数据更改的版本号，ACL更改和时间戳，以允许缓存验证和协调更新。每当znode的数据发生变化时，版本号就会增加。例如，每当客户端检索数据时，它也会收到数据的版本。
存储在名称空间中每个节点上的数据是以原子方式读取和写入的。读取获得与znode关联的所有数据字节，写入将替换所有数据。每个节点都有一个访问控制列表（ACL），限制谁可以做什么。
ZooKeeper也有短暂节点的概念。只要创建znode的会话处于活动状态，就会存在这些znode。当会话结束时，znode被删除。当您想实现[tbd]时，短暂节点很有用。
条件更新和监视
ZooKeeper支持监控概念。客户可以在znode上设置一个监控。当znode改变时，监控将被触发并移除。当监控被触发时，客户端收到一个数据包说znode已经改变。如果客户端与其中一个Zoo Keeper服务器之间的连接中断，客户端将收到本地通知。这些可以用来[待定]。
保证
ZooKeeper非常快速，非常简单。既然它的目标是构建比较复杂的服务，比如同步，就提供了一套保证。这些是：
- 顺序一致性 ： 来自客户端的更新将按照它们发送的顺序进行应用。
- 原子性 ： 更新成功或失败。没有部分结果。
- 单系统映像： 无论服务器连接到哪个服务器，客户端都会看到相同的服务视图。
- 可靠性： 一旦更新被应用，它将一直持续到客户覆盖更新。
- 及时性 ： 系统的客户观点在一定的时间范围内保证是最新的。
简单的API
ZooKeeper的一个设计目标是提供一个非常简单的编程接口。因此，它只支持这些操作：
- 创建：
在树中的一个位置创建一个节点- 删除：
删除一个节点- 判断是否存在：
测试节点是否存在于某个位置- 获取数据：
从节点读取数据- 设置数据：
将数据写入节点- 获得子集：
检索一个节点的子节点列表- 同步：
等待数据同步到每个节点上
实现
ZooKeeper组件显示了ZooKeeper服务的高级组件。除请求处理器外，组成ZooKeeper服务的每个服务器都复制其每个组件的副本。
ZooKeeper组件
复制的数据库是包含整个数据树的内存数据库。将更新记录到磁盘以实现可恢复性，并在写入磁盘之前将其写入磁盘，然后再将其写入内存数据库。
每个ZooKeeper服务器都为客户端服务。客户端连接到一个服务器提交irequests。读取请求是从每个服务器数据库的本地副本服务的。请求改变服务的状态，写请求，由协议协议处理。
作为协议协议的一部分，来自客户端的所有写入请求都被转发给一个称为leader的服务器 。ZooKeeper服务器的其余部分（称为 followers）接收leader的消息建议并同意消息传递。消息传递层负责替换失效的leader，并与leader同步followers。
ZooKeeper使用一个自定义的原子消息传递协议。由于消息传递层是原子的，因此ZooKeeper可以保证本地副本不会发生分离。当leader接收到一个写请求时，它会计算什么时候系统的状态是什么时候写，并将其转换成一个捕获这个新状态的事务。
使用
ZooKeeper的编程接口是特意设计的简单。但是，有了它，您可以实现更高阶的操作，例如同步原语，组成员资格，所有权等。一些分布式应用程序已经使用它来：[tbd：从白皮书和视频演示中添加使用。]
性能
ZooKeeper被设计为高性能的。但是呢？Yahoo! ZooKeeper开发团队的成果 研究表明它是。（请参阅ZooKeeper吞吐量作为读写速率的变化。）在读取数量大于写入的应用程序中，性能特别高，因为写入操作涉及到同步所有服务器的状态。（读出次数写入通常是协调服务的情况。）
Zoopkeeper吞吐量变化
图中的ZooKeeper吞吐量读写比率发生变化是动ZooKeeper的吞吐量图3.2版与双2GHz的至强和两个SATA 15K RPM驱动器的服务器上运行。一个驱动器被用作专用的ZooKeeper日志设备。快照被写入到OS驱动器。写请求是1K写，读取是1K读。“服务器”表示ZooKeeper集成的大小，即构成服务的服务器的数量。大约还有30台服务器用于模拟客户端。ZooKeeper集成配置使领导不允许来自客户端的连接。
注意：与之前的3.1版本相比，3.2版本的r / w性能提高了约2倍。
基准也表明它也是可靠的。显示了部署如何响应各种故障。图中标注的事件如下：
- follower的失效和恢复
- 失效和恢复不同的follower
- leader失效
- 两名follower失效和恢复
- 另一位leader失效
可靠性
为了显示随着时间的推移系统的行为，我们运行了一个由7台机器组成的ZooKeeper服务。我们和以前一样运行了相同的饱和度基准，但是这次我们把写入百分比保持在30％，这是我们预期的工作量的一个保守的比例。
存在错误的可靠性
这个图是几个重要的观察结果。首先，如果follower失效并迅速恢复，那么ZooKeeper即使失效也能保持高吞吐量。但更重要的是，leader选举算法允许系统恢复得足够快，以防止吞吐量大幅下降。在我们的观察中，ZooKeeper花了不到200ms选出一个新的leader。第三，随着follower的恢复，ZooKeeper能够在开始处理请求后再次提高吞吐量。
ZooKeeper项目
ZooKeeper已被 成功应用于 许多工业应用。它用在Yahoo! 作为Yahoo!的协调和故障恢复服务。Message Broker，这是一个高度可扩展的发布 – 订阅系统，管理数千个复制和数据传输主题。它被Yahoo!的抓取服务使用。爬虫，它也管理故障恢复。一些雅虎！广告系统也使用ZooKeeper来实现可靠的服务。
