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。