ZooKeeper的数据模型与监听机制

        相信大家在看了《ZooKeeper入门(概念+shell操作)》后对ZooKeeper已经有了一定的基础,本篇博客小菌则为大家带来的是关于 ZooKeeper的数据模型与监听机制!让大家对ZooKeeper的底层原理有一个更深的认知!


文章目录

  • ZooKeeper数据模型

  • 数据结构图 * 节点类型 * 节点属性

    • ZooKeeper Watcher(监听机制)
  • Watch机制特点 * 通知状态和事件类型 * Shell 客户端设置watcher

        

ZooKeeper数据模型

        ZooKeeper的数据模型,在结构上和标准文件系统的非常相似,拥有一个层次的命名空间,都是采用树形层次结构,ZooKeeper树中的每个节点被称为— Znode。和文件系统的目录树一样,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部分组成:

① stat:此为状态信息, 描述该Znode的版本, 权限等信息

② data:与该Znode关联的数据

③ children:该Znode下的子节点

节点类型

        Znode有两种,分别为 临时节点永久节点

        节点的类型在创建时即被确定,并且 不能改变

         临时节点:该节点的生命周期依赖于创建它们的会话。 一旦会话结束,临时节点将被自动删除,当然可以也可以手动删除。 临时节点不允许拥有子节点。

         永久节点:节点的生命周期不依赖于会话,并且只有在客户端显示执行删除操作的时候,他们才能被删除。

        Znode还有一个序列化的特性,如果创建的时候指定的话,该Znode的名字后面会自动追加一个不断增加的序列号。序列号对于此节点的父节点来说是唯一的,这样便会记录每个子节点创建的先后顺序。它的格式为“%10d”(10位数字,没有数值的数位用0补充,例如“0000000001”)。
在这里插入图片描述
这样便会存在 四种类型的Znode节点,分别对应:

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

节点属性

每个znode都包含了一系列的属性,通过命令get,可以获得节点的属性。

在这里插入图片描述

dataVersion:数据版本号,每次对节点进行set操作,dataVersion的值都会增加1(即使设置的是相同的数据),可有效避免了数据更新时出现的先后顺序问题。

cversion :子节点的版本号。当znode的子节点有变化时,cversion 的值就会增加1。

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 Watcher(监听机制)

        ZooKeeper提供了 分布式数据发布/订阅功能,一个典型的发布/订阅模型系统定义了一种一对多的订阅关系,能让多个订阅者同时监听某一个主题对象,当这个主题对象自身状态变化时,会通知所有订阅者,使他们能够做出相应的处理。

        ZooKeeper中,引入了 Watcher机制来实现这种分布式的通知功能。ZooKeeper允许客户端向服务端注册一个Watcher监听,当服务端的一些事件触发了这个Watcher,那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。

        触发事件种类很多,如:节点创建,节点删除,节点改变,子节点改变等。

        总的来说可以概括Watcher为以下三个过程: 客户端向服务端注册Watcher、服务端事件发生触发Watcher、客户端回调Watcher得到触发事件情况

Watch机制特点

  • 一次性触发

事件发生触发监听,一个watcher event就会被发送到设置监听的客户端,这种效果是一次性的,后续再次发生同样的事件,不会再次触发。

  • 事件封装

ZooKeeper使用WatchedEvent对象来封装服务端事件并传递。
WatchedEvent包含了每一个事件的三个基本属性:

通知状态(keeperState),事件类型(EventType)和节点路径(path)

  • event异步发送

watcher的通知事件从服务端发送到客户端是异步的。

  • 先注册再触发

Zookeeper中的watch机制,必须客户端先去服务端注册监听,这样事件发送才会触发监听,通知给客户端。

通知状态和事件类型

        同一个事件类型在不同的通知状态中代表的含义有所不同,下表列举了常见的通知状态和事件类型。

在这里插入图片描述
其中 连接状态事件(type=None, path=null)不需要客户端注册,客户端只要有需要直接处理就行了。

Shell 客户端设置watcher

设置节点数据变动监听:
在这里插入图片描述
通过另一个客户端更改节点数据:
在这里插入图片描述
此时设置监听的节点收到通知:
在这里插入图片描述



本次的分享到这里就结束了,受益的小伙伴们或对大数据技术感兴趣的朋友记得关注小菌哟(^U^)ノ~YO

在这里插入图片描述

代码交流 2021