zookeeper核心原理（选举）

hadoop系列：zookeeper（2）——zookeeper核心原理（选举）

2015-08-15 13:13  本站整理  浏览(421)

1、前述

上篇文章《hadoop系列：zookeeper（1）——zookeeper单点和集群安装》（ http://www.lai18.com/content/599370.html）我们介绍了zookeeper的两种安装方式，相信您的测试机或者VM上面已经有了一个可用的zookeeper环境了。本文是zookeeper讲解的第二篇文章，我们主要介绍zk中的重要基本原理。为后文给大家讲解zk的java api使用打下基础。无论您在工作中实际的角色是什么，如果您准备在实际工作中使用zookeeper技术，那么这篇文章介绍的基本原理您都应该了解。

2、zk的数据组织方式

首先我们在您的zk环境上使用zkCli.sh连接上去：

[root@vm2 ~]# zkCli.sh 
Connecting to localhost:2181
2015-08-12 23:43:53,624 [myid:] - INFO  [main:Environment@100] - Client environment:zookeeper.version=3.4.6-1569965, built on 02/20/2014 09:09 GMT
2015-08-12 23:43:53,639 [myid:] - INFO  [main:Environment@100] - Client environment:host.name=vm2
2015-08-12 23:43:53,639 [myid:] - INFO  [main:Environment@100] - Client environment:java.version=1.7.0_71
2015-08-12 23:43:53,642 [myid:] - INFO  [main:Environment@100] - Client environment:java.vendor=Oracle Corporation
。。。。。。
。。。。。。
。。。。。。
。。。。。。
[zk: localhost:2181(CONNECTED) 0]

然后我们使用ls命令，查看zookeeper服务器上的数据存储信息：

[zk: localhost:2181(CONNECTED) 1] ls /
[filesq, zookeeper]

当然您还可以使用很多命令，如下：

connect host:port
get path [watch]
ls path [watch]
set path data [version]
rmr path
delquota [-n|-b] path
quit 
printwatches on|off
create [-s] [-e] path data acl
stat path [watch]
close 
ls2 path [watch]
history 
listquota path
setAcl path acl
getAcl path
sync path
redo cmdno
addauth scheme auth
delete path [version]
setquota -n|-b val path

如果您对以上命令感兴趣，可以查询zookeeper的官方文档去了解。本文的内容我们将从ls命令得到的zookeeper中的数据结构讲开。

2.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.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异常终止后，节点也会被删除。

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节点时本身的时间差，我们假设发出包的先后顺序，就是目标节点接受这些包的先后顺序。这个理想的过程中，我们同时开启5个zookeeper节点，让他们进行选举：



在第一轮中，按照“我最牛逼，我怕谁”的原则，每个节点都推荐它自己为集群的leader节点。

按照我们假设的理想条件，节点S1首先收到了S2发送来的推荐者“2”，节点S1发现“2”要比它之前推荐的“1”（也就是它自己）牛。根据谁牛推荐谁的原则，“S1”清空自己的票箱，重新选举“2”（注意，此时“S1”的新票箱中已经有两票选举“2”了，一票是它自己，另外一票是”S2”，并且所有节点都是Looking状态）

同样的事情发生在“S2”身上：”S2”收到了”S3”发过来的推荐信息，发现“3”这个被推举者比之前自己推举的“2”要牛，于是也清空自己的票箱，发起一轮新的投票，此时“S2”选举“3”。依次类推”S3”、”S4”。

这里要注意S5这个节点，在第一轮接受到了来源于“S1”——“S4”的推举者（一定注意，每一次接受信息，都会广播一次“我坚持推举的人”），发现“还是推荐的5最牛”，于是“我继续推举S5吧”。

以上这个过程在整个理想的网络环境上一直持续。到了第四轮，“S1”收到了“S2”发送来的推举者“5”，发现“5”要比当前“S1”推荐的“4”要牛。 所以“S1”清空了自己的票箱，重新推举“5”（发送给其他所有节点）。

关键的第五轮来了，我们再重复一下，经过之前的选举，现在“S2”——“S5”都已经推举“5”为Leader了，而且都处于第四轮。这时他们收到了”S1”发来的新的“第五轮”投票，于是都和之前一样，做相同的一件事：清空自己的票箱，重新向其他所有节点广播自己的第五轮投票“5”。

于是，节点X，收到了大于N + 1 / 2的选举“5”的投票，且都是第五轮投票。这样每个节点就都知道了自己的角色。，选举结束。 所有将成为Follower状态的节点，向将要成为Leader的节点发起最后一次“工作是否正常”的询问。得到肯定的ack后，整个集群的工作状态就确认了。

