在ZooKeeper中,节点也称为znode。由于对于程序员来说,对zk的操作主要是对znode的操作,因此,有必要对znode进行深入的了解。 
ZooKeeper采用了类似文件系统的的数据模型,其节点构成了一个具有层级关系的树状结构。例如,图1展示了zk节点的层级树状结构。

这里写图片描述 
图1:ZooKeeper的层级树状结构

图1中,根节点 / 包含了两个字节点 /module1,/module2,而节点 /module1 又包含了三个字节点 /module1/app1,/module1/app2,/module1/app3。在zk中,节点以绝对路径表示,不存在相对路径,且路径最后不能以 / 结尾(根节点除外)。

类型

根据节点的存活时间,可以对节点划分为持久节点和临时节点。节点的类型在创建时就被确定下来,并且不能改变。 
持久节点的存活时间不依赖于客户端会话,只有客户端在显式执行删除节点操作时,节点才消失。 
临时节点的存活时间依赖于客户端会话,当会话结束,临时节点将会被自动删除(当然也可以手动删除临时节点)。利用临时节点的这一特性,我们可以使用临时节点来进行集群管理,包括发现服务的上下线等。 
ZooKeeper规定,临时节点不能拥有子节点。

持久节点

使用命令create可以创建一个持久节点。

create /module1 module1

这样,便创建了一个持久节点/module1,且其数据为”module1”。

临时节点

使用create命令,并加上-e参数,可以创建一个临时节点。

create -e /module1/app1 app1

这样,便创建了一个临时节点 /module1/app1,数据为”app1”。关闭会话,然后输入命令:

get /module1/app1

可以看到有以下提示,说明临时节点已经被删除。

Node does not exist: /module1/app1

顺序节点

ZooKeeper中还提供了一种顺序节点的节点类型。每次创建顺序节点时,zk都会在路径后面自动添加上10位的数字(计数器),例如 < path >0000000001,< path >0000000002,……这个计数器可以保证在同一个父节点下是唯一的。在zk内部使用了4个字节的有符号整形来表示这个计数器,也就是说当计数器的大小超过2147483647时,将会发生溢出。 
顺序节点为节点的一种特性,也就是,持久节点和临时节点都可以设置为顺序节点。这样一来,znode一共有4种类型:持久的、临时的,持久顺序的,临时顺序的。

使用命令create加上-s参数,可以创建顺序节点,例如,

create -s /module1/app app

输出:

Created /module1/app0000000001

便创建了一个持久顺序节点 /module1/app0000000001。如果再执行此命令,则会生成节点 /module1/app0000000002。 
如果在create -s再添加-e参数,则可以创建一个临时顺序节点。

节点的数据

在创建节点时,可以指定节点中存储的数据。ZooKeeper保证读和写都是原子操作,且每次读写操作都是对数据的完整读取或完整写入,并不提供对数据进行部分读取或者写入的操作。 
以下命令创建一个节点/module1/app2,且其存储的数据为app2。

create /module1/app2 app2

ZooKeeper虽然提供了在节点存储数据的功能,但它并不将自己定位为一个通用的数据库,也就是说,你不应该在节点存储过多的数据。Zk规定节点的数据大小不能超过1M,但实际上我们在znode的数据量应该尽可能小,因为数据过大会导致zk的性能明显下降。如果确实需要存储大量的数据,一般解决方法是在另外的分布式数据库(例如Redis)中保存这部分数据,然后在znode中我们只保留这个数据库中保存位置的索引即可。

节点的属性

每个znode都包含了一系列的属性,通过命令get,我们可以获得节点的属性。

get /module1/app2 
app2 
cZxid = 0x20000000e 
ctime = Thu Jun 30 20:41:55 HKT 2016 
mZxid = 0x20000000e 
mtime = Thu Jun 30 20:41:55 HKT 2016 
pZxid = 0x20000000e 
cversion = 0 
dataVersion = 0 
aclVersion = 0 
ephemeralOwner = 0x0 
dataLength = 4 
numChildren = 0

