Zookeeper数据结构

根据本小结第一部分的描述，很显然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子节点个数。

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