【转】【Apache ZooKeeper】官方文档

原文连接 http://blog.csdn.net/kobejayandy/article/details/11836051

 

ZooKeeper是一个高性能的用于协调分布式应用程序的服务。它将公共服务，好比命名、配置管理、同步化和集群服务封装进一个简单的接口，

能够直接用于实现共识（consensus）、集群管理、领导者选举和存在（presence ）协议。

能够在其上构建本身的分布式应用程序。

 

ZooKeeper使用一种相似文件系统目录树的数据模型，它能够运行于Java上而且具备Java和C的封装。

 

ZooKeeper的设计目标

简单——ZooKeeper容许分布式进程之间经过一个共享的层级命名空间来相互协做，这个命名空间以相似于文件系统的方式组织起来。

命名空间中的数据单元被称为znode，它至关于文件或者目录。与典型文件系统不一样的是，文件系统用于持久化存储，

而ZooKeeper的数据是保持在内存中的，这意味着ZooKeeper能达到很高的吞吐量和低延迟。

 

ZooKeeper的实现十分注重高性能、高可用性，和严格的顺序访问。高性能使得ZooKeeper能用于大规模分布式系统，

高可用性能避免单点故障，严格的顺序化意味着复杂的同步操做能够在客户端实现。

集群化——ZooKeeper自己也是有集群化的。以下图：

 

 

    客户端与单个服务端相连，它维持一个TCP链接，在其上发送请求，得到响应，得到监控事件和发送心跳检测。

若是到服务端的TCP链接断了，客户端会链接另外一个服务端。组成ZooKeeper服务的每一个服务端都知道其它服务端的存在，

它们维护一个服务端状态的内存镜像，连同事务日志和快照保存在持久化存储中，只要大部分服务端可用，ZooKeeper服务就可用。

 

顺序化——ZooKeeper为每一个更新操做都标记一个号码以反映事务的顺序。后来的操做使用这个顺序来实现高度的抽象，好比同步原语。

快速——这个特性在以读操做为主的工做中尤其明显。ZooKeeper应用程序运行于数以千计的机器中，当读操做与写操做的比例为10:1时，ZooKeeper能得到最佳性能。

 

数据模型和层级命名空间

ZooKeeper提供的命名空间极像一个标准的文件系统，一个名字是一个以/分隔的路径元素的序列，ZooKeeper命名空间的每一个节点经过路径来标识。

 

节点和临时节点

与标准文件系统不一样，ZooKeeper命名空间中的全部节点均可以有数据和子节点，这就像文件系统中容许一个文件同时是一个目录。

（ZooKeeper被设计用来存储管理服务的数据：状态信息、配置、位置信息等，因此每一个节点存储的数据一般很小，几字节到几K字节不等。）

咱们使用znode这个术语来表示ZooKeeper的数据节点。

znode维持一个stat结构，它包含数据变化的版本号、ACL变化和时间戳，以容许cache校验和协调化的更新。

每当znode的数据变化时，版本号将增长。一个客户端收到数据时，它也会收到数据的版本号。

 

保存在每一个znode中的数据都是自动读写的。读操做获取znode的全部数据，写操做替换掉znode的全部数据。

每一个节点有一个访问控制表（ACL）来限制谁能作哪些操做。

ZooKeeper也有临时节点的概念，这些znode只存在于建立znode的会话中。当会话结束，这些节点也就被删除了。

 

 

条件化更新和监控

ZooKeeper支持监控的概念。客户端能够在zonode上设置一个观察员。这个观察员会在znode发生变化时触发和移除

。当观察员被触发时，客户端会接收到一个说明znode发生变化的包

。若是客户端和服务端的链接断了，客户端会收到一个本地的通知。这些能够用于[tbd]

 

保证

ZooKeeper很是快，也很是简单。由于它的目标是成为构建复杂服务的基础，因此它提供一系列保证：

 

• 顺序一致性——来自客户端的更新操做将以它们发送的顺序来执行。
• 原子性——更新操做只有成功和失败两种结果，没有局部化结果。
• 单个系统镜像——无论客户端链接的服务器是哪一个，全部客户端看到的服务都是一个样子。
• 可靠性——一旦更新操做被执行，它将被持久化保存直到被下次更新所覆盖。
• 及时性——客户端所看到的系统在一个时间范围内是最新的。

 

简单的API

ZooKeeper的一个设计目标是易于编程。因此，它只支持以下操做：

create

    在命名空间的某个位置建立一个节点

delete

    删除一个节点

exists

    测试某位置的节点是否存在

get data

    从一个节点读取数据

set data

    往一个节点写数据

get children

    获取一个节点的子节点列表

sync

等待数据被传播以同步数据

 

 

实现

下图从较高层次说明了ZooKeeper的构成。除了请求处理单元，组成ZooKeeper服务的每一个服务端都会备份它的每一个组件。

 

集群数据库是存在于内存中的数据库，保存命名空间的全部数据。

更新操做会被记录到硬盘中以便恢复，写操做先被序列化到硬盘中，再应用到内存数据库中。

每一个ZooKeeper服务端为一个或多个客户端服务。客户端链接一个服务端来提交请求。

 

读操做请求由每一个服务端数据库的本地副本提供服务。

 

可以改变服务状态的请求、写操做请求，按协议处理。

做为协议的一部分，来自客户端的全部写操做请求会导向一个服务端，叫作leader。其余服务端叫作follower。

全部follower从leader接收消息建议而且对消息转发达成一致。由消息传送层来处理失败时替换leader，同步follower和leader的工做。

ZooKeeper使用自定义的原子性消息协议。因为消息传送层是原子性的，ZooKeeper可以保证本地副本不产生分歧。

当leader收到一个写请求，它会计算出当写操做完成后系统将会是什么状态，接着将之转变为一个事务。