zookeeper详解（一） -- 基本结构

1、zookeeper是什么

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop的重要组件，CDH版本中更是使用它进行Namenode的协调控制。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

zookeeper到底能为我们的分布式系统做什么事情呢：

• 管理系统中独特的/统一的信息：

一个分布式系统的各节点可能需要一个规范的、各节点的唯一的命名（例如节点名、CPU编号等），ZK可以实现这个的应用场景。

各个节点也会有一致的信息，例如每个节点的主配置信息。为了管理方便，新加入的节点也需要快速同步这些信息。使用ZK可以方便的做到。

• 集群状态监控和通知：

分布式系统中的每个节点需要知道整个系统的状态、知道系统中每个节点的状态：当有新节点加入时它需要知道、当有节点出现故障时它需要知道、当有节点退出时它需要知道。ZK就是这样一个“通知工具”。

• 协调资源抢占（锁）：

当分布式系统的多个节点试图同时抢占唯一资源时（例如同时写入一个文件），就需要对这个唯一资源的使用进行协调。这是ZK的“协调者”功能。

• 分派计算任务：

如何协调1000个需要同时处理的任务到分布式系统的13个节点？如何保证执行失败的任务能被重新执行？如何在某个节点崩溃的情况下，接管其正在处理的任务？

2 ,Zookeeper的基本概念

(1) 角色

Zookeeper中的角色主要有以下三类，如下表所示：

系统模型如图所示：

(2) 设计目的

1.最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。

2 .可靠性：具有简单、健壮、良好的性能，如果消息m被到一台服务器接受，那么它将被所有的服务器接受。

3 .实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。

4 .等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。

5.原子性：更新只能成功或者失败，没有中间状态。

6 .顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。

3 , 特点

(1)Zookeeper是可重用的

ZooKeeper Service

组成Zookeeper的各个服务器必须要能相互通信。他们在内存中保存了服务器状态，也保存了操作的日志，并且持久化快照。只要大多数的服务器是可用的，那么Zookeeper就是可用的。

客户端连接到一个Zookeeper服务器，并且维持TCP连接。并且发送请求，获取回复，获取事件，并且发送连接信号。如果这个TCP连接断掉了，那么客户端可以连接另外一个服务器。

(2)Zookeeper是有序的

Zookeeper使用数字来对每一个更新进行标记。这样能保证Zookeeper交互的有序。后续的操作可以根据这个顺序实现诸如同步操作这样更高更抽象的服务。

(3)Zookeeper是高效的

Zookeeper的高效更表现在以读为主的系统上。Zookeeper可以在千台服务器组成的读写比例大约为10:1的分布系统上表现优异。

(4)数据结构和分等级的命名空间

Zookeeper的命名空间的结构和文件系统很像。一个名字和文件一样使用/的路径表现，zookeeper的每个节点都是被路径唯一标识

ZooKeeper's Hierarchical Namespace

4、zookeeper的存储结构

zookeeper中的数据是按照“树”结构进行存储的。而且znode节点还分为4中不同的类型。

（1）、znode

根据本小结第一部分的描述，很显然zookeeper集群自身维护了一套数据结构。这个存储结构是一个树形结构，其上的每一个节点，我们称之为“znode”。如下如所示：

• 每一个znode默认能够存储1MB的数据（对于记录状态性质的数据来说，够了）

• 可以使用zkCli命令，登录到zookeeper上，并通过ls、create、delete、sync等命令操作这些znode节点

• znode除了名称、数据以外，还有一套属性：zxid。这套zid与时间戳对应，记录zid不同的状态（后续我们将用到）

那么每个znode结构又是什么样的呢？如下图所示：

此外，znode还有操作权限。如果我们把以上几类属性细化，又可以得到以下属性的细节：

• czxid：创建节点的事务的zxid
• mzxid：对znode最近修改的zxid
• ctime：以距离时间原点(epoch)的毫秒数表示的znode创建时间
• mtime：以距离时间原点(epoch)的毫秒数表示的znode最近修改时间
• version：znode数据的修改次数
• cversion：znode子节点修改次数
• aversion：znode的ACL修改次数
• ephemeralOwner：如果znode是临时节点，则指示节点所有者的会话ID；如果不是临时节点，则为零。
• dataLength：znode数据长度。
• numChildren：znode子节点个数。

(2)、znode中的存在类型

我们知道了zookeeper内部维护了一套数据结构：由znode构成的集合，znode的集合又是一个树形结构。每一个znode又有很多属性进行描述。并且znode的存在性还分为四类，如下如所示：

