【转】【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收到一个写请求，它会计算出当写操作完成后系统将会是什么状态，接着将之转变为一个事务。