ZooKeeper概述（一）

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

ZooKeeper是一个为分布式应用提供的分布的开源的协调服务。它暴露一组简单的原子操做，分布式系统能够在这之上为同步，配置管理，和组和命名实现更高级的服务。它被设计来编程简单，而且使用一个跟文件系统类似的数据模型。它在Java中运行而且绑定Java和C。

协调服务众所周知地很是难正确。它们特别易于竞争条件和死锁的错误。ZooKeeper后面的动机是减轻分布式应用

从头开始实现协调服务的责任。

设计目标

 

ZooKeeper是简单的。ZooKeeper容许分布式的进程彼此协调经过一个共享的结构化的命名空间，这个命名空间组织结构和标准的文件系统类似。这个命名空间包括数据注册器 - 称为znodes,用ZooKeeper的说话 - 而且他们和文件和文件夹类似。和典型的文件系统设计用来存储不一样的是，ZooKeeper的数据保存在内存中，这意为着ZooKeeper能够达到很高的吞吐量和低延迟。

ZooKeeper实现给高性能，高可用，严格的顺序访问增长了一个保险。ZooKeeper的高性能方面意为着它能够被用在大的分布式系统。可靠性避免它成为一个失败单点。严格的访问顺序意为复杂的同步原语能够在客户端实现。

ZooKeeper是可复制的。和它协调的分布的进程同样，ZooKeeper自己也打算是可复制的经过一组称为集群的主机。

ZooKeeper Service

组成ZooKeeper的服务的服务器必须都知道彼此。他们维护一个在内存中的状态镜像，和一个事务日志和一个持久存储中的快照。只要大多数是可用的，ZooKeeper服务就是可用的。

客户端链接到一个单独的ZooKeeper服务器。客户端维护一个TCP链接，经过这个连接它发送请求，获取响应，获取watch事件，而且发送心跳。若是到服务器的TCP链接中断，客户端将连到另外一个不一样的服务器。

ZooKeeper是有序的。ZooKeeper用一个数字来记录每一次更新，这个数字反映了全部ZooKeeper事务的顺序，随后的操做可能使用这个顺序来实现 更高级的抽象，好比同步原语

ZooKeeper是快速的。它至关的快在读为主的工做场景中。ZooKeeper应用运行在成千上万个机器上，而且它表现很好在读比写广泛的，比例大约10:1的时候。

数据模型和分层次的命名空间

 

ZooKeeper提供的命名空间很是像一个标准的文件系统。一个名字是一系列的被/分开的路径元素，在ZooKeeper中每个节点被标示为一个路径。

ZooKeeper's Hierarchical Namespace

节点和短暂的节点

和标准的文件系统不一样，每个ZooKeeper中的节点能够有数据和它关联，子节点也同样。就像一个文件系统容许一个文件是一个目录。（ZooKeeper被设计用来存储协调数据:状态信息，配置，地址信息，等等。因此存储在每个节点的数据一般很小，在字节和千字节的范围。）咱们使用znode来使咱们清楚咱们正在讨论ZooKeeper的数据节点。

Znodes维护一个数据结构包括数据改变，ACL改变，的版本号和时间戳，来容许缓存检验和协调更新。每次一个znode的数据改变，版本号增长。例如，当客户端检索数据，它也收到数据的版本。

在命名空间里的每个节点存储的数据原子地读和写。读获得一个znode关联的全部的数据字节，而且写替换全部的数据。每个节点有一个访问控制列表(ACL)来限制谁能作和作什么。

ZooKeeper也有短暂节点的概念。这些节点存在只要建立它们的会话是活跃的。当会话结束，这个节点也就被删除。短暂的节点是有用的当你想实现[tbd]。

条件更新和监视器

ZooKeeper支持监视的概念，客户端能够在znode上设置一个监视器，监视器将被触发和删除当znode改变的时候。当监视器被触发的时候，客户端收到一个数据包说明znode已经被改变。而且若是客户端和zookeeper服务器之间的连接已经断掉，客户端将会收到一个本地的通知，这些能够被用来实现tbd.

担保

ZooKeeper是很是快和简单的。尽管它的目标是构建例如同步这样更复杂服务的基础，它提供了一组保证它们是:

• 顺序的一致性 - 来自客户端的更新将会按照它们发送的顺序应用。
• 原子性 - 更新要么成功要么失败，没有部分结果。
• 单一系统映象 - 客户端将会看到服务端相同的视图，无论它连的是那一个服务端。
• 可靠性 - 一旦应用了一个更新，它将会从更新的时刻持续到另外一个更新覆盖它。
• 时效性 - 系统的客户端视图保证是最新的在必定的时间内。

