（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 的票数。