zookeeper知识体系
2022-06-14 23:00:40 0 举报AI智能生成
zookeeper知识体系
作者其他创作
大纲/内容
zk概念说明
zk是什么
是一个分布式系统协调服务
Zookeeper 提供了一个类似于 Linux 文件系统的树形结构（可认为是轻量级的内存文件系统，但
只适合存少量信息，完全不适合存储大量文件或者大文件）
只适合存少量信息，完全不适合存储大量文件或者大文件）
同时提供了对于每个节点的监控与
通知机制。
通知机制。
核心概念
znode节点
zk数据模型中的数据单元
类似于文件系统，以树形结构存储
包含的信息
path/唯一路径
childNode：子节点
stat：状态属性
type：节点类型
持久性节点
persistent持久节点
persistent_sequential持久有序节点
创建时会在路径上加上序号作为后缀
创建命令:create -s/path
persistent_with_ttl 待ttl的持久节点
persistent_sequential_with_ttl持久有序节点
临时节点（不能拥有子节点）
ephemeral 临时节点
ephemeral_sequential 临时有序节点
container容器节点
用于leader、lock等特殊用途，当容器节点不存在任何子节点时，容器将成为未来服务器在将来某个时刻删除的候选节点
节点对应的数值
版本号
每个znode都有版本号，随着每次数据变化自增
当多个client对node进行操作时保证了数据的一致性
节点权限（ACL）
保障数据安全的权限控制机制
包含的最大数据量是1mb
监听与通知（watcher）
定义
zk允许客户端向服务端的某个 Znode 注册一个 Watcher 监听
当服务端的一些指定事件触发了这个 Watcher，
服务端会向指定客户端发送一个事件通知来实现分布式的通知功能
服务端会向指定客户端发送一个事件通知来实现分布式的通知功能
然后客户端根据 Watcher 通知状态和事件类型做出
业务上的改变。
业务上的改变。
集群角色
Leader
zk集群同一时间只会有一个实际工作的 Leader，
它会发起并维护与各 Follwer及 Observer 间的心跳。
它会发起并维护与各 Follwer及 Observer 间的心跳。
所有的写操作必须要通过 Leader 完成再由 Leader 将写操作广播给其它服务器
只要有超过半数节点（不包括 observeer 节点） 写入成功，该写请求就会被提交
Follower
一个 zk集群可能同时存在多个 Follower，它会响应 Leader 的心跳
Follower 可直接处理并返回客户端的读请求，同时会将写请求转发给 Leader 处理
并且负责在 Leader 处理写请求时对请求进行投票
Observer
角色与 Follower 类似，但是无投票权
引入 Observer，Observer 不参与投票； Observers 接受客户端的连接，并将写请求转发给 leader 节点
加入更多 Observer 节点，提高伸缩性，同时不影响吞吐率
zk原子广播（zab）
Zab 协议模式
恢复模式
当服务启动或者在领导者崩溃后， Zab 就进入了恢复模式，当领导者被选举出来，且大多
数 server 的完成了和 leader 的状态同步以后，恢复模式就结束了
数 server 的完成了和 leader 的状态同步以后，恢复模式就结束了
广播模式
一旦 leader 已经和多数的 follower 进行了状态同步后，他就可以开始广播消息了
ACL权限
CREATE
create子节点
READ
getChildren，getData
WRITE
setDate
DELETE
delete子节点
ADMIN
setACL
zk使用场景
服务发现/命名服务
分布式协调/通知
分布式（Master/leader）选举
子主题
数据发布/订阅
发布订阅模式
推(push)模式
拉（pull）模式
zk采用推拉结合模式
客户端向ZK注册自己关注的节点。
一旦该节点的数据发送了变化，那么zk就会向相应的客户端发送watcher事件通知。
客户端收到这个消息通知后，主动到服务端获取最新数据。
一旦该节点的数据发送了变化，那么zk就会向相应的客户端发送watcher事件通知。
客户端收到这个消息通知后，主动到服务端获取最新数据。
配置管理
分布式锁
zk核心机制流程
zk Watcher 机制
架构
子主题
主流程
客户端首先将Watcher注册到服务端，同时将Watcher对象保存到客户端的Watch管理器中
当ZooKeeper服务端监听的数据状态发生变化时，服务端会主动通知客户端
接着客户端的Watch管理器会触发相关Watcher来回调相应处理逻辑
Watcher 特性
一次性
客户端串行执行
轻量
客户端注册 Watcher流程
zk数据同步
说明
数据同步分类
DIFF：直接差异化同步
TRUNC+DIFF：先回滚再差异化同步
TRUNC：仅回滚同步
SNAP：全量同步
流程
follower将自己最大zxid发送给leader
leader根据follower的zxid来确定同步点
leader向follower发送proposal消息，并且紧跟着一条commit消息，标识该事物已经被提交
同步完成后follower状态变为update，提供服务
zk部署架构
部署模式分类
单机模式
伪集群模式
集群模式
核心概念
zk server状态
LOOKING：寻找Leader
LEADING：Leader状态，对应的节点为Leader。
FOLLOWING：Follower状态，对应的节点为Follower
OBSERVING：Observer状态，对应节点为Observer，该节点不参与Leader选举
ZXID（zookeeper transaction id）
每个改变Zookeeper状态的操作都会形成一个对应的zxid，并记录到transaction log中
这个值越大，表示更新越新
myid
服务器SID，一个数字,通过配置文件配置，唯一
SID
服务器的唯一标识
Leader的必要条件
Leader要具有最高的zxid
当集群的规模是n时，集群中大多数的机器（至少n/2+1）得到响应并follow选出的Leader。
集群选主
选主时机
启动时，集群服务器刚启动
运行时，Leader 崩溃
选主流程
每个服务器发送一个投票(SID,ZXID)
其中sid是自己的myid，初始阶段都将自己投为Leader
其中sid是自己的myid，初始阶段都将自己投为Leader
接收来自其他服务器的投票。
集群的每个服务器收到投票后，首先判断该投票的有效性，
如检查是否是本轮投票、是否来自LOOKING状态的服务器。
如检查是否是本轮投票、是否来自LOOKING状态的服务器。
处理投票
针对每个投票都按以下规则与自己的投票PK，
PK后依据情况是否更新投票，再发送给其他机器。
PK后依据情况是否更新投票，再发送给其他机器。
a.优先检查ZXID，ZXID较大者优先为Leader
b.如果ZXID相同，检查SID，SID较大者优先为Leader
统计投票
每次投票后，服务器统计所有投票，判断是否有过半的机器收到相同的投票，
如果某个投票达到一半的要求，则认为该投票提出者可以成为Leader。
如果某个投票达到一半的要求，则认为该投票提出者可以成为Leader。
改变服务器状态
一旦确定了Leader，每个服务器都更新自己的状态，Leader变更为Leading，
Follower变更为Following 正常情况下一旦选出一个Leader则一直会保持，
除非Leader服务器宕掉，则再进行重新选举。
Follower变更为Following 正常情况下一旦选出一个Leader则一直会保持，
除非Leader服务器宕掉，则再进行重新选举。
0 条评论
下一页
