ZooKeeper 概览(1)

简介

ZooKeeper是一种高性能的分布式应用协调服务。它在一个简单的接口中公开公共服务，例如命名、配置管理、同步和组服务，这样你就不必从头编写它们。你可以使用它来实现共识、组管理、领导人选举和到场协议。您可以根据自己的特定需要在此基础上进行构建。

 

概览：

ZooKeeper: 分布式协调服务

ZooKeeper是一个开源的为分布式应用提供分布式协调的服务。它公开了一组简单的原语，分布式应用程序可以基于这些原语实现更高级别的服务，包括同步、维护配置、组和命名。它的设计易于编程，它使用一个遵循文件系统中常见的目录树结构的数据模型。它在Java环境中运行，对Java和C都有绑定。

协调服务是出了名的难。它们特别容易出错，如竞态条件和死锁。ZooKeeper背后的动机是让分布式应用从零开始实现一站式协调服务

设计目标

ZooKeeper很简单。通过共享一个类似于标准文件系统结构的层次名称空间，Zookeeper允许分布式进程进行各自的协调。名称空间中包含了注册数据——即所谓的znodes，它们类似于文件和目录。Zookeeper不像文件系统，目的是数据存储，Zookeeper的数据存放在内存中，这意味着zookeeper具有高吞吐量和低延迟的优点。

ZooKeeper非常注重高性能、高可用性、严格有序的访问。ZooKeeper的性能方面意味着它可以在大型分布式系统中使用。可靠性方面使它不会出现单点故障。严格有序意味着可以在客户端实现复杂的同步原语。

ZooKeeper是复制的。与它所协调的分布式进程一样，ZooKeeper本身也打算在一组主机上进行复制。

组成ZooKeeper的每个server之间都必须互相了解。每个server都维护状态信息(state)的内存映像，以及持久存储中的事务日志和快照。只要ZooKeeper中的大多数server可用，ZooKeeper服务就可用。

每个client连接到ZooKeeper集群中的某个server。客户端会与之建立TCP连接，通过该TCP连接来发送请求、获取响应、获取观察事件(watch events)以及发送心跳。如果TCP连接中断，客户端将连接到另一个server。

ZooKeeper是有序的。ZooKeeper给每次更新都贴上一个数字，这个数字反映了所有ZooKeeper事务的顺序。后续操作可以使用这个顺序来实现高级抽象，例如同步原语。

ZooKeeper速度很快，特别是在"以读为主"的工作负载中尤其快速。ZooKeeper应用程序可用在数千台机器上运行，在多读少写(比率在10:1左右)的环境中表现最好。

数据模型和有层次的名称空间

ZooKeeper提供的名称空间非常类似于标准文件系统。名称是由斜线(/)分隔的路径元素序列。在ZooKeeper名称空间中的每一个节点都是通过一条路径来标识的。

节点和临时节点

与标准文件系统不同的是，ZooKeeper名称空间中的每个节点(路径)都可以有与之关联的数据，子节点也如此(译注：即节点的路径自身携带数据)。这就像是一个既文件也目录的文件系统。(ZooKeeper的目的是存储协调数据:状态信息、配置、位置信息等，所以每个节点存储的数据通常都很小，一般都是kb级别的)。我们使用术语znode来明确说明我们正在讨论ZooKeeper数据节点。

znode维护一个包含数据更改版本号、ACL更改版本号和时间戳版本号的stat结构，以便能够做缓存验证和协调更新。每当znode的数据发生变化，版本号就会增加。例如，客户端每次检索数据的同时，也会接收数据的版本信息。

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

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

协调更新和watch

ZooKeeper支持观察(watch)的概念。客户端可以在znode上设置一个watch。当znode更改时，将触发并删除一个watch。当watch被触发时，客户端会收到一个通知znode已更改的数据包。如果客户端和ZooKeeper server之间的TCP连接中断了，客户端将收到本地通知。这些可用于[tbd]。

ZooKeeper的保证

