ZooKeeper OverView

曾经终败给现在 2022-07-17 04:50 146阅读 0赞

## ZooKeeper：一个分布式应用程序协调服务 ##

Zookeeper 是一个分布式的、开源的协调服务，用在分布式应用程序中。它公开了一组简单的原语，分布式应用程序可以基于这些原语之上构建更高层的分布式服务用于实现同步、配置管理、分组和命名等。Zookeeper被设计的容易编程，它使用一种类似于文件系统的目录树结构的数据模型，以java方式运行，有java绑定和c的绑定。

协调服务是出了名的难得到正确的实现，尤其容易产生诸如竟态条件、死锁等错误。Zookeeper 背后的动机就是减轻分布式应用程序自己实现协调服务的难度。

### 设计目标 ###

**Zookeeper很简单。** ZooKeeper使分布式进程可以通过一种类似于标准文件系统的共享的层次化的命名空间进行相互协调。命名空间由称为znode的数据寄存器组成，在Zookeeper的语义里，这类似于文件和目录。不同于为存储而设计的典型的文件系统，ZooKeeper的数据是保持在内存中的，这意味着可以达到高吞吐量和低延迟。

Zookeeper的实现着重于高性能、高可用性和严格的顺序访问。在性能方面，Zookeeper适用于大型的分布式系统。在可靠性方面，Zookeeper能够避免单点失效。严格顺序意味着可以在客户端实现复杂的同步原语。

**Zookeeper是可集群的（可复制）。** 像协调分布式进程一样，Zookeeper在被称为“ensemble” 的一组主机之间进行集群（复制）。

![Zookeeper Service][]

组成Zookeeper服务的每个服务器都必须相互知道对方。它们维护着一份在内存中的状态镜像，以及持久存储的事务日志和快照。只要这些服务器中的大多数是可用的，整个Zookeeper服务就是可用的。

客户端连接到一个Zookeeper服务器，客户端维护一个TCP连接，通过它发送请求，得到响应，得到监视事件和发送心跳。如果该TCP连接中断了，客户端将连接到另外一个服务器。

**Zookeeper是有序的。** Zookeeper用一个数字标记每一次更新，来反映所有 Zookeeper 事务的顺序。并发的操作可以这些次序来实现更高层的抽象，比如同步原语。  
**Zookeeper是快速的。** 在以“读”为主的负载时尤其快速。Zookeeper的应用程序运行在数以千计的计算机上，而当“读”远多于“写”，读写比达到10比1左右时，表现最好。

## 数据模型和层次化命名空间 ##

ZooKeeper提供的命名空间更像是一个标准的文件系统。一个名称由以斜线”/”分隔的路径元素组成。ZooKeeper命名空间中的每一个节点都通过路径唯一标识。