znode是由客户端创建的，它和创建它的客户端的内在联系，决定了它的存在性：

• PERSISTENT-持久化节点：创建这个节点的客户端在与zookeeper服务的连接断开后，这个节点也不会被删除（除非您使用API强制删除）。

• PERSISTENT_SEQUENTIAL-持久化顺序编号节点：当客户端请求创建这个节点A后，zookeeper会根据parent-znode的zxid状态，为这个A节点编写一个全目录唯一的编号（这个编号只会一直增长）。当客户端与zookeeper服务的连接断开后，这个节点也不会被删除。

• EPHEMERAL-临时目录节点：创建这个节点的客户端在与zookeeper服务的连接断开后，这个节点（还有涉及到的子节点）就会被删除。

• EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点：当客户端请求创建这个节点A后，zookeeper会根据parent-znode的zxid状态，为这个A节点编写一个全目录唯一的编号（这个编号只会一直增长）。当创建这个节点的客户端与zookeeper服务的连接断开后，这个节点被删除。

• 另外，无论是EPHEMERAL还是EPHEMERAL_SEQUENTIAL节点类型，在zookeeper的client异常终止后，节点也会被删除。

图 1 Zookeeper 数据结构

                                                    

Zookeeper 这种数据结构有如下这些特点：

1. 每个子目录项如 NameService 都被称作为 znode，这个 znode 是被它所在的路径唯一标识，如 Server1 这个 znode 的标识为 /NameService/Server1
2. znode 可以有子节点目录，并且每个 znode 可以存储数据，注意 EPHEMERAL 类型的目录节点不能有子节点目录
3. znode 是有版本的，每个 znode 中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据
4. znode 可以是临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个 znode 也将自动删除，Zookeeper 的客户端和服务器通信采用长连接方式，每个客户端和服务器通过心跳来保持连接，这个连接状态称为 session，如果 znode 是临时节点，这个 session 失效，znode 也就删除了
5. znode 的目录名可以自动编号，如 App1 已经存在，再创建的话，将会自动命名为 App2
6. znode 可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是 Zookeeper 的核心特性，Zookeeper 的很多功能都是基于这个特性实现的，后面在典型的应用场景中会有实例介绍

(3)、zk中的选举FastLeaderELection

我们已经知道了一个zookeeper集群中，有一个处于leader身份的节点，其他的节点都是flower状态。那么一个leader是怎么产生的呢？这就是zookeeper中的选举规则，默认的选举规则称为：FastLeaderELection（网上的资料还有提到另外的选举算法，实际上它们的核心思想都是一样的）

3.1、选举算法的中心思想

网上的资料有使用纯文字进行算法描述的，也有使用流程图进行算法描述的，但是如果读者不仔细看，还是容易昏头转向，这里我们使用一张过程图和文字相结合的方式对FastLeaderELection选举算法进行描述。实际上FastLeaderELection说的中心思想无外乎以下几个关键点：

• 全天下我最牛，在我没有发现比我牛的推荐人的情况下，我就一直推举我当leader。第一次投票那必须推举我自己当leader。

• 每当我接收到其它的被推举者，我都要回馈一个信息，表明我还是不是推举我自己。如果被推举者没我大，我就一直推举我当leader，是我是我还是我！

• 我有一个票箱， 和我属于同一轮的投票情况都在这个票箱里面。一人一票 重复的或者过期的票，我都不接受。

• 一旦我不再推举我自己了（这时我发现别人推举的人比我推荐的更牛），我就把我的票箱清空，重新发起一轮投票（这时我的票箱一定有两票了，都是选的我认为最牛的人）。

• 一旦我发现收到的推举信息中投票轮要高于我的投票轮，我也要清空我的票箱。并且还是投当初我觉得最牛的那个人（除非当前的人比我最初的推荐牛，我就顺带更新我的推荐）。

• 不断的重复上面的过程，不断的告诉别人“我的投票是第几轮”、“我推举的人是谁”。直到我的票箱中“我推举的最牛的人”收到了不少于 N /2 + 1的推举投票。

• 这时我就可以决定我是flower还是leader了（如果至始至终都是我最牛，那我就是leader咯，其它情况就是follower咯）。并且不论随后收到谁的投票，都向它直接反馈“我的结果”。

3.2、网上的资料

上图是网络上的一张选举过程图，步骤是怎么样的，笔者我就不再多说了，只希望这个能辅助大家更好的理解选举过程。

哦，现在您知道为什么zookeeper在少于 N + 1 / 2的节点处于工作状态的情况下会崩溃了吧。因为，无论怎么选也没有任何节点能够获得 N + 1 / 2 的票数。