3.3、实际上没有那么理想

关于上节的算法或者关于上上节的白话描述，如果您一边没有看懂，请多看几遍，如果您看晕了，请休息一下，清空脑袋，再看。 选举算法的整个流程第一次是不好理解，但是一旦理解了其中的关键点，它就变得很简单。

我们在上文中介绍的选举流程是基于一个基本的考虑：理想的网络环节，理想的节点处理能力。但事实上，没有这样的环境，网络情况的多变导致了我们需要让选举算法兼容各种的情况。

下面我们假设在选举的过程中，“S1”,“S2”两个节点出现了宕机的情况（或者是网络延迟，或者是网络物理层断开，不管您怎么想吧，反正其它节点再也收到”S1”，”S2”的投票信息了）。如下图所示：



上图所示，在第三轮的选举过程后，“S1”,“S2”两个节点就断开了，他们的投票信息根本没有发送出去。

这样一来，“S3”收到了“S4”,“S5”发来的投票信息，这时“S3”的票箱处于第3轮，并且发现了占大多数的投票结果：大家选举“S5”为Leader节点。

同样的事情也发生在“S4”身上。这样“S3”,“S4”两个节点率先知道了投票结果，在最后一次询问Leader节点是否能正常工作，并得到了肯定的ACK之后，“S3”,“S4”两个节点变成了Follower状态。

之后，无论“S3”,“S4”两个节点收到了任何节点的投票信息，都直接向源节点反馈投票结果，不会再进行投票了。

这样一来，在投票完成后，“S1”,“S2”重新连入后，虽然他们发起了投票，但是不会再收到投票反馈了。直接根据“S3”或者“S4”发来的结果状态，变成Follower状态。

3.4、网上的资料

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

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

4、后文介绍

本来，我是希望这篇文章向大家说明包括zookeeper选举原理和zookeeper中的事件监听watcher原理在内的两个核心原理。奈何，内容量已经超出了我的想象，这样的话同时介绍两种原理不利于大家对知识点的吸收消化。所以我决定zookeeper事件监听的watcher原理，在下一篇文章中再详细介绍，当然会包括示例代码。

转自：点击打开链接

hadoop系列：zookeeper（2）——zookeeper核心原理（选举）

2015-08-15 13:13  本站整理  浏览(421)

1、前述

上篇文章《hadoop系列：zookeeper（1）——zookeeper单点和集群安装》（ http://www.lai18.com/content/599370.html）我们介绍了zookeeper的两种安装方式，相信您的测试机或者VM上面已经有了一个可用的zookeeper环境了。本文是zookeeper讲解的第二篇文章，我们主要介绍zk中的重要基本原理。为后文给大家讲解zk的java api使用打下基础。无论您在工作中实际的角色是什么，如果您准备在实际工作中使用zookeeper技术，那么这篇文章介绍的基本原理您都应该了解。

2、zk的数据组织方式

首先我们在您的zk环境上使用zkCli.sh连接上去：

[root@vm2 ~]# zkCli.sh 
Connecting to localhost:2181
2015-08-12 23:43:53,624 [myid:] - INFO  [main:Environment@100] - Client environment:zookeeper.version=3.4.6-1569965, built on 02/20/2014 09:09 GMT
2015-08-12 23:43:53,639 [myid:] - INFO  [main:Environment@100] - Client environment:host.name=vm2
2015-08-12 23:43:53,639 [myid:] - INFO  [main:Environment@100] - Client environment:java.version=1.7.0_71
2015-08-12 23:43:53,642 [myid:] - INFO  [main:Environment@100] - Client environment:java.vendor=Oracle Corporation
。。。。。。
。。。。。。
。。。。。。
。。。。。。
[zk: localhost:2181(CONNECTED) 0]

然后我们使用ls命令，查看zookeeper服务器上的数据存储信息：

[zk: localhost:2181(CONNECTED) 1] ls /
[filesq, zookeeper]

当然您还可以使用很多命令，如下：

connect host:port
get path [watch]
ls path [watch]
set path data [version]
rmr path
delquota [-n|-b] path
quit 
printwatches on|off
create [-s] [-e] path data acl
stat path [watch]
close 
ls2 path [watch]
history 
listquota path
setAcl path acl
getAcl path
sync path
redo cmdno
addauth scheme auth
delete path [version]
setquota -n|-b val path