版本号

对于每个znode来说,均存在三个版本号:

  • dataVersion 
    数据版本号,每次对节点进行set操作,dataVersion的值都会增加1(即使设置的是相同的数据)。
  • cversion 
    子节点的版本号。当znode的子节点有变化时,cversion 的值就会增加1。
  • aclVersion 
    ACL的版本号,关于znode的ACL(Access Control List,访问控制),可以参考 参考资料1 有关ACL的描述。

以数据版本号来说明zk中版本号的作用。每一个znode都有一个数据版本号,它随着每次数据变化而自增。ZooKeeper提供的一些API例如setData和delete根据版本号有条件地执行。多个客户端对同一个znode进行操作时,版本号的使用就会显得尤为重要。例如,假设客户端C1对znode /config写入一些配置信息,如果另一个客户端C2同时更新了这个znode,此时C1的版本号已经过期,C1调用setData一定不会成功。这正是版本机制有效避免了数据更新时出现的先后顺序问题。在这个例子中,C1在写入数据时使用的版本号无法匹配,使得操作失败。图2描述了这个情况。

这里写图片描述

图2:使用版本号来阻止并行操作的不一致性

事务ID

对于zk来说,每次的变化都会产生一个唯一的事务id,zxid(ZooKeeper Transaction Id)。通过zxid,可以确定更新操作的先后顺序。例如,如果zxid1小于zxid2,说明zxid1操作先于zxid2发生。 
需要指出的是,zxid对于整个zk都是唯一的,即使操作的是不同的znode。

  • cZxid 
    Znode创建的事务id。

  • mZxid 
    Znode被修改的事务id,即每次对znode的修改都会更新mZxid。

这里写图片描述 
图3:Zxid在客户端重连中的作用

在集群模式下,客户端有多个服务器可以连接,当尝试连接到一个不同的服务器时,这个服务器的状态要与最后连接的服务器的状态要保持一致。Zk正是使用zxid来标识这个状态,图3描述了客户端在重连情况下zxid的作用。当客户端因超时与S1断开连接后,客户端开始尝试连接S2,但S2延迟于客户端所识别的状态。然而,S3的状态与客户端所识别的状态一致,所以客户端可以安全连接上S3。

时间戳

包括znode的创建时间和修改时间,创建时间是znode创建时的时间,创建后就不会改变;修改时间在每次更新znode时都会发生变化。

以下命令创建了一个 /module2 节点。

create /module2 module2 
Created /module2

通过 get 命令,可以看到 /module2的 ctime和mtime均为Sat Jul 02 11:18:32 CST 2016。

get /module2 
module2 
cZxid = 0x2 
ctime = Sat Jul 02 11:18:32 CST 2016 
mZxid = 0x2 
mtime = Sat Jul 02 11:18:32 CST 2016 
pZxid = 0x2 
cversion = 0 
dataVersion = 0 
aclVersion = 0 
ephemeralOwner = 0x0 
dataLength = 7 
numChildren = 0

修改 /module2,可以看到 ctime 没有发生变化,mtime已更新为最新的时间。

set /module2 module2_1 
cZxid = 0x2 
ctime = Sat Jul 02 11:18:32 CST 2016 
mZxid = 0x3 
mtime = Sat Jul 02 11:18:50 CST 2016 
pZxid = 0x2 
cversion = 0 
dataVersion = 1 
aclVersion = 0 
ephemeralOwner = 0x0 
dataLength = 9 
numChildren = 0

参考资料

  1. http://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#ch_zkDataModel
  2. http://java.globinch.com/enterprise-services/zookeeper/apache-zookeeper-explained-tutorial-cases-zookeeper-java-api-examples/#
  3. 《ZooKeeper分布式过程协同技术详解》,Flavio Junqueira等著,谢超等译