Zookeeper教程-1 数据模型

Zookeeper的数据模型

在结构上和标准文件系统非常相似，拥有一个层次的命名空间，都是采用树形层次结构，ZooKeeper树中的每个节点都可以拥有子节点。但也有不同之处：

1. Znode兼具文件和目录两种特点。既像文件一样维护着数据、元信息、ACL、时间戳等数据结构，又像目录一样可以作为路径标识的一部分，并可以具有子Znode。用户对Znode具有增、删、改、查等操作（权限允许的情况下）
2. Znode具有原子性。读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据。另外，每一个节点都拥有自己的ACL(访问控制列表)，这个列表规定了用户的权限，即限定了特定用户对目标节点可以执行的操作。
3. Znode存储数据大小有限制。Zookeeper虽然可以关联一些数据，但并没有被设计为常规的数据库或者大数据存储，相反的是，它用来管理调度数据，比如分布式应用中的配置文件信息、状态信息、汇集位置等等。这些数据的共同特性就是它们都是很小的数据，通常以KB为大小单位。Zookeeper的服务器和客户端都被设计为严格检查并限制每个Znode的数据大小至多为1M，当时常规使用中应该远小于此值。
4. Znode通过路径引用，如同Unix中的文件路径。路径必须是绝对的，因此他们必须由斜杠字符来开头。除此以外，他们必须是唯一的，也就是说每一个路径只有一个表示，因此这些路径不能改变。在Zookeeper中，路径由Unicode字符串组成，并且有一些限制。字符串“/zookeeper"用以保存管理信息，比如关键配额信息。

图中的每个节点称为一个Znode。每个Znode由3部分组成：

1. stat：此为状态信息，描述该Znode的版本，权限等信息
2. data：与该Znode关联的数据
3. children：该Znode下的子节点

Zookeeper的节点类型

Znode有两种，分别为临时节点和永久节点。
节点的类型在创建时即被确定，并且不能改变。
临时节点：该节点的生命周期依赖于创建它们的会话。一旦会话结束，临时节点将被自动删除，当然也可以手动删除。临时节点不允许拥有子节点。
永久节点：该节点的生命周期不依赖于会话，并且只有在客户端显式执行删除操作的时候，他们才能被删除。
Znode还有一个序列化特性，如果创建的时候指定的话，该Znode的名字后面会自动追加一个不断增加的序列号。序列号对于此节点的父节点来说是唯一的，这样便会记录每个子节点创建的先后顺序。它的格式为”%10d"（10位数字，没有数值的位数用0补充，例如“0000000001”）

这样便会存在四种类型的Znode节点，分别对应：

• PERSISTENT：永久节点
• EPHEMERAL：临时节点
• PERSISTENT_SEQUENTIAL：永久节点、序列化
• EPHEMERAL_SEQUENTIAL：临时节点、序列化

Zookeeper的节点属性

每个Znode都包含了一系列的属性，通过命令get，可以获得节点的属性
dataVersion：数据版本号，每次对节点进行set操作，dataVersion的值都会增加1（即使设置的是相同的数据），可有效避免数据更新时出现的先后顺序问题
cversion：子节点的版本号。当znode的子节点有变化时，cversion的值就会增加1
aclVersion：ACL的版本号
cZxid：Znode创建的事务id
mZxid：Znode被修改的事务id，即每次对Znode的修改都会更新mZxid
对于zk来说，每次的变化都会产生一个唯一的事务id，zxid（Zookeeper Transaction Id）。通过zxid，可以确定更新操作的先后顺序。例如，如果zxid1小于zxid2，说明zxid1操作先于zxid2发生，zxid对于整个zk都是唯一的，即使操作的是不同的znode
ctime：节点创建的时间戳
mtime：节点最新一次更新发生时的时间戳
ephemeralOwner：如果该节点为临时节点，ephemeralOwner值表示与该节点绑定的session id。如果不是，ephemeralOwner值为0.
在client和server通信之前，首先需要建立连接，该连接成为session。连接建立后，如果发生连接超时、授权失败，或者显示关闭连接，连接便处于CLOSED状态，此时session结束。

Zookeeper视频教程