有关这些的更多信息，而且它们怎么被使用，参考[tbd]

简单的API

ZooKeeper的其中一个设计目标就是提供一个简单的编程接口，做为结果，它只提供了这些操做:

create

在树的一个位置上建立一个节点

delete

删除一个节点

exists

检验一个节点是否在这个位置

get data

从节点读取数据

set data

往节点写数据

get children

检索一个节点的孩子节点列表

sync

等待数据被传播

对于这些更深刻的讨论，和他们怎么被用来实现更高级的操做，请参考[tbd]

实现

ZooKeeper Components展现了ZooKeepere服务更高级的组件，除了请求处理器，每一个组成ZooKeeper服务的服务器上复制本身的每一个组件的副本。

 

ZooKeeper Components

复制的数据库是一个内存数据库，包含了整个数据树。更新被记录到硬盘为了恢复。而且写操做被序列化到磁盘上在它应用到内存数据训以前。

每个ZooKeeper服务器给客户端提供服务，客户端连到其中一个服务器来提交请求。请请求被每个服务器的数据库的本地副本提供服务。改变服务器状态的请求，写请求，被一致协议处理。

做为一致性协议的一部分，全部从客户端来的写请求被推送到一个服务器，就是所谓的领导者。剩下的其它ZooKeeper服务器，就是追随者,它们从领导者接收消息提议，并赞成消息传递。消息层负责更换失效的领导者而且同步领导者和追随者。

ZooKeeper使用自定义的原子消息协议。由于消息层是原子的，ZooKeeper能够保证本地复制永远不会出现分歧。当领导者收到一个写请求，它计算当更新被应用时系统处于怎么状态，而且转换这个请求为到一个事务中来捕获这个状态。

使用

ZooKeeper的编程接口至关简单，利用它你能够实现更高级的顺序操做，例如同步原语，群成员管理，全部权，等待。一些分布式系统已经使用它来[],更多信息，参考[tbd]。

性能

ZooKeeper是设计为了高性能的。可是是真的么？来自Yahoo! Research的ZooKeeper的开发团队的结果表示它是(参考ZooKeeper Throughput as the Read-Write Ratio Varies.)。在读比写多的应用中它有更高的性能，由于写涉及同步全部全部服务器的状态。

ZooKeeper Throughput as the Read-Write Ratio Varies

图片ZooKeeper Throughput as the Read-Write Ratio Varies是一个运行在dual 2Ghz Xeon和两个15K转的SATA驱动器的3.2版本的ZooKeeper的吞吐图。其中一个驱动器专门用来做为ZooKeeper的日志记录设备，快照被写入到系统驱动器。写请求是1k读请求也是1k."Servers"表示ZooKeeper集群的数量，组成服务的服务器数量。大概30个其它有服务器用来模拟客户端。这个ZooKeeper被配置成领导者不容许和客户端相连。

注意:

3.2版本的读写性能相比之3.1版本的性能提升了大约2倍

基准测试也表示了它是可靠的。Reliability in the Presence of Errors展现了若是对各类故障作出响应。图片中标记的事件是下面这些:

1. 追随者的失效和恢复。

2. 不一样的追随都的失效和恢复。

3. 领导者的失效

4. 两个追随者的失效和恢复

5. 另外一个领导者的失效

可靠性

为了展现系统随着时间注入失败的的行为，咱们运行了一个7台机器组成 的ZooKeeper的服务。咱们以前运行过这个基准测试。可是此次咱们保持写的比例在30%，这是咱们指望的工做负荷的保守比例。

Reliability in the Presence of Errors

从这个图中能够看到几个重要言论。首先，若是追随者失效而且很快地恢复，ZooKeeper能够维持一个高的吞吐量尽管有失效。可是也许更重要的是。领导者的选举逻辑容许系统很快地恢复来避免吞吐量降低的太厉害。在咱们的观察中，ZooKeeper消耗低于200ms来选出一个新领导者。当追随者恢复，ZooKeeper能够再次提高吞吐量一旦它们再次处理请求。

The ZooKeeper Project

ZooKeeper已经成功地应用在不少工业应用中。它在Yahoo!为Yahoo!的Message Broker做为协调和失效恢复服务来使用。它是一个高度可扩展的发布订阅系统管理者成千上万个主题为了复制和数据传递。它被用在Yahoo!的Fetech Service,它也管理失效恢复。许多的Yahoo!广告系统也使用ZooKeeper来实现可靠性服务。