ZK_01Zookeeper特性与节点数据类型
2023-05-17 10:08:38 7 举报AI智能生成
Zookeeper特性与节点数据类型
作者其他创作
大纲/内容
CAP&Base理论
CAP 理论
对于一个分布式计算系统来说，不可能同时满足以下三点
一致性Consistency
指数据在多个副本之间是否能够保持一致的特性，等同于所有节点访问同一份最新的数据副本
在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态
可用性Availability
每次请求都能获取到正确的响应，但是不保证获取的数据为最新数据
分区容错性Partition tolerance
布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务
最多只能同时满足其中的两项，P 是必须的，因此只能在 CP 和 AP 中选择
zookeeper 保证的是 CP
spring cloud 系统中的注册中心 eureka实现的是 AP
BASE 理论
Basically Available(基本可用)
在分布式系统出现故障，允许损失部分可用性（服务降级、页面降级
Soft-state(软状态)
允许分布式系统出现中间状态
中间状态不影响系统的可用性
Eventually Consistent(最终一致性)
data replications 经过一段时间达到一致性
BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果
我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性
Zookeeper
概念
主要用来解决分布式集群中应用系统的一致性问题
目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用
本质上是一个分布式的小文件存储系统（Zookeeper=文件系统+监听机制）
设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据
配置参数
数据结构
与 Unix 文件系统很类似，整体上可以看作是一棵树，每个节点称做一个 ZNode
层次模型，层次模型常见于文件系统
文件系统的树形结构便于表达数据之间的层次关系
文件系统的树形结构便于为不同的应用分配独立的命名空间( namespace )
节点分类
持久节点(PERSISTENT)
znode在创建之后即使发生ZooKeeper集群宕机或者client宕机也不会丢失
临时节点(EPHEMERAL )
client宕机或者client在指定的timeout时间内没有给ZooKeeper集群发消息，这样的znode就会消失
持久顺序节点(PERSISTENT_SEQUENTIAL)
znode除了具备持久性znode的特点之外，znode的名字具备顺序性
临时顺序节点(EPHEMERAL_SEQUENTIAL)
znode除了具备临时性znode的特点之外，zorde的名字具备顺序性
Container节点
Container容器节点，当容器中没有任何子节点，该容器节点会被zk定期删除（定时任务默认60s 检查一次)
ZK 服务端启动后，会有一个单独的线程去扫描，所有的容器节点，当发现容器节点的子节点数量为 0 时，会自动删除该节点。可以用于 leader 或者锁的场景中
TTL节点
带过期时间节点，默认禁用，需要在zoo.cfg中添加 extendedTypesEnabled=true 开启
ttl不能用于临时节点
节点状态信息
cZxid ：Znode创建的事务id
ctime：节点创建时的时间戳
mZxid ：Znode被修改的事务id，即每次对znode的修改都会更新mZxid
对于zk来说，每次的变化都会产生一个唯一的事务id，zxid（ZooKeeper Transaction Id），通过zxid，可以确定更新操作的先后顺序
例如，如果zxid1小于zxid2，说明zxid1操作先于zxid2发生，zxid对于整个zk都是唯一的，即使操作的是不同的znode
pZxid: 表示该节点的子节点列表最后一次修改的事务ID
添加子节点或删除子节点就会影响子节点列表，但是修改子节点的数据内容则不影响该ID
注意: 只有子节点列表变更了才会变更pzxid，子节点内容变更不会影响pzxid
mtime：节点最新一次更新发生时的时间戳
cversion ：子节点的版本号。当znode的子节点有变化时，cversion 的值就会增加1
dataVersion：数据版本号，每次对节点进行set操作，dataVersion的值都会增加1（即使设置的是相同的数据）
可有效避免了数据更新时出现的先后顺序问题
ephemeralOwner:如果该节点为临时节点, ephemeralOwner值表示与该节点绑定的session id
如果不是, ephemeralOwner值为0(持久节点)
Zookeeper 节点特性总结
同一级节点 key 名称是唯一的
已存在/lock节点，再次创建会提示已经存在
创建节点时，必须要带上全路径
session 关闭，临时节点清除
自动创建顺序节点
watch 机制，监听节点变化
delete 命令只能一层一层删除。提示：新版本可以通过 deleteall 命令递归删除
监听通知（watcher）机制
一个Watch事件是一个一次性的触发器
当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们
Zookeeper采用了 Watcher机制实现数据的发布订阅功能
多个订阅者可同时监听某一特定主题对象
当该主题对象的自身状态发生变化时例如节点内容改变、节点下的子节点列表改变等，会实时、主动通知所有订阅者
watcher的过程
客户端向服务端注册watcher
服务端事件发生触发watcher
客户端回调watcher得到触发事件情况
：Zookeeper中的watch机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知给客户端
永久性Watch
在被触发之后，仍然保留，可以继续监听ZNode上的变更，是Zookeeper 3.6.0版本新增的功能
addWatch [-m mode] path
addWatch的作用是针对指定节点添加事件监听，支持两种模式
PERSISTENT，持久化订阅，针对当前节点的修改和删除事件，以及当前节点的子节点的删除和新增事件
PERSISTENT_RECURSIVE，持久化递归订阅，在PERSISTENT的基础上，增加了子节点修改的事件触发，
以及子节点的子节点的数据变化都会触发相关事件（满足递归订阅特性）
以及子节点的子节点的数据变化都会触发相关事件（满足递归订阅特性）
应用场景
注册中心
数据发布/订阅（常用于实现配置中心）
负载均衡
命名服务
分布式协调/通知
集群管理
Master选举
分布式锁
分布式队列
0 条评论
下一页
