ZooKeeper 简介

ZooKeeper: 分布式应用的分布式协调服务

ZooKeeper 是一个用于分布式应用的分布式、开源的协调服务。它开放了一套简单的函数，分布式应用可以在此之上为上层服务实现分布式同步、配置维护、组服务、命名等功能。它使用了一个类似于目录树结构的文件系统作为数据模型，易于编程。它运行在java上，而且已经有了Java和C的客户端。

众所周知，协调服务是很难正确实现的。它们很容易出现条件竞争和死锁等错误。ZooKeeper 出现的目的就是解除为分布式应用实现协调服务的痛点。

设计目标

ZooKeeper is simple. ZooKeeper 允许分布式的进程通过共享命名空间层次来相互协调，共享命名空间层次有点类似于标准的文件系统。命名空间由数据寄存器组成，ZooKeeper 中的说法是 znodes，类似于文件和目录。与典型的文件系统不同，其被设计用于存储，ZooKeeper 数据存放在内存中。也就是说ZooKeeper 可以实现高吞吐量和低延迟数。
ZooKeeper 完美的实现了高性能、高可用、严格有序的访问。性能方面，ZooKeeper 可以用在大规模、分布式的系统中。可靠性方面，解决了单点障碍。严格有序意味着可以从客户端实现复杂的同步函数。
ZooKeeper is replicated. 类似于分布式进程协调，ZooKeeper 自身可被复制副本到一组主机上作为一个整体。

节点以及临时节点

与标准的文件系统不同，ZooKeeper 命名空间中的每个节点都存有与子节点相关的数据。它就像一个文件系统允许文件变成一个目录。(ZooKeeper 为存储协调数据而设计：状态信息、配置信息、路径信息等，因此每个节点存储的数据通常都很小，量级在B到KB之间。）我们用术语znode 来指ZooKeeper 数据节点。

Znodes 的数据结构中包括：数据变更的版本号、ACL 变更以及时间戳，以便缓存验证和协调更新。每次znode数据改变，版本号递增。例如，每当客户端收到数据，它将同时收到数据的版本。

命名空间中znode存储的数据是被原子性读写的。读操作可以获得Znode相关的全部数据，写操作将覆盖全部数据。每个及诶单有一个权限控制列表（ Access Control List ，ACL）来限制什么人可以干什么事。

ZooKeeper 也有临时节点的概念. 这些节点存在时间与会话一致，会话创建时znode生效。当会话结束时Znode被删除。临时节点对你实现功能非常有用，请参考[tbd]。

Conditional updates and watches

ZooKeeper 支持watches 的概念. 客户端可以在Znodes上设一个watch 。znode 改变时会触发或删除watch。当watch 被触发时，客户端会收到一个说“znode已被改变”的包。并且，如果客户端和一个Zookeeper服务器之间的连接中断时，客户端会收到一个本地通知。对于如何使用，请参考[tbd]。

保障

ZooKeeper 非常简单、迅速，这源自于它的设计目标。因此它为构建更复杂的服务提供了基础。例如为同步服务提供了一套保障：

• Sequential Consistency（顺序一致性） - 按照客户端的发送顺序进行更新。
• Atomicity（原子性）- 更新或成功或失败。不会有中间态的部分结果。
• Single System Image（单一系统镜像） - 无论客户端或服务器，连接到服务端后都能看到同样的视图。
• Reliability（可靠性） - 一旦应用一个更新，它将留存到客户端覆盖本次更新为止。
• Timeliness（时效性） - 在一段时间内保证系统的客户端视图是最新的。

更多信息以及他们怎么使用，请看[tbd]。

Simple API

ZooKeeper 其中一个设计目标是提供一个非常简单的编程接口。最终，它只支持这些操作：
_ create _ ：在树的某个位置创建一个节点
_ delete _ ：删除一个节点
_ exists _ ：测试某个位置的节点是否存在
_ get data _ ：从节点中获取数据
_ set data _ ：将数据写入节点中
_ get children _ ：获取子节点的列表
_ sync _ ：等待数据同步

对于更深入的探讨，以及他们怎样用于高级的操作，请参阅[tbd]。

实现

副本数据库是一个内存数据库，包含了整个数据树。更新日志序列化后记录在磁盘上，用来恢复数据。

每个Zookeeper服务器服务的客户端。客户端准确的连接到一个服务端后提交请求。读请求从每个服务器数据库的本地副本中响应。服务状态变更请求、写请求按照约定的协议执行。

协议的一部分，客户端的全部写请求被转到叫领导者（leader）的一个独立的服务端。其余的Zookeeper服务端，称为从服务（followers） ,从领导者（leader）那边接收消息并确认消息已收到。消息层负责在领导者发生故障时更换领导者并同步数据到从服务。

ZooKeeper 采用了一个自定义的原子消息协议。由于消息层是原子的，Zookeeper 可以保证本地副本没有偏差。当领导者收到一个写请求时，它会计算出系统何时做了写操作，并在事务中更新最新状态。

使用

ZooKeeper 的程序接口刻意简单化。With it, however, you can implement higher order operations, 通过它，你可以实现高层次的操作，例如同步服务，组成员，权限等。一些分布式应用用它： [tbd: 白皮书和视频演示中新增用途] 更多信息请看：[tbd]

性能

1. 从服务（follower）发生故障并恢复
2. 其他从服务（follower）发生故障并恢复
3. 领导者（leader）发生故障；
4. 两个从服务（follower）发生故障并恢复
5. 其他领导者（leader）发生故障

可靠性

我们运行一个由7台机器组成的Zookeeper服务，来展示系统故障时的表现。我们运行了与之前相同饱和度的服务，但这次我们将写操作比例保持在30%，30%是我们预期工作负载的保守比例。

这幅图可以观察出一些问题。首先，如果从服务（followers）失败并快速恢复，经管有失败但Zookeeper 任然可以提供高吞吐量的服务。但更重要的是，领导者选举算法（leader election algorithm）可以使系统快速恢复，足以防止吞吐量大幅下降。我们的观察中，ZooKeeper 以低于200ms 的速度选出了领导者（leader）。第三，从服务（followers ）恢复后，ZooKeeper 由于从服务（followers）恢复，它们开始处理请求，又能提高吞吐量。

ZooKeeper 项目