ZooKeeper快速又简单。但由于它的目标是作为构建更复杂服务(如同步)的基础，所以它要实现一些保证。包括：

• 序列的一致性：(Sequential Consistency)来自客户端的更新将按照发送的顺序进行应用。
• 原子性：(Atomicity)更新要么成功，要么失败。没有部分成功、失败的结果。
• 单系统映像：(Single System Image)无论连接到ZooKeeper中的哪个server，客户端都将看到相同的服务视图。
• 可靠性：(Reliability)一旦应用了更新，它将一直持续到有客户端对它做了覆盖更新。
• 时效性：(Timeliness)保证客户端看到的视图在一定的时间范围内是最新的。

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

Simple API

ZooKeeper的一个设计目标是提供非常简单的编程接口。因此，它只支持以下几个操作：

1. create：在树中的某个位置创建一个节点。
2. delete：删除一个节点。
3. exists：测试一个节点是否存在。
4. get data：读取节点数据。
5. set data：向节点中写入数据。
6. get children：检索某节点的子节点列表。
7. sync：等待要传播的数据。

更深入内容，以及如何使用它们实现更高级别的操作，请参阅[tbd]。

Implementation

下图显示了ZooKeeper服务的高层组件。除了request processor，构成ZooKeeper Service的每个server都复制自己的每个组件副本。

replicated database是包含整个数据树(data tree)的内存数据库。每次发起的更新都会将其记录到磁盘中的日志，以便以后能够进行恢复(recovery)，在更新真正应用到内存数据库之前，还会先将更新序列化到磁盘中。

每个ZooKeeper server都会为客户端提供服务。客户端连接到一个server来提交request。对于read request，每个server会从本地database的副本中提供服务。对于write request，这些请求会更改服务状态，它们由协商协议(agreement procotol)来处理。

作为协商协议(agreement procotol)的一部分，所有来自客户端的write request都被转发到一个称为leader的server上。ZooKeeper中的其它server，都称为follower，它们接收来自leader的消息，并传递那些达成一致的消息。消息层(messaging layer)负责在leader故障时选举新的leader，并剩余的follower和新的leader保持同步。

ZooKeeper使用一个自定义的原子消息传递协议。由于该消息层是原子性的，ZooKeeper可以保证本地副本永远不会出现分歧。当leader收到write request时，它会计算当写操作被执行时系统状态，并将其转换为带有该状态的事务。

ZooKeeper的使用

ZooKeeper的编程接口很简单。但有了它，您可以实现更高级的操作，比如同步原语、组成员关系(group membership)、所有权(ownership)等等。更多信息请参阅[tbd]。

ZooKeeper性能

ZooKeeper具有高性能。真的如此吗？雅虎ZooKeeper的开发团队的研究结果已经表明确实如此。(参见下图)。当读操作比写操作更频繁时，ZooKeeper的性能非常高，因为写操作会调用所有节点的状态同步。(协调服务的典型情况就是多读少写)。

注意：在3.2版本中，r/w的性能比3.1版本提高了大约2倍。

Benchmarks also indicate that it is reliable, too. Reliability in the Presence of Errors shows how a deployment responds to various failures. The events marked in the figure are the following:

Failure and recovery of a follower
Failure and recovery of a different follower
Failure of the leader
Failure and recovery of two followers
Failure of another leader

Reliability

To show the behavior of the system over time as failures are injected we ran a ZooKeeper service made up of 7 machines. We ran the same saturation benchmark as before, but this time we kept the write percentage at a constant 30%, which is a conservative ratio of our expected workloads.

There are a few important observations from this graph. First, if followers fail and recover quickly, then ZooKeeper is able to sustain a high throughput despite the failure. But maybe more importantly, the leader election algorithm allows for the system to recover fast enough to prevent throughput from dropping substantially. In our observations, ZooKeeper takes less than 200ms to elect a new leader. Third, as followers recover, ZooKeeper is able to raise throughput again once they start processing requests.