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