Zookeeper数据模型：

Zookeeper的结构类似标准的文件系统，但这个文件系统中没有文件和目录，而是统一使用节点(node)的概念，称为znode。Znode作为保存数据的容器(限制在1mb以内)，也构成了一个层次化的命名空间。

 

znode

zookeeper目录中的每一个节点对应着一个znode，每个znode维护着一个属性结构，它包含数据的版本号、时间戳、等信息。Zookeeper就是通过这些属性来实现它特定的功能。每当znode的数据改变时，相应的版本号会增加，每当客户端查询、更新和删除数据时，也必须提供要被操作的znode版本号，如果所提供的数据版本号与实际的不匹配，那么将会操作失败。

节点属性：

属性	描述
czxid	节点被创建的zxid值
mzxid	节点被修改时zxid值
ctime	节点创建的时间
mtime	节点最后一次的修改时间
vesion	节点的版本号
cversion	节点所拥有的子节点被修改的版本号
aversion	节点的ACL被修改的版本号
dataLength	节点数据的长度
numChildren	节点拥有子节点的个数
ephemeralOwner	如果节点为临时节点，那么它的值为这个节点拥有者的session ID；负责它的值为0

Znode是客户端访问的zookeeper的主要实体，它包含了以下主要特征：

(1)  Watch

Znode状态发生改变时(增删改等操作)，watch (监视器)机制可以让客户端得到通知，并且仅仅只会触发一次watch。

在读操作exists、getChildren和getData上可以设置监视器，这些监视器可以被写操作create、delete和setData触发。ACL相关的操作不参与任何监视器。当一监视器触发时，会产生一个事件，这个监视器和触发它的操作共同绝地沟了监视器事件类型。

*  当所监视的znode被创建子节点、删除或其他数据更新时，设置在exists操作上的监视器将会被触发。

*  当所监视的znode被删除或其更新时，设置在getData上的监视器将会被触发，创建znode不会触发getData上的监视器，因为getData操作成功执行的前提是znode必须已经在。

*  当所监视的znode的一个子节点被创建或删除时，或监视的znode自己被删时，设置在getChildren操作上的监视器将会被触发。

设置监视器的操作及对应的触发器

设置触发 器的操作	触发触发器的操作/受影响的节点
	create		delete		setData
	znode	子节点	znode	子节点
Exists	NodeCreated		NodeDeleted		NodeDataChanged
getData			NodeDeleted		NodeDataChanged
getChildren			NodeDeleted	NodeDeleted

(2)  数据访问控制

每个znode创建时间都会有一个ACL列表，用于决定谁可以执行那些操作。

(3)  临时节点

Zookeeper节点有两种：临时节点和持久节点。节点类型在创建时确定，并且不能修改。临时节点生命周期依赖创建它的会话，一旦会话结束，临时节点将会被删除。临时节点不允许有子节点。

(4)  顺序节点

当创建znode 时设置了顺序节点，那么该znode路径之后便会附加一个递增的计数，这个计数对于此节点的父节点来说是唯一的。

例如：一个客户端请求创建一个名为/a/b-的顺序节点，则所创建znode的名字可能是a/b-5，稍后另外一个名为/a/b-的顺序节点被创建，计数器会给出一个更大的值来保证znode名称的唯一性，例如/a/b-6。