ZooKeeper 文档（概述）

概述

• ZooKeeper：分布式应用程序的分布式协调服务
• 设计目标
• 数据模型和层次命名空间
• 节点和临时节点
• 有条件的更新和守望者
• 保证
• 简单的API
• 实现
• 使用
• 性能
• 可靠性
• ZooKeeper项目

ZooKeeper：分布式应用程序的分布式协调服务

ZooKeeper是一个分布式、开源的分布式应用协调服务，它公开了一组简单的基元，分布式应用程序可以在这些基元的基础上实现更高级别的服务，以实现同步、配置维护、组和命名，它被设计成易于编程，并且使用了一个数据模型，该数据模型采用了文件系统中常见的目录树结构，它在Java中运行，并同时绑定了Java和C。

众所周知，协调服务很难做好，它们特别容易出现诸如竞态条件和死锁之类的错误，ZooKeeper背后的动机是减轻分布式应用从零开始实现协调服务的责任。

设计目标

ZooKeeper是简单的。ZooKeeper允许分布式进程通过一个共享的层次化命名空间相互协调，这个命名空间的组织类似于标准文件系统，命名空间由数据寄存器组成 - 叫znodes，在ZooKeeper的说法 - 这些类似于文件和目录，与为存储而设计的典型文件系统不同，ZooKeeper数据被保存在内存中，这意味着ZooKeeper可以实现高吞吐量和低延迟。

ZooKeeper的实现非常重视高性能、高可用性和严格有序的访问，ZooKeeper的性能方面意味着它可以在大型分布式系统中使用，可靠性方面使它避免成为单点故障，严格的排序意味着可以在客户端上实现复杂的同步基元。

ZooKeeper是复制的。就像它协调的分布式进程一样，ZooKeeper本身也要在一组被称为集成的主机上进行复制。

组成ZooKeeper服务的服务器必须互相知晓，它们维护内存中的状态镜像，以及持久存储中的事务日志和快照，只要大多数服务器可用，ZooKeeper服务就可用。

客户端连接到一个ZooKeeper服务器，客户端维护一个TCP连接，通过它发送请求、获取响应、查看事件和发送心跳，如果到服务器的TCP连接中断，客户端将连接到另一个服务器。

ZooKeeper是有序的。ZooKeeper用一个反映所有ZooKeeper事务顺序的数字来标记每次更新，后续操作可以使用顺序实现更高级别的抽象，比如同步基元。

ZooKeeper是快速的。它在“读为主”的工作负载中尤其快速，ZooKeeper应用程序在数千台机器上运行，在读比写更普遍的地方运行得最好，比率约为10:1。

数据模型和层次命名空间

ZooKeeper提供的命名空间很像标准文件系统，名称是用斜杠（/）分隔的路径元素序列，ZooKeeper的命名空间中的每个节点都由一条路径来标识。

节点和临时节点

与标准文件系统不同，ZooKeeper命名空间中的每个节点都可以拥有与之关联的数据以及子节点，这就像有一个允许文件也可以是目录的文件系统，（ZooKeeper被设计用来存储协调数据：状态信息、配置、位置信息等，因此，存储在每个节点上的数据通常很小，从字节到千字节不等。）我们使用术语znode是为了说明我们讨论的是ZooKeeper数据节点。

Znodes维护一个stat结构，其中包括数据更改的版本号、ACL更改和时间戳，以允许缓存验证和协调更新，每次znode的数据发生变化，版本号就会增加，例如，每当客户机检索数据时，它也会接收数据的版本。

在命名空间中的每个znode上存储的数据是原子式读写的，读取获取与znode关联的所有数据字节，写入替换所有数据，每个节点都有一个访问控制列表(ACL)，它限制谁可以做什么。

ZooKeeper也有临时节点的概念，只要创建了znode的会话是活动的，这些znode就存在，当会话结束时，znode将被删除，当你想要实现[tbd]时，临时节点非常有用。

有条件的更新和守望者

ZooKeeper支持守望者的概念，客户端可以在znode上设置一个守望者，当znode发生变化时，守望者将被触发并移除，当一个守望者被触发时，客户端会收到一个报文，说znode已经改变了，如果客户端和ZooKeeper服务器之间的连接中断，客户端将收到本地通知，这些可以用于[tbd]。

保证

ZooKeeper非常快并且非常简单，但是，由于它的目标是成为构建更复杂服务（如同步）的基础，所以它提供了一组保证。
这些都是：

• 顺序一致性 - 来自客户端的更新将按发送的顺序应用。
• 原子性 - 更新要么成功，要么失败，没有部分结果。
• 单一系统映像 - 无论连接到哪个服务器，客户端都将看到相同的服务视图。
• 可靠性 - 一旦应用了更新，它将从那时起一直持续到客户端覆盖更新为止。
• 及时性 - 系统的客户端视图保证在一定的时间范围内是最新的。

