1、前述
上篇文章《hadoop系列：zookeeper（1）——zookeeper单点和集群安装》（）我们介绍了zookeeper的两种安装方式，相信您的测试机或者VM上面已经有了一个可用的zookeeper环境了。本文是zookeeper讲解的第二篇文章，我们主要介绍zk中的重要基本原理。为后文给大家讲解zk的java api使用打下基础。无论您在工作中实际的角色是什么，如果您准备在实际工作中使用zookeeper技术，那么这篇文章介绍的基本原理您都应该了解。
2、zk的数据组织方式
首先我们在您的zk环境上使用zkCli.sh连接上去：
[root@vm2 ~]# zkCli.sh Connecting to localhost:21812015-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 GMT2015-08-12 23:43:53,639 [myid:] – INFO [main:Environment@100] – Client environment:host.name=vm22015-08-12 23:43:53,639 [myid:] – INFO [main:Environment@100] – Client environment:java.version=1.7.0_712015-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:portget path [watch]ls path [watch]set path data [version]rmr pathdelquota [-n|-b] pathquit printwatches on|offcreate [-s] [-e] path data aclstat path [watch]close ls2 path [watch]history listquota pathsetAcl path aclgetAcl pathsync pathredo cmdnoaddauth scheme authdelete path [version]setquota -n|-b val path
如果您对以上命令感兴趣，可以查询zookeeper的官方文档去了解。本文的内容我们将从ls命令得到的zookeeper中的数据结构讲开。
2.1、znode
根据本小结第一部分的描述，很显然zookeeper集群自身维护了一套数据结构。这个存储结构是一个树形结构，其上的每一个节点，我们称之为“znode”。如下如所示：
那么每个znode结构又是什么样的呢？如下图所示：
此外，，znode还有操作权限。如果我们把以上几类属性细化，又可以得到以下属性的细节：
2.2、znode中的存在类型
我们知道了zookeeper内部维护了一套数据结构：由znode构成的集合，znode的集合又是一个树形结构。每一个znode又有很多属性进行描述。并且znode的存在性还分为四类，如下如所示：
znode是由客户端创建的，它和创建它的客户端的内在联系，决定了它的存在性：
3、zk中的选举FastLeaderELection
在上篇文章中，我们已经知道了一个zookeeper集群中，有一个处于leader身份的节点，其他的节点都是flower状态。那么一个leader是怎么产生的呢？这就是zookeeper中的选举规则，默认的选举规则称为：FastLeaderELection（网上的资料还有提到另外的选举算法，实际上它们的核心思想都是一样的）
3.1、选举算法的中心思想
网上的资料有使用纯文字进行算法描述的，也有使用流程图进行算法描述的，但是如果读者不仔细看，还是容易昏头转向，这里我们使用一张过程图和文字相结合的方式对FastLeaderELection选举算法进行描述。实际上FastLeaderELection说的中心思想无外乎以下几个关键点：
3.2、一张理想的图
那么我们按照以上的原则，进行一次投票。这是一个比较理想的状态，我们不考虑其中的网络延迟，不考虑启动zookeeper节点时本身的时间差，我们假设发出包的先后顺序，就是目标节点接受这些包的先后顺序。这个理想的过程中，我们同时开启5个zookeeper节点，让他们进行选举：
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、后文介绍要铭记在心;每天都是一年中最美好的日子
