分布式_zookeeper
2021-12-14 15:24:47 28 举报AI智能生成
zookeeper简介
作者其他创作
大纲/内容
简介
说明
作用
java客户端
原生API连接
curator连接
Curator
简介
maven依赖
API
创建会话
创建数据节点
删除数据节点
读取数据节点
修改数据节点
事务
其他
异步回调
curator 的几种锁方案
1、InterProcessMutex：分布式可重入排它锁
2、InterProcessSemaphoreMutex：分布式排它锁
3、InterProcessReadWriteLock：分布式读写锁
znode 结构
说明
状态属性
cZxid 创建节点时的事务ID
ctime 创建节点时的时间
mZxid 最后修改节点时的事务ID
mtime 最后修改节点时的时间
pZxid 表示该节点的子节点列表最后一次修改的事务ID
cversion 子节点版本号，子节点每次修改版本号加1
dataversion 数据版本号，数据每次修改该版本号加1
aclversion 权限版本号，权限每次修改该版本号加1
ephemeralOwner 创建该临时节点的会话的sessionID。
dataLength 该节点的数据长度
numChildren 该节点拥有子节点的数量
session 基本原理
连接
Session 的创建
sessionID: 会话ID
Timeout：会话超时时间
TickTime：下次会话超时时间点，默认 2000 毫秒。
isClosing：该属性标记一个会话是否已经被关闭
子主题
Session 的状态
connecting：连接中
connected：已连接，连接成功之后的状态。
closed：已关闭
会话超时管理（分桶策略+会话激活）
子主题
客户端基础命令使用
ls 命令用于查看某个路径下目录列表。
ls2 命令用于查看某个路径下目录列表，它比 ls 命令列出更多的详细信息。
get 命令用于获取节点数据和状态信息。
stat 命令用于查看节点状态信息。
create 命令用于创建节点并赋值。
set 命令用于修改节点存储的数据。
delete 命令用于删除某节点。
四字命令
conf 3.3.0版本引入的。打印出服务相关配置的详细信息。
cons 3.3.0版本引入的。列出所有连接到这台服务器的客户端全部连接/会话详细信息。
crst 3.3.0版本引入的。重置所有连接的连接和会话统计信息。
dump 列出那些比较重要的会话和临时节点。这个命令只能在leader节点上有用。
envi 打印出服务环境的详细信息。
reqs 列出未经处理的请求
ruok 测试服务是否处于正确状态。
stat 输出关于性能和连接的客户端的列表。
srst 重置服务器的统计。
srvr 3.3.0版本引入的。列出连接服务器的详细信息
wchs 3.3.0版本引入的。列出服务器watch的详细信息。
wchc 3.3.0版本引入的。通过session列出服务器watch的详细信息，它的输出是一个与watch相关的会话的列表。
wchp 3.3.0版本引入的。通过路径列出服务器watch的详细信息。它输出一个与session相关的路径。
mntr 3.4.0版本引入的。输出可用于检测集群健康状态的变量列表
节点特性
同一级节点 key 名称是唯一的
创建节点时，必须要带上全路径
session 关闭，临时节点清除
自动创建顺序节点
watch 机制，监听节点变化
delete 命令只能一层一层删除
权限控制 ACL
命令行
getAcl 命令：获取某个节点的 acl 权限信息。
setAcl 命令：设置某个节点的 acl 权限信息。
addauth 命令：输入认证授权信息，注册时输入明文密码，加密形式保存。
构成
scheme：代表采用的某种权限机制，包括 world、auth、digest、ip、super 几种。
id：代表允许访问的用户。
permissions：权限组合字符串，由 cdrwa 组成，其中每个字母代表支持不同权限， 创建权限 create(c)、删除权限 delete(d)、读权限 read(r)、写权限 write(w)、管理权限admin(a)。
事件机制原理剖析
watcher 机制过程
客户端注册 watcher。
服务端处理 watcher。
服务端触发 watcher 事件。
客户端回调 watcher。
户端注册 watcher 有三种方式
getData
exists
getChildren
数据同步流程（ZAB）
消息广播
崩溃恢复
数据不一致性的隐患
1、Leader 服务器将消息 commit 发出后，立即崩溃
2、Leader 服务器刚提出 proposal 后，立即崩溃
恢复模式策略
1、选举 zxid 最大的节点作为新的 leader
2、新 leader 将事务日志中尚未提交的消息进行处理
Leader 选举原理
选举存在两个阶段
启动时 leader 选举
（1）每台 server 发出一个投票
（2）接收来自各个服务器的投票
（3）分别处理投票
（4）统计投票
（5）改变服务器状态
运行过程中 leader 服务器宕机
（1）变更状态。leader 挂后，其他非 Oberver服务器将自身服务器状态变更为 LOOKING。
（2）每个 server 发出一个投票。在运行期间，每个服务器上 zxid 可能不同。
（3）处理投票。规则同启动过程。
（4）统计投票。与启动过程相同。
（5）改变服务器状态。与启动过程相同。
重要的参数
服务器 ID(myid)：编号越大在选举算法中权重越大
事务 ID(zxid)：值越大说明数据越新，权重越大
逻辑时钟(epoch-logicalclock)：同一轮投票过程中的逻辑时钟值是相同的，每投完一次值会增加
选举状态
LOOKING: 竞选状态
FOLLOWING: 随从状态，同步 leader 状态，参与投票
OBSERVING: 观察状态，同步 leader 状态，不参与投票
LEADING: 领导者状态
分布式锁实现原理
排他锁
共享锁
0 条评论
下一页