有关这些信息以及如何使用它们的更多信息，请参见[tbd]。

简单的API

ZooKeeper的设计目标之一就是提供一个非常简单的编程接口，因此，它只支持这些操作：

• create - 在树中的某个位置创建节点
• delete - 删除一个节点
• exists - 测试节点是否存在于某个位置
• get data - 从节点读取数据
• set data - 将数据写入节点
• get children - 检索节点的子节点列表
• sync - 等待数据被传播

有关这些操作的更深入讨论，以及如何使用它们实现更高级别的操作，请参阅[tbd]

实现

ZooKeeper组件显示了ZooKeeper服务的高级组件，除了请求处理器之外，构成ZooKeeper服务的每个服务器都复制自己的每个组件副本。

复制数据库是包含整个数据树的内存数据库，更新被记录到磁盘上以供恢复，写入操作在应用到内存数据库之前被序列化到磁盘。

每个ZooKeeper服务器服务客户端，客户端连接到一个完整服务器以提交请求，从每个服务器数据库的本地副本服务读取请求，更改服务状态的请求、写请求，是通过一致性协议来处理的。

作为一致性协议的一部分，所有来自客户端的写请求都被转发到一个名为leader的服务器，其他的ZooKeeper服务器，被称为followers，接收来自领导者的信息建议并同意信息传递，消息传递层负责在失败时替换领导者，并将追随者与领导者同步。

ZooKeeper使用自定义原子消息传递协议，由于消息传递层是原子层，ZooKeeper可以确保本地副本不会分散，当leader收到写请求时，它会计算应用写时系统的状态，并将其转换为捕获新状态的事务。

使用

ZooKeeper编程接口非常简单，但是通过它，你可以实现更高阶的操作，例如同步原语、组成员关系、所有权等等，一些分布式应用程序已经使用了它：[tbd：添加来自白皮书和视频演示的用法]如需更多资料，请参阅[tbd]。

性能

ZooKeeper被设计成具有很高的性能，但真的是这样吗? Yahoo!研究公司的ZooKeeper开发团队的结果表明确实如此。（当读写比率变化时，请查看ZooKeeper吞吐量。）在读多于写的应用程序中，它的性能特别高，因为写涉及到同步所有服务器的状态。（读多于写是协调服务的典型情况。）

随着读写比率的变化，ZooKeeper的吞吐量数据是一个ZooKeeper版本3.2的吞吐量图，该版本运行在具有双2Ghz Xeon和两个SATA 15K RPM驱动器的服务器上，其中一个驱动器被用作专用的ZooKeeper日志设备，快照被写入操作系统驱动器。写请求是1K写，读是1K读，“ Servers”表示ZooKeeper集合的大小，即组成服务的服务器数量，大约有30个其他服务器用于模拟客户端，ZooKeeper总体的配置是这样的:领导者不允许与客户端建立连接。

与 之前的3.1版本相比，3.2版本的r/w性能提高了~2x。

基准测试也表明它是可靠的，存在错误时的可靠性图显示部署如何响应各种故障，图中所示的事件如下：

1. 追随者的故障和恢复
2. 一个不同的追随者的故障和恢复
3. 领导者的故障
4. 两个追随者的故障和恢复
5. 另一个领导者的故障

可靠性

为了显示系统随着时间的推移而出现的故障，我们运行了一个由7台机器组成的ZooKeeper服务，我们运行了与以前相同的饱和基准，但这次我们把写的百分比保持在30%不变，那是我们预期工作量的保守比率。

存在错误时的可靠性如下图：

这是一些重要的观察结果，首先，如果追随者故障了并且恢复得很快，那么ZooKeeper能够在故障的情况下维持高吞吐量，但可能更重要的是，领导人选举算法允许系统恢复足够快，以防止吞吐量大幅下降，在我们的观察中，ZooKeeper用了不到200毫秒的时间就选出了一个新的领导者。第三，随着追随者的恢复，一旦开始处理请求，ZooKeeper就能够再次提高吞吐量。

ZooKeeper项目

ZooKeeper已经成功地应用于许多工业领域，它在Yahoo!中用作Yahoo! Message Broker的协调和故障恢复服务，那是一个高度可伸缩的发布-订阅系统，用于管理数千个主题的复制和数据传递，它被Yahoo! crawler的抓取服务所使用，该服务还管理故障恢复，许多Yahoo!广告系统也使用ZooKeeper来实现可靠的服务。

鼓励所有用户和开发人员加入社区并贡献他们的专业知识，有关更多信息，请参阅Apache上的Zookeeper项目。