前面提过,Zookeeper相当于文件系统+通知机制。既然是文件系统,那就涉及数据模型。
ZooKeeper 的数据模型在结构上和Unix标准文件系统非常相似,都是采用树形层次结构,ZooKeeper 树中的每个节点被称为 Znode。
和文件系统的目录树一样,ZooKeeper 树中的每个节点可以拥有子节点。但和标准文件系统也有不同之处,体现在:
引用方式:Znode 通过路径引用,如同 Linux 中的文件路径,但路径必须由斜杠字符来开头
Znode 结构:每个 Znode 由 3 部分组成:
Znode 大小:ZooKeeper 虽然可以关联一些数据,但并没有被设计为常规的数据库或者大数据存储,相反,它被用来管理调度数据,比如分布式应用中的配置文件信息、状态信息、汇集位置等等。这些数据的共同特性就是它们都很小,通常以 KB 为单位。ZooKeeper 的服务器和客户端都被设计为严格检查并限制每个 Znode 的数据大小至多 1M, 但实际使用中要远小于此值
数据访问:ZooKeeper 中的每个节点存储的数据要被原子性的操作,也就是说读操作将获取与节点相关的所有数据,写操作将替换掉节点的所有数据。另外,每一个节点都拥有自己的 ACL(访问控制列表),这个列表规定了用户的权限,即限定了特定用户对目标节点可以执行的操作
节点类型:ZooKeeper 中的节点有两种,分别为临时节点和永久节点。节点的类型在创建时即被确定,并且不能改变。
监视器:客户端可以在节点上设置 watch, 称为监视器。当节点状态发生改变时(Znode 的增、删、改)将会触发 watch 所对应的操作。当 watch 被触发时,ZooKeeper 将会向客户端发送且仅发送一条通知,因为 watch 只能被触发一次,这样可以减少网络流量。这就对应前面说的,当有用户关注的主播上线的时候,就会给用户发送通知消息,这个动作就是由监视器来完成的
Zxid:Zxid 是一个 64 位的数字,它的高 32 位是 epoch 用来标识 leader 关系是否改变,每次一个Leader 被选出来,它都会有一个新的 epoch, 低 32 位是个递增计数。
使得 ZooKeeper 节点状态改变的每一个操作都将使节点接收到一个 Zxid 格式的时间戳,并且这个时间戳全局有序。也就是说,每个对节点的改变都将产生一个唯一的 Zxid, 如果 Zxid1的值小于 Zxid2 的值,那么 Zxid1 所对应的事件发生在 Zxid2 所对应的事件之前。
实际上,ZooKeeper 的每个节点维护者三个 Zxid 值,为别为:cZxid、mZxid、pZxid。
cZxid 是节点的创建时间所对应的 Zxid 格式时间戳。
mZxid 是节点的修改时间所对应的 Zxid 格式时间戳
版本号:
对节点的每一个操作都将致使这个节点的版本号增加。每个节点维护着三个版本号,它们分别为:
version:节点数据版本号
cversion:子节点版本
aversion:节点所拥有的 ACL 版本号
一个 ZooKeeper 节点自身拥有表示其状态的许多重要属性,如下图所示。