[Zookeeper研究]一 Zookeeper技术简介

最近的项目中使用到了Zookeeper、Kafka以及Storm。仔细研究了一下，觉得这几个开源项目对于搞分布式的人来说是非常有用的，所以想把自己的一点心得体会总结一下，希望能对大家有所帮助。

首先从Zookeeper开始。这一节主要是介绍一下Zookeeper的背景和架构

zookeeper是一个开源分布式的服务,它提供了分布式协作,分布式同步,配置管理等功能. 它实现的功能与google的chubby基本一致。

Zookeeper的官方文档对它的设计实现有很详细的描述，下面我们来简单介绍一下。

一. Zookeeper的设计目标：

1. Simple。 ZooKeeper的命名空间组织结构类似文件系统，分布式系统可以基于它进行协作。Zookeeper中的每一个节点都是一个znode，它类似于文件系统中的文件或文件夹。通用的文件系统一般都是设计用来存储数据，而Zookeeper的数据都是保存在memory中的，这也意味这ZooKeeper能够有很高的throughput和很低的延迟。

　　ZooKeeper的实现主要考虑的是高性能、高可用性以及严格的顺序访问。 高性能意味着它可以被用在大型的分布式系统中；高可用性是指使用ZooKeeper集群能够避免单点故障；严格的顺序意味着ZooKeeper的客户端可以实现复杂的同步功能。

　　2. replicated。像很多分布式系统一样，ZooKeeper的数据会被拷贝到一个集群中的多台机器上，这些机器组成一个ZooKeeper集群，如下图所示：



　　组成ZooKeeper集群服务的Server都要获知彼此的存在。它们在内存中保存了当前ZooKeeper服务数据的最新镜像，同时每隔一段时间会持久化保存这些镜像数据以及transaction日志。这些数据可以被用来恢复ZooKeeper服务。只要大部分的ZooKeeper Server都正常，ZooKeeper服务就是可用的。

　　每个客户端都只会连接到一个ZooKeeper Server，客户端维护了一个跟Server的TCP连接，可以通过这个连接来发送请求、获取数据、获取监听事件以及发送心跳信息。如果TCP连接断掉，客户端会尝试连接到其它Server。

　　3. Ordered。ZooKeeper为每一次update都关联一个number，它反映了所有ZooKeeper transactions的顺序。以后的操作可以基于该顺序实现更高层次的抽象，比如分布式同步锁等。

　　4. Fast。ZooKeeper在以读操作为主的场景中尤其快。ZooKeeper应用可以运行在成百上千台机器中，当读写操作比为10：1时它表现的最好。

二. ZooKeeper的数据模型和层次式的命名空间。

　　ZooKeeper提供的命名空间很像一个标准的文件系统，如下图所示，它的名字是一系列由"/"分隔的路径。ZooKeeper命名空间中的每一个节点都由一个路径指定。



三. ZooKeeper节点以及ephemeral节点

　　同文件系统不同的是，每一个ZooKeeper的节点都既可以存储数据也可以含有子节点。普通文件系统中，只有文件夹可以有子文件或子目录，文件只能用来存储数据。所以这里ZooKeeper就好像是文件系统允许一个文件可以有文件夹的功能。ZooKeeper是被设计用来存储一些协作数据的，比如说状态信息、配置信息、位置信息等，所以通常每个节点存储的数据量都是非常小的（范围在byte和kilobyte之间）。我们用术语znode表明我们讨论的是ZooKeeper的数据节点。

　　znode维护了一个stat数据结构，它包含了以下信息：

czxid ：这个znode创建时对应的zxid

mzxid
：这个znode最后一次被修改对应的zxid

ctime
：这个znode被创建的时间，单位是毫秒

mtime
：这个znode最后一次被修改的时间，单位是毫秒

version
：这个znode存储的数据改动的次数，每次加1

cversion
：这个znode的子节点改动的次数（创建或删除），每次加1

aversion
：这个znode的ACL权限的改动次数，每次加1

ephemeralOwner ：如果这个znode是一个ephemeral 节点，存储的是创建该节点的client的session id，否则默认为0

dataLength
：znode中存储的数据的长度

numChildren： znode节点的子节点数目

　　

　　当这个节点的内容或是子节点有改动时，对应的Stat中存储的值会被更新. ZooKeeper的客户端获取该znode的数据时，它也同时会获得这些stat信息。

　　每个命名空间对应的znode节点存储的数据的读和写都是原子操作，也即读的话会获取当前存储的所有数据，写的话会用新数据覆盖旧数据。每个znode都有一个ACL（Access Control List）来限制谁可以对该znode做哪些操作。

　　ephemeral znode是ZooKeeper中的一个重要概念，这是一中特殊的znode，只要创建它的那个session一直存在，这个znode就一直存在，一旦这个session结束了，这个znode就会被删除。这对于分布式系统各个组件之间相互协作是非常有用的，可以通过注册ephemeral 节点来标识当前各个组件的运行状态（live or dead）。

　　

　　ZooKeeper中存在下述的3种类型znode:

Persistent Nodes: 永久有效地节点,除非client显式的删除,否则一直存在

Ephemeral Nodes: 临时节点,仅在创建该节点client保持连接期间有效,一旦连接丢失,zookeeper会自动删除该节点

Sequence Nodes: 顺序节点,client申请创建该节点时,zk会自动在节点路径末尾添加递增序号,这种类型是实现分布式锁,分布式queue等特殊功能的关键

四. ZooKeeper的Watch

ZooKeeper中有Watch的概念， Zookeeper Watch 定义如下:

“A watch event is one-time trigger, sent to the client that set the watch, which occurs when the data for which the watch was set changes.”

　　Watch是由ZooKeeper的client在进行操作时设置的，所有的读操作（getData(), getChildren(), and exists()）都可以选择设置watch。在我看来,watch可以理解为一个分布式的回调,当client关心的znode发生变化时,zookeeper将会把消息传回到client,并导致client的消息处理函数得到调用. 后面我们会详细介绍ZooKeeper的Watch的实现机制。

五. ZooKeeper的保证

　　ZooKeeper非常快并且非常简单，由于它的目标是成为构建复杂系统的基石（比如说同步系统），它提供了一系列的保证，它们是：

1. 顺序的一致性。 一个Client所发送的所有更新的执行顺序跟它们的发送顺序是一致的。

2. 原子性。更新操作要么成功要么失败，不存在部分成功的情况。

3. 单一系统镜像。在一个ZooKeeper集群中，一个Client不论链接到哪个Server上，它看到的ZooKeeper系统的状态/视图应该是相同的。

4. 可靠性。 一旦一个更新操作执行成功，这个更改就会一直存在直到有一个client又对它进行了更改/覆盖。

5. 时效性。在一定的时间限制范围内，确保所有client看到的ZooKeeper系统的数据是最新的。

　　希望看完这一章之后，大家会对ZooKeeper有一个基础的印象，后面的章节会详细介绍ZooKeeper中设计和实现。