在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