动物园管理员
ZooKeeper：分布式应用程序的分布式协调服务
ZooKeeper 是分布式应用程序的分布式开源协调服务。它公开了一组简单的原语，分布式应用程序可以基于这些原语实现更高级别的同步、配置维护、组和命名服务。它被设计为易于编程，并使用一种数据模型，该模型以熟悉的文件系统目录树结构为风格。它在 Java 中运行，并具有 Java 和 C 的绑定。
众所周知，协调服务很难做好。它们特别容易出现竞争条件和死锁等错误。ZooKeeper 背后的动机是减轻分布式应用程序从头开始实现协调服务的责任。
设计目标
ZooKeeper 很简单。ZooKeeper 允许分布式进程通过共享的分层命名空间相互协调，该命名空间的组织方式类似于标准文件系统。命名空间由数据寄存器组成——在 ZooKeeper 用语中称为 znodes——它们类似于文件和目录。与为存储而设计的典型文件系统不同，ZooKeeper 数据保存在内存中，这意味着 ZooKeeper 可以实现高吞吐量和低延迟数字。
ZooKeeper 实施非常重视高性能、高可用性、严格有序的访问。ZooKeeper 的性能方面意味着它可以用于大型分布式系统。可靠性方面使其不会成为单点故障。严格的排序意味着可以在客户端实现复杂的同步原语。
ZooKeeper 被复制。与它协调的分布式进程一样，ZooKeeper 本身旨在通过一组称为 ensemble 的主机进行复制。
组成 ZooKeeper 服务的服务器必须相互了解。它们在内存中维护状态图像，以及持久存储中的事务日志和快照。只要大多数服务器可用，ZooKeeper 服务就可用。
客户端连接到单个 ZooKeeper 服务器。客户端维护一个 TCP 连接，通过它发送请求、获取响应、获取监视事件并发送心跳。如果与服务器的 TCP 连接中断，客户端将连接到不同的服务器。
ZooKeeper 已订购。ZooKeeper 使用反映所有 ZooKeeper 事务顺序的数字标记每个更新。后续操作可以使用该顺序来实现更高级别的抽象，例如同步原语。
ZooKeeper 速度很快。它在“以读取为主”的工作负载中尤其快。ZooKeeper 应用程序在数千台机器上运行，它在读取比写入更常见的情况下表现最佳，比率约为 10:1。
数据模型和分层命名空间
ZooKeeper 提供的命名空间很像标准文件系统。名称是由斜杠 (/) 分隔的一系列路径元素。ZooKeeper 命名空间中的每个节点都由路径标识。
ZooKeeper 的分层命名空间
节点和临时节点
与标准文件系统不同，ZooKeeper 命名空间中的每个节点都可以拥有与其关联的数据以及子节点。这就像拥有一个允许文件也成为目录的文件系统。（ZooKeeper 被设计用来存储协调数据：状态信息、配置、位置信息等，所以每个节点存储的数据通常很小，在字节到千字节的范围内。）我们使用术语znode来明确我们正在谈论 ZooKeeper 数据节点。
Znode 维护一个统计结构，其中包括数据更改、ACL 更改和时间戳的版本号，以允许缓存验证和协调更新。每次 znode 的数据更改时，版本号都会增加。例如，每当客户端检索数据时，它也会收到数据的版本。
存储在命名空间中每个 znode 的数据是原子读取和写入的。读取获取与 znode 关联的所有数据字节，写入替换所有数据。每个节点都有一个访问控制列表 (ACL)，它限制谁可以做什么。
ZooKeeper 也有临时节点的概念。只要创建 znode 的会话处于活动状态，这些 znode 就存在。当会话结束时，znode 被删除。
有条件的更新和监视
ZooKeeper支持 watch 的概念。客户端可以在 znode 上设置监视。当 znode 发生变化时，watch 将被触发并移除。当 watch 被触发时，客户端会收到一个数据包，说明 znode 已更改。如果客户端和其中一个 ZooKeeper 服务器之间的连接断开，客户端将收到本地通知。
3.6.0 中的新功能：客户端还可以在 znode 上设置永久的递归监视，这些监视在触发时不会被删除，并且会以递归方式触发已注册 znode 以及任何子 znode 上的更改。
保证
ZooKeeper 非常快速且非常简单。但是，由于它的目标是成为构建更复杂服务（例如同步）的基础，因此它提供了一组保证。这些都是：
- 顺序一致性 - 来自客户端的更新将按照它们发送的顺序应用。
- 原子性 - 更新成功或失败。没有部分结果。
- 单一系统映像 - 客户端将看到相同的服务视图，而不管它连接到的服务器如何。即，即使客户端故障转移到具有相同会话的不同服务器，客户端也永远不会看到系统的旧视图。
- 可靠性 - 应用更新后，它将从那时起持续存在，直到客户端覆盖更新。
- 及时性——系统的客户视图保证在一定的时间范围内是最新的。
简单的 API
ZooKeeper 的设计目标之一是提供一个非常简单的编程接口。因此，它仅支持以下操作：
-
create：在树中的某个位置创建一个节点
-
delete : 删除一个节点
-
exists：测试节点是否存在于某个位置
-
获取数据：从节点读取数据
-
设置数据：将数据写入节点
-
获取子节点：检索节点的子节点列表
-
sync：等待数据传播
执行
ZooKeeper 组件展示了 ZooKeeper 服务的高级组件。除了请求处理器之外，组成 ZooKeeper 服务的每个服务器都复制自己的每个组件的副本。
复制数据库是包含整个数据树的内存数据库。更新被记录到磁盘以便恢复，写入在应用到内存数据库之前被序列化到磁盘。
每个 ZooKeeper 服务器都服务于客户端。客户端仅连接到一台服务器以提交请求。从每个服务器数据库的本地副本为读取请求提供服务。改变服务状态的请求，写请求，由协议协议处理。
作为协议协议的一部分，来自客户端的所有写入请求都被转发到单个服务器，称为领导者。ZooKeeper 服务器的其余部分，称为追随者，接收来自领导者的消息提议并同意消息传递。消息传递层负责在失败时替换领导者并将追随者与领导者同步。
ZooKeeper 使用自定义原子消息传递协议。由于消息传递层是原子的，ZooKeeper 可以保证本地副本永远不会发散。当领导者收到一个写请求时，它会计算系统在应用写时的状态，并将其转换为捕获这个新状态的事务。
用途
ZooKeeper 的编程接口故意简单。但是，使用它，您可以实现更高阶的操作，例如同步原语、组成员资格、所有权等。
表现
ZooKeeper 被设计为高性能。但是是吗？ZooKeeper 在 Yahoo! 的开发团队的成果 研究表明确实如此。（请参阅ZooKeeper 吞吐量随着读写比率的变化。）它在读取数超过写入数的应用程序中具有特别高的性能，因为写入涉及同步所有服务器的状态。（协调服务通常会出现读取次数超过写入次数的情况。）
ZooKeeper 吞吐量随读写比变化是 ZooKeeper 版本 3.2 在具有双 2Ghz Xeon 和两个 SATA 15K RPM 驱动器的服务器上运行的吞吐量图。一个驱动器用作专用的 ZooKeeper 日志设备。快照被写入操作系统驱动器。写入请求为 1K 写入，读取为 1K 读取。“Servers”表示 ZooKeeper 集合的大小，即构成服务的服务器数量。大约 30 台其他服务器用于模拟客户端。ZooKeeper 集成被配置为领导者不允许来自客户端的连接。
笔记
在 3.2 版本中，与之前的 3.1 版本相比，r/w 性能提高了约 2 倍。
基准也表明它也是可靠的。存在错误时的可靠性显示了部署如何响应各种故障。图中标注的事件如下：
- 追随者的失败和恢复
- 不同追随者的失败和恢复
- 领袖的失败
- 两个追随者的故障和恢复
- 另一位领导者的失败
可靠性
为了显示系统在注入故障时的行为，我们运行了一个由 7 台机器组成的 ZooKeeper 服务。我们运行与之前相同的饱和度基准测试，但这次我们将写入百分比保持在恒定的 30%，这是我们预期工作负载的保守比率。
这张图有一些重要的观察结果。首先，如果追随者失败并迅速恢复，那么 ZooKeeper 能够在失败的情况下维持高吞吐量。但也许更重要的是，领导者选举算法允许系统足够快地恢复，以防止吞吐量大幅下降。在我们的观察中，ZooKeeper 用不到 200 毫秒的时间来选举一个新的领导者。第三，随着追随者的恢复，ZooKeeper 能够在他们开始处理请求后再次提高吞吐量。
ZooKeeper 项目
ZooKeeper 已成功用于许多工业应用。它用于 Yahoo! 作为 Yahoo! 的协调和故障恢复服务 Message Broker，它是一个高度可扩展的发布-订阅系统，可管理数千个主题以进行复制和数据传递。它被 Yahoo! 的 Fetching Service 使用。爬虫，它还管理故障恢复。一些雅虎！广告系统也使用 ZooKeeper 来实现可靠的服务。
鼓励所有用户和开发人员加入社区并贡献他们的专业知识。有关更多信息，请参阅Apache 上的 Zookeeper 项目。