如果您对以上命令感兴趣，可以查询zookeeper的官方文档去了解。本文的内容我们将从ls命令得到的zookeeper中的数据结构讲开。

2.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.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异常终止后，节点也会被删除。

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节点时本身的时间差，我们假设发出包的先后顺序，就是目标节点接受这些包的先后顺序。这个理想的过程中，我们同时开启5个zookeeper节点，让他们进行选举：



在第一轮中，按照“我最牛逼，我怕谁”的原则，每个节点都推荐它自己为集群的leader节点。

按照我们假设的理想条件，节点S1首先收到了S2发送来的推荐者“2”，节点S1发现“2”要比它之前推荐的“1”（也就是它自己）牛。根据谁牛推荐谁的原则，“S1”清空自己的票箱，重新选举“2”（注意，此时“S1”的新票箱中已经有两票选举“2”了，一票是它自己，另外一票是”S2”，并且所有节点都是Looking状态）

同样的事情发生在“S2”身上：”S2”收到了”S3”发过来的推荐信息，发现“3”这个被推举者比之前自己推举的“2”要牛，于是也清空自己的票箱，发起一轮新的投票，此时“S2”选举“3”。依次类推”S3”、”S4”。

这里要注意S5这个节点，在第一轮接受到了来源于“S1”——“S4”的推举者（一定注意，每一次接受信息，都会广播一次“我坚持推举的人”），发现“还是推荐的5最牛”，于是“我继续推举S5吧”。

以上这个过程在整个理想的网络环境上一直持续。到了第四轮，“S1”收到了“S2”发送来的推举者“5”，发现“5”要比当前“S1”推荐的“4”要牛。 所以“S1”清空了自己的票箱，重新推举“5”（发送给其他所有节点）。

关键的第五轮来了，我们再重复一下，经过之前的选举，现在“S2”——“S5”都已经推举“5”为Leader了，而且都处于第四轮。这时他们收到了”S1”发来的新的“第五轮”投票，于是都和之前一样，做相同的一件事：清空自己的票箱，重新向其他所有节点广播自己的第五轮投票“5”。

于是，节点X，收到了大于N + 1 / 2的选举“5”的投票，且都是第五轮投票。这样每个节点就都知道了自己的角色。，选举结束。 所有将成为Follower状态的节点，向将要成为Leader的节点发起最后一次“工作是否正常”的询问。得到肯定的ack后，整个集群的工作状态就确认了。

3.3、实际上没有那么理想

关于上节的算法或者关于上上节的白话描述，如果您一边没有看懂，请多看几遍，如果您看晕了，请休息一下，清空脑袋，再看。 选举算法的整个流程第一次是不好理解，但是一旦理解了其中的关键点，它就变得很简单。

我们在上文中介绍的选举流程是基于一个基本的考虑：理想的网络环节，理想的节点处理能力。但事实上，没有这样的环境，网络情况的多变导致了我们需要让选举算法兼容各种的情况。

下面我们假设在选举的过程中，“S1”,“S2”两个节点出现了宕机的情况（或者是网络延迟，或者是网络物理层断开，不管您怎么想吧，反正其它节点再也收到”S1”，”S2”的投票信息了）。如下图所示：



上图所示，在第三轮的选举过程后，“S1”,“S2”两个节点就断开了，他们的投票信息根本没有发送出去。

这样一来，“S3”收到了“S4”,“S5”发来的投票信息，这时“S3”的票箱处于第3轮，并且发现了占大多数的投票结果：大家选举“S5”为Leader节点。

同样的事情也发生在“S4”身上。这样“S3”,“S4”两个节点率先知道了投票结果，在最后一次询问Leader节点是否能正常工作，并得到了肯定的ACK之后，“S3”,“S4”两个节点变成了Follower状态。

之后，无论“S3”,“S4”两个节点收到了任何节点的投票信息，都直接向源节点反馈投票结果，不会再进行投票了。

这样一来，在投票完成后，“S1”,“S2”重新连入后，虽然他们发起了投票，但是不会再收到投票反馈了。直接根据“S3”或者“S4”发来的结果状态，变成Follower状态。

3.4、网上的资料

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

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

4、后文介绍

本来，我是希望这篇文章向大家说明包括zookeeper选举原理和zookeeper中的事件监听watcher原理在内的两个核心原理。奈何，内容量已经超出了我的想象，这样的话同时介绍两种原理不利于大家对知识点的吸收消化。所以我决定zookeeper事件监听的watcher原理，在下一篇文章中再详细介绍，当然会包括示例代码。