![ZooKeeper's Hierarchical Namespace][ZooKeeper_s Hierarchical Namespace]

### 节点和瞬时节点 ###

与标准的文件系统不同的是，Zookeeper命名空间中的每一个节点可以既有数据同时也有子节点。就像一种文件系统，允许一个文件同时也是一个目录。（Zookeeper设计用于保存协调数据：状态信息、配置、位置信息等等，所以这些保存在节点中的数据通常都很小，在Byte到KB之间）为了清晰的讨论这些Zookeeper的数据节点，Zookeeper用`znode`这一术语来表示这些节点。

`Znodes`维护一个数据结构，包括数据的修改的版本号、时间戳以及访问控制列表（ACL）的变化，用于缓存验证和协调更新。每次znode的数据变化，版本号随之递增。例如：当一个客户端检索数据时，同时也收到数据对应的版本号。

命名空间中的每个znode的数据的读写都是原子的。读取一个znode将获得其全部的数据，而写入则替换其全部的数据。每个节点有一个访问控制列表（ACL）用于约束什么样的访问者可以进行哪些操作。

ZooKeeper还有“瞬时节点”的概念。当创建瞬时节点的客户端会话一直保持活动，瞬时节点就一直存在。而当会话终结时，瞬时节点被删除。

### 条件更新和监视 ###

ZooKeeper 支持“监视”(watch)的概念。客户端可以在znode上设置一个监视(watch)。当znode发生改变时，“监视”会被触发同时被移除。当“监视”被触发时，客户端会收到一个描述znode变更的数据包。如果客户端和Zookeeper服务器之间的连接断开时，客户端将会收到一个本地通知。

### 保证 ###

Zookeeper非常快速也非常简单。不过，由于它的目标是作为构建诸如“同步”这类更复杂服务的基础，所以它提供了一组保证：

*  顺序一致性 - 来自客户端的更新请求将会按照它们的发送的顺序被应用
 *  原子性 - 更改要么成功，要么失败，不会存在部分成功或失败的结果
 *  单一系统映像 - 客户端会看到Zookeeper服务的相同的视图，而无论它们连到具体哪一个服务器上
 *  可靠性 - 一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖
 *  及时性 - 客户端看到的系统视图在一定的时间范围内总是最新的

## 简单的API ##

Zookeeper的设计目标之一就是提供简单的编程接口。于是，它只提供了以下的操作：

create ： 在（命名空间）树的一个特定地址上创建一个节点
    delete ： 删除一个节点
    exists ： 检测在一个地址上是否存在节点
    get data ： 从节点读取数据
    set data ：将数据写入节点
    get children ：检索子节点列表
    sync ： 等待数据传播完成

## 实现 ##

[Zookeeper组件][Zookeeper]展示了Zookeeper服务的高层组件。除了`Request Processor`，构成Zookeeper服务的所有服务器都会复制一份这些组件的拷贝。  
![ZooKeeper Components][]

“复制的数据库”是包含了整个数据树的内存数据库。所有更改都会记录到磁盘以便可恢复。数据先序列化到磁盘而后写入到内存数据库。

每一个Zookeeper服务器都向客户端提供服务，客户端连接到一个确切的Zookeeper服务器提交请求。读请求从服务器数据库的本地拷贝中获取。改变Zookeeper服务状态的请求以及写入请求会通过一个一致性协议进行处理。

作为协议的一部分，客户端的所有写入请求都被转发到一个单独的服务器，该服务器被称为`leader`。而其余的服务器，被称为`follower`，从`leader`接收消息并对消息的交付同步。消息层的作用是维护`leader`失效时的更新替换以及`leader`和`follower`之间的同步。

Zookeeper使用自定义的原子消息协议。由于消息层是原子的，Zookeeper可以保证本地的复制品的一致性。当`leader`收到一个写入请求时，它计算系统所处的状态以及何时写入请求，并将此转换为一个包含新状态的事务。

## 使用 ##

Zookeeper的编程接口特别简单，然而通过这些编程接口可以更高阶的操作，例如同步原语、成员分组、所有权等等。

## 性能 ##

Zookeeper被设计为高性能。但实际是否如此呢？在雅虎研发中心的Zookeeper开发团队的研究结果表明的确如此。（参见下图：Zookeeper 吞吐量随读写比的变化）。在“读”多于“写”的应用程序中尤其高性能，因为“写”会导致在所有的服务器间同步状态。（“读”多于“写”是协调服务的典型场景。）

Zookeeper吞吐量随读写比的变化:  
![ZooKeeper Throughput as the Read-Write Ratio Varies][]

图“Zookeeper 吞吐量随读写比的变化” 是 Zookeeper3.2 版本运行于 Dual 2Gh Xeon 和 2 个 15K RPM 的 SATA 硬盘驱动器的服务器上的结果。一个驱动器用作Zookeeper专用的日志设备。快照写到操作系统驱动器。写请求是1K数据的写入，读请求是1K的数据读取。“Servers”标出了 Zookeeper集合的大小，即组成Zookeeper服务的服务器的数量。大约30台其它的服务器被用作模拟客户端。Zookeeper集合被配置为不允许客户端连接到`Leader`。

> 注：3.2版本的读/写性能相对于[3.1版本以前][3.1]有最多达2倍的提升。

基准测试也表明了Zookeeper的可靠性。图“错误发生的情况下的可靠性”展示了Zookeeper是如何应对各种不同的失效的。图中标注的事件如下：

1.  一个`Follower`失效然后恢复。
2.  另一个不同的`Follower`失效然后恢复。
3.  `Leader`失效。
4.  两个`Follower`失效然后恢复。
5.  另一个`Leader`失效。

## 可靠性 ##

为了演示当发生错误时，系统是如何表现的，我们运行由7个机器组成的ZooKeeper服务。我们也运行和之前一样的饱和基准，但是此时我们保持30%恒速写性能，而这个速度是我们预期保守的工作负载。

错误发生的情况下的可靠性:

![错误发生的情况下的可靠性][zkperfreliability.jpg]

从这张图中可以得到几点重要的结果。首先，如果`follower`失效并快速恢复，虽然存在失效，但是Zookeeper能够维持高吞吐量。但也许更重要的是，`leader`选举算法使系统足够快地恢复，避免了吞吐量的总体下降。从观察结果来看，Zookeeper花了不到200毫秒的时间选举出了一个新的 leader。第三，只要`follower`恢复，Zookeeper的吞吐量能够再次上升到刚开始处理请求时的水平。

## 关于ZooKeeper项目 ##

Zookeeper 已经被成功地用在许多工业级的应用。在雅虎，Zookeeper被用作雅虎消息中间件的协调和失效恢复服务，该系统是一个高伸缩性的发布订阅系统，管理着成千上万的主题复制和数据分发。Zookeeper还被用在雅虎爬虫的抓取服务上，用于管理失效恢复。许多雅虎的广告系统也用 Zookeeper实现可靠的服务。

我们鼓励所有的用户和开发者都加入社区，并贡献他们的专业知识。更多详细信息请参见[Zookeeper Project on Apache][]。

--------------------

英文原文：  
[ZooKeeper 3.4 Documentation ZooKeeper OverView][]  
备注：  
转载请注明出处：[http://blog.csdn.net/wsyw126/article/details/52390668][http_blog.csdn.net_wsyw126_article_details_52390668]  
作者：WSYW126

[Zookeeper Service]: /images/20220717/6a622e82257d4e018b9697f1247e758c.png
[ZooKeeper_s Hierarchical Namespace]: /images/20220717/55dfeccaf0714e01a861ca8626a9eb67.png
[Zookeeper]: http://zookeeper.apache.org/doc/r3.4.8/zookeeperOver.html#fg_zkComponents
[ZooKeeper Components]: /images/20220717/21912ecb205d42a8936de7ad33476afb.png
[ZooKeeper Throughput as the Read-Write Ratio Varies]: /images/20220717/0fe799b6b3cd4ae2b4360c427d2a769a.png
[3.1]: http://zookeeper.apache.org/docs/r3.1.1/zookeeperOver.html#Performance
[zkperfreliability.jpg]: /images/20220717/4a89786a1b3f4728a9d01f62eb6980e3.png
[Zookeeper Project on Apache]: http://zookeeper.apache.org/
[ZooKeeper 3.4 Documentation ZooKeeper OverView]: http://zookeeper.apache.org/doc/r3.4.8/zookeeperOver.html
[http_blog.csdn.net_wsyw126_article_details_52390668]: http://blog.csdn.net/wsyw126/article/details/52390668