高可靠分布式协调框架--Zookeeper

介绍

Zookeeper 是一个维护配置信息、服务名称、分布同步和集群服务的集中服务。我们以前在分布式应用中使用这些服务时，每次在实际实现中，不可避免的要花费大量时间来修复bug、配置竞选条件。因为他们的管理复杂性、脆弱性使我们最初实现让我们焦头烂额，即使你全部都搞定了，你又要面对不同的服务复杂的部署。

Apache Zookeeper 是hadoop的一个子项目,致力于高可靠的分布式协调的开源框架。提供的功能包括：配置维护、名字服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

了解更多信息，请参见Zookeeper Wiki。

设计目标

易用性 ZooKeeper 可以允许分布式进程通过一个共享的协调等级命名空间组织类似于一个标准的文件系统，命名空间由数据寄存器（znodes）组成， Zookeeper中，这类似于文件和文件目录。与一个典型的用于存储在物理空间的文件系统相比，Zookeeper的数据存储在内存中，这意味着Zookeeper可以实现高吞吐量和低延迟。

Zookeepper注重高性能、高可用性、严格有序的访问，Zookeeper的高性能意味着它可以用于大型分布式系统，高可用性的它能够避免大型分布式系统中的单点故障，严格有序的特点使得客户端可以实现复杂的同步逻辑。

副本机制 像分布式进程协作一样，Zookeeper 的服务可以由多台主机提供副本，称作ensemble。

组成Zookeeper的服务节点之间必须可以相互通信，他们共同维护着一个内存的状态，还有事务日志以及数据持久化的快照。只要大部分服务可用，Zookeeper就可用，所以最好部署奇数个节点。

客户端连接一个节点，它通过建立一个TCP连接来发送请求(request)，获取相应（response），得到事件通知和发送心跳信息。如果连接断开，客户端会连接到另一个节点上。

有序的 用数字标记每一次更新，来保证事务的顺序，后续操作可以通过这个有序性来实现更高要求的需求，比如同步操作。

快速的 尤其是在“只读”的工作负载上，Zookeeper可以在上千台机器上运行，用10：1的比例来配置读写会更高效。

数据模型和分层命名空间(The hierarchical namespace)

ZooKeeper的命名空间非常像一个标准文件系统。每个名称都是用“/”分隔的一系列路径。每个znode都被用一个路径标识。

节点和临时节点 (Ephemeral nodes)

与标准文件系统不同，每个命名空间中的节点能够有对应的数据，也可以有子集。就想文件系统中，可以是一个文件，也可以是一个目录。（Zookeeper被设计用来协调存储数据：状态信息、配置信息、位置信息等，所以存储在每个节点的数据通常都很小，几个字节到几千个字节之间）我们使用znode组件使我们描述Zookeeper数据节点更加清晰明确。

Znode管理的数据结构包包含数据修改、ACL修改、时间戳的版本号，为了保证协调和校验缓存的更新。znode的数据每改变一次，版本号增加一次。例如：每当客户端接收数据，同事接收到当前数据的版本。

存储在每个znode的命名空间中的数据可以自动读取和写入。读取所znode对应的所有数据自己和写入替换所有数据。每个节点都有一个访问控制列表(ACL)来限制谁可以做什么。

Zookeeper也有临时节点的概念，临时节点只有在会话（Session）处于活跃状态时被创建，当会话结束临时节点被删除。

监视器(Watches)

Zookeeper支持监视器(watch)概念，客户端能够在一个znodes节点配置一个监视器（watch），当一个znode改变监视器（watch）被触发并且被移除。当监视器被触发时，客户端会收到一个描述了 znode 的变更的数据包。如果客户端和Zookeeper服务器之间的连接断开时，客户端将会收到一个本地通知。

保证（Guarantees）

Zookeeper 很高效并且很简单，然而，为了构建更复杂的服务，比如同步，它有如下要求：

顺序(Sequential Consistency)：致性-来自客户端的更新将按照他们的发送顺序被应用

原子性(Atomicity)：要么更新成功，要么更新失败，不会存在部分成功或失败的接口

单一系统镜像（Single System Image）：客户端无论连接到那个服务器上，看到的都是相同的视图。

可靠性(Reliability)：一次更新将会持续到下一次更新被覆盖

及时性(Timeless)：保证客户端在一段时间内看到的系统视图总是最新的。

简单的API（Simple API）

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

create ：在树的指定位置创建一个节点。

delete ： 删除一个节点。

exists ： 检测在一个地址上是否存在节点。

get data ： 从节点读取数据。

set data ：将数据写入节点。

get children ：检索子节点列表。

sync ： 等待数据传播完成。

实现（Implementation）

Zookeeper 组件图展示了 Zookeeper 服务的高层组件。除了“Request Processor”，构成 Zookeeper 服务的所有服务器都会复制一份这些组件的拷贝。

拷贝数据库(Replicated Database)是一个内存型数据库，包含了整个数据树。所有更改都会记录到磁盘中以便回复。数据写入到内存数据库之前，会先序列化到磁盘

性能（Performance）

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

可靠性

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

资源

Zookeeper可以在单机运行也可以在很小的集群上运行。

快速上手：Zookeeper 安装运行向导

开发文档：

API Docs - Zookeeper 客户端API技术文档

应用向导 - 开发人员的ZooKeeper客户端应用向导

ZooKeeper Java Demo-JAVA示例程序

管理和运维

管理 - 管理和部署Zookeeper向导

JMX - JMX集成

监控 - 方便提高Zookeeper的可伸缩性

动态配置-动态重新配置Zookeeper

下载

更多