4、ZK的节点特性和分类
4.1 节点特性
ZooKeeper的数据模型,在结构上和标准文件系统的非常相似,都是采用树形层次结构,和文件系统的目录树一样,ZooKeeper树中的每个节点可以拥有子节点。 但也有不同之处: Znode兼具文件和目录两种特点: Znode没有文件和目录之分,Znode既有像文件一样存储数据,也能像目录一样作为路径标识的一部分 Znode具有原子性操作: 读操作将获取与节点相关的所有数据,写操作也将替换掉节点的所有数据 Znode存储数据大小有限制: 每个Znode的数据大小至多1M,当时常规使用中应该远小于此值 Znode通过路径引用: 路径必须是绝对的,因此他们必须由斜杠字符来开头。除此以外,他们必须是唯一的,也就是说每一个路径只有一个表示,因此这些路径不能改变。 默认有/zookeeper节点用以保存关键的管理信息。
4.2 节点分类
节点分类: 永久普通节点,临时普通节点,永久序列化节点,临时序列化节点 创建永久普通节点: create /节点 数据 创建临时普通节点: create -e /节点 数据 创建永久序列化节点: create -s /节点 数据 创建临时序列化节点: create -e -s /节点 数据 注意: 临时节点不能创建子节点。类似文件夹下面不能再创建文件夹
4.3 节点属性
每个znode都包含了一系列的属性,通过命令get /节点,可以获得节点的属性 注意: 对于zk来说,每次的变化都会产生一个唯一的事务id,zxid(ZooKeeper Transaction Id)。通过zxid,可以确定更新操作的先后顺序。例如,如果zxid1小于zxid2,说明zxid1操作先于zxid2发生,zxid对于整个zk都是唯一的,即使操作的是不同的znode。 cZxid :Znode创建的事务id。 ctime :Znode创建时的时间戳.
mZxid :Znode被修改的事务id,即每次对当前znode的修改都会更新mZxid。 mtime :Znode最新一次更新发生时的时间戳.
pZxid :Znode的子节点列表变更的事务ID,添加子节点或删除子节点就会影响子节点列表 cversion :子节点进行变更的版本号。添加子节点或删除子节点就会影响子节点版本号
dataVersion:数据版本号,每次对节点进行set操作,dataVersion的值都会增加1(即使设置的是相同的数据),可有效避免了 数据更新时出现的先后顺序问题。 aclVersion : 权限变化列表版本 access control list Version ephemeralOwner : 字面翻译临时节点拥有者,永久节点值为: 0x0,临时节点值为:会话ID (不是0x0的就是临时节点) dataLength : Znode数据长度 numChildren: 当前Znode子节点数量(不包括子子节点)
5、ZK集群特点
1. 全局数据一致: 集群中每个服务器保存一份相同的数据副本,client无论连接到哪个服务器,展示的数据都是一致的,这是最重要的特征; 2. 可靠性: 如果消息被其中一台服务器接受,那么将被所有的服务器接受。 3. 顺序性: 包括全局有序和偏序两种:全局有序是指如果在一台服务器上消息a在消息b前发布,则在所有Server上消息a都将在消息b前被发布;偏序是指如果一个消息b在消息a后被同一个发送者发布,a必将排在b前面。 4. 数据更新原子性: 一次数据更新要么成功(半数以上节点成功),要么失败,不存在中间状态; 5. 实时性: Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息,或者服务器失效的信息。
6、watch监听机制
ZooKeeper中,引入了Watcher机制来实现数据发布/订阅功能,一个典型的发布/订阅模型系统定义了一种一对多的订阅关系,能让多个订阅者同时监听某一个主题对象,当这个主题对象自身状态变化时,会通知所有订阅者,使他们能够做出相应的处理。 ZooKeeper允许客户端向服务端注册一个Watcher监听,当服务端的一些事件触发了这个Watcher,那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。
watch监听机制过程: 客户端向服务端注册Watcher 服务端事件发生触发Watcher 客户端回调Watcher得到触发事件情况 Watch监听机制注册格式: get /节点绝对路径 watch Watch监听机制特点: 先注册再触发: Zookeeper中的watch机制,必须客户端先去服务端注册监听,这样事件发送才会触发监听,通知给客户端 一次性触发: 事件发生触发监听,一个watcher event就会被发送到设置监听的客户端,这种效果是一次性的,后续再次发生同样的事件,不会再次触发。 异步发送: watcher的通知事件从服务端发送到客户端是异步的。 通知内容: 通知状态(keeperState),事件类型(EventType)和节点路径(path)
示例:
node1上创建临时节点
[zk: localhost:2181(CONNECTED) 1] create -e /master 1111 Created /master
node2上设置监听
[zk: localhost:2181(CONNECTED) 28] get /master watch
node1退出
[zk: localhost:2181(CONNECTED) 2] quit
node2查看消息
[zk: localhost:2181(CONNECTED) 29] WATCHER:: WatchedEvent state:SyncConnected type:NodeDeleted path:/master
7、ZK应用
1. 数据发布/订阅 数据发布/订阅系统,就是发布者将数据发布到ZooKeeper的一个节点上,提供订阅者进行数据订阅,从而实现动态更新数据的目的,实现配置信息的集中式管理和数据的动态更新。 主要用到知识点: 监听机制 2. 提供集群选举 在分布式环境下,不管是主从架构集群,还是主备架构集群,要求在服务的时候有且有一个正常的对外提供服务,我们称之为master。 当master出现故障之后,需要重新选举出的新的master。保证服务的连续可用性。zookeeper可以提供这样的功能服务。 主要用到知识点: znode唯一性、临时节点短暂性、监听机制。 选举概述: 选举要求: 过半原则,所以搭建集群一般奇数,只要某个node节点票数过半立刻成为leader 集群第一次启动: 启动follower每次投票后,他们会相互同步投票情况,如果票数相同,谁的myid大,谁就当选leader,一旦确定了leader,后面来的默认就是follower,即使它的myid大,leader也不会改变(除非leader宕机了) leader宕机后启动: 每一个leader当老大的时候,都会产生新纪元epoch,且每次操作完节点数据都会更新事务id(高32位_低32位) ,当leader宕机后,剩下的follower就会综合考虑几个因素选出最新的leader,先比较最后一次更新数据事务id(高32位_低32位),谁的事务id最大,谁就当选leader,如果更新数据的事务id都相同的情况下,就需要再次考虑myid,谁的myid大,谁就当选leader