说明
个人英语水平非常一般，理解可能有偏差，假设有翻译不恰当之处，请看官指点。
1、简单介绍
分布式系统就像动物园。当中每台server就像一仅仅动物，Zookeeper就像动物园管理员，协调、服务于动物园里的动物。
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 是一套易于理解的框架
Zookeeper 同意分布式进程之间彼此协调。通过共享一个命名空间体系。这个命名空间体系的组织形式类似于标准的文件系统文件夹结构。
命名空间由很多的数据注冊者（Data Register）构成。数据注冊者（Data Register）用Zookeeper的官方语言来描写叙述，则称为 Znoder（以我理解，这就是小动物）。
Znoder 类似于文件系统中的文件和文件夹。
不同于文件系统的地方在于，文件系统被设计用于存储数据。而Zookeeper的数据是存储在内存中的。
所以 Zookeeper 可以实现高吞吐量（High Throuphput）和低延迟（Low latency）。
Zookeeper 在高性能、高可用性、严格命令訪问方面有很好的实现。高性能方面。Zookeeper 能够用于大型的分布式系统；高可用性方面，Zookeeper 攻克了单点故障问题。严格命令訪问方面，
同意client实现复杂的同步原语。
2.2、Zookeeper 是一套冗余的机制
就像协调分布式进程一样。Zookeeper 本身会复制全部主机集合。
（图2.2：Zookeeper Service）
组成 Zookeeper Service 的server（Server），它们之间必须是相互连通的。
它们连同事务日志和快照一起在持久化存储中维持内存中一个图像的状态。
仅仅要大部分的Server是可用的。那么Zookeeper Service就是可用的。
client连接到单个 Zookeeper Server 时。client通过发送请求（Requests）、获取响应（Responses）、获取观察事件（Watch Events）、发送心跳（Heart beats）等方式来维护一个TCP连接。
假设client连接到 Zookeeper Server 的 TCP连接中断，那么client将会去连接到另外一个不同的 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的数据更新，对应的版本会添加。
当client获取数据时。它也会获取到数据的版本。
每一个ZNode的数据读写是原子性的，读操作将读取整个节点的数据，写操作也是替换整个节点的数据。
每一个节点都有一个ACL，表明谁能做什么。
Zookeeper 中有短暂的节点的概念，这些短暂的节点与创建它的Session的生命周期一致，假设Session结束了，则这个节点也随着被删除。
2.7、条件更新和监视点（conditional updates and watches）
Zookeeper 支持监视点。client能够在一个 ZNode 上添加一个监视点。当这个 ZNode 发生变化时，监视点将被触发和删除。
监视点被触发时，client将会收到一个包。告知其 ZNode 已经改变了。
假设这时。client与 Zookeeper Server 的连接中断了，client会收到一个本地的通知。
2.8、保障（Guarantees）
由于 Zookeeper 的目标是，基于 Zookeeper 去构建更复杂的服务（比如同步），同一时候，Zookeeper 的执行又很快并且使用又很easy，所以须要提供一些保障。
Zookeeper 提供了下面保障：
1）、顺序一致性：来自client的更新，依据发送的先后顺序实施。
2）、原子性：更新的结果仅仅有成功或失败。
3）、唯一系统镜像性：无论client连接到哪一台 Zookeeper Server , client仅仅会查看到同一个服务视图。
4）、可靠性：一旦实施了更新，就会一直保持更新的状态，直到client完毕覆盖更新。
5）、及时性：在一个确定的时间内，client看到的系统的状态是最新的。
2.9、简单的API
create：在树中某个位置创建节点；
delete：删除节点；
exists：在某个位置检查是否存在节点；
get data：从一个节点读取数据；
set data：向一个节点写入数据。
get children：获取一个节点的子节点列表。
sync：等待数据传播完成。
2.10、实现（Implementation）
（图2.10：Zookeeper Components）
该图展示了 Zookeeper 服务的高级组件。除了请求处理器（Request Processor）外,组成 Zookeeper 服务的每个server。都会从每个组件中复制一个属于自己的复本。
复本数据库（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、使用
尽管 Zookeeper 的编程接口很easy。可是，你能够使用它来实现高层的顺序操作，比如：同步原语、成员分组、所属权限等。
2.12、性能（Performance）
Zookeeper 设计目标就是高性能。
在那些读操作远远大于写操作的场合，Zookeeper是很高性能的。
读操作大于写操作是协调服务典型的应用场合。
假设是写操作远远大于读操作的场合，则不然。由于写操作会导致全部server之间的同步操作。
官方团队性能測试-吞吐量图：Zookeeper Throughput as the read-write Ratio varies（3.2版本号的測试图）
Zookeeper Throughput as the read-write Ratio varies）
硬件环境：
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
图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就提升了吞吐量。
说明
个人英语水平非常一般，理解可能有偏差，假设有翻译不恰当之处，请看官指点。
1、简单介绍
分布式系统就像动物园。当中每台server就像一仅仅动物，Zookeeper就像动物园管理员，协调、服务于动物园里的动物。
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 是一套易于理解的框架
Zookeeper 同意分布式进程之间彼此协调。通过共享一个命名空间体系。这个命名空间体系的组织形式类似于标准的文件系统文件夹结构。
命名空间由很多的数据注冊者（Data Register）构成。数据注冊者（Data Register）用Zookeeper的官方语言来描写叙述，则称为 Znoder（以我理解，这就是小动物）。
Znoder 类似于文件系统中的文件和文件夹。
不同于文件系统的地方在于，文件系统被设计用于存储数据。而Zookeeper的数据是存储在内存中的。
所以 Zookeeper 可以实现高吞吐量（High Throuphput）和低延迟（Low latency）。
Zookeeper 在高性能、高可用性、严格命令訪问方面有很好的实现。高性能方面。Zookeeper 能够用于大型的分布式系统；高可用性方面，Zookeeper 攻克了单点故障问题。严格命令訪问方面，
同意client实现复杂的同步原语。
2.2、Zookeeper 是一套冗余的机制
就像协调分布式进程一样。Zookeeper 本身会复制全部主机集合。
（图2.2：Zookeeper Service）
组成 Zookeeper Service 的server（Server），它们之间必须是相互连通的。
它们连同事务日志和快照一起在持久化存储中维持内存中一个图像的状态。
仅仅要大部分的Server是可用的。那么Zookeeper Service就是可用的。
client连接到单个 Zookeeper Server 时。client通过发送请求（Requests）、获取响应（Responses）、获取观察事件（Watch Events）、发送心跳（Heart beats）等方式来维护一个TCP连接。
假设client连接到 Zookeeper Server 的 TCP连接中断，那么client将会去连接到另外一个不同的 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的数据更新，对应的版本会添加。
当client获取数据时。它也会获取到数据的版本。
每一个ZNode的数据读写是原子性的，读操作将读取整个节点的数据，写操作也是替换整个节点的数据。
每一个节点都有一个ACL，表明谁能做什么。
Zookeeper 中有短暂的节点的概念，这些短暂的节点与创建它的Session的生命周期一致，假设Session结束了，则这个节点也随着被删除。
2.7、条件更新和监视点（conditional updates and watches）
Zookeeper 支持监视点。client能够在一个 ZNode 上添加一个监视点。当这个 ZNode 发生变化时，监视点将被触发和删除。
监视点被触发时，client将会收到一个包。告知其 ZNode 已经改变了。
假设这时。client与 Zookeeper Server 的连接中断了，client会收到一个本地的通知。
2.8、保障（Guarantees）
由于 Zookeeper 的目标是，基于 Zookeeper 去构建更复杂的服务（比如同步），同一时候，Zookeeper 的执行又很快并且使用又很easy，所以须要提供一些保障。
Zookeeper 提供了下面保障：
1）、顺序一致性：来自client的更新，依据发送的先后顺序实施。
2）、原子性：更新的结果仅仅有成功或失败。
3）、唯一系统镜像性：无论client连接到哪一台 Zookeeper Server , client仅仅会查看到同一个服务视图。
4）、可靠性：一旦实施了更新，就会一直保持更新的状态，直到client完毕覆盖更新。
5）、及时性：在一个确定的时间内，client看到的系统的状态是最新的。
2.9、简单的API
create：在树中某个位置创建节点；
delete：删除节点；
exists：在某个位置检查是否存在节点；
get data：从一个节点读取数据；
set data：向一个节点写入数据。
get children：获取一个节点的子节点列表。
sync：等待数据传播完成。
2.10、实现（Implementation）
（图2.10：Zookeeper Components）
该图展示了 Zookeeper 服务的高级组件。除了请求处理器（Request Processor）外,组成 Zookeeper 服务的每个server。都会从每个组件中复制一个属于自己的复本。
复本数据库（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、使用
尽管 Zookeeper 的编程接口很easy。可是，你能够使用它来实现高层的顺序操作，比如：同步原语、成员分组、所属权限等。
2.12、性能（Performance）
Zookeeper 设计目标就是高性能。
在那些读操作远远大于写操作的场合，Zookeeper是很高性能的。
读操作大于写操作是协调服务典型的应用场合。
假设是写操作远远大于读操作的场合，则不然。由于写操作会导致全部server之间的同步操作。
官方团队性能測试-吞吐量图：Zookeeper Throughput as the read-write Ratio varies（3.2版本号的測试图）
Zookeeper Throughput as the read-write Ratio varies）
硬件环境：
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
图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就提升了吞吐量。
