Zookeeper
2023-12-27 15:05:11 21 举报
AI智能生成
Zookeeper
作者其他创作
大纲/内容
ZAB协议(原子广播协议)
两种模式
恢复模式
当Leader被选出,且过半节点完成leader同步,就进去广播模式
导致的原因
集群启动
新增节点
leader崩溃
由于网络原因导致 Leader 服务器失去了与过半 Follower 的联系
恢复步骤
1.Leader选举
leader需要满足的要求
1)新选举出来的 Leader 不能包含未提交的 Proposal 。
2)新选举的 Leader 节点中含有最大的 zxid 。
Java版本快速选举算法
1)选 epoch 最大的
2)若 epoch 相等,选 zxid 最大的
3)若 epoch 和 zxid 相等,选择 server_id 最大的(zoo.cfg中的myid)
2)若 epoch 相等,选 zxid 最大的
3)若 epoch 和 zxid 相等,选择 server_id 最大的(zoo.cfg中的myid)
2.数据恢复
确保半数follow节点以上,与leader节点数据一致。
follow节点与leader比较,丢掉或提交 未提交的proposal
follow节点与leader比较,丢掉或提交 未提交的proposal
广播模式
Leader已经和过半fellow同步过后就进入广播模式
新增一个节点时,先进入恢复模式,等与leader同步之后该节点也进入广播模式
一直持续该模式,直到leader崩溃或者失去过半fellow,进入恢复模式。
提供
文件系统
类似文件目录的树形结构,但每个目录都为一个znode,可以存储1M的数据
znode
四种类型
永久节点
永久顺序节点
临时节点
临时顺序节点
内部结构
data
znode存储的数据信息
ACL
记录访问权限,即哪些人或哪些IP可以访问
stat
包含Znode的各种元数据,比如事务Id,版本号,时间戳,大小等
child
当前节点的子节点引用
通知系统
客户端可以向服务端的某个 Znode 注册一个 Watcher 监听,
当服务端的一些指定事件触发了这个 Watcher,服务端会向指定客户端发送一个事件通
知来实现分布式的通知功能,然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。
当服务端的一些指定事件触发了这个 Watcher,服务端会向指定客户端发送一个事件通
知来实现分布式的通知功能,然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。
工作机制
- 客户端注册watch
- 服务端处理watch
- 客户端回调watch
特性
一次性
一个watch一旦触发,就会被移除不再执行
每次变动都要通知到所有的客户端,给网络和服务器造成很大压力。
很多情况下,我们的客户端不需要知道服务端的每一次变动,我只要最新的数据即可
客户端串行执行
客户端watch回调过程,是一个串行同步的过程
轻量
通知简单,只通知发生了事件,不告诉具体事件
仅仅传递注册事件的布尔值
无法保证强一致性,只能保证最终一致性
事件-触发
getData
setData
exist
delete
getChildren
create
实现
客户端注册watch
(1)调用 getData()/getChildren()/exist()三个 API,传入 Watcher 对象
(2)标记请求 request,封装 Watcher 到 WatchRegistration
(3)封装成 Packet 对象,向服务端发送 request
(4)收到服务端响应后,将 Watcher 注册到 ZKWatcherManager 中进行管理
(5)请求返回,完成注册。
(2)标记请求 request,封装 Watcher 到 WatchRegistration
(3)封装成 Packet 对象,向服务端发送 request
(4)收到服务端响应后,将 Watcher 注册到 ZKWatcherManager 中进行管理
(5)请求返回,完成注册。
服务端处理watch
服务端接收 Watcher 并存储
接收到客户端请求,处理请求判断是否需要注册 Watcher,
需要的话将数据节点的节点路径和 ServerCnxn(ServerCnxn 代表一个客户端和服务端的连接,
实现了Watcher 的 process 接口,此时可以看成一个 Watcher 对象)存储在WatcherManager 的 WatchTable 和 watch2Paths 中去。
需要的话将数据节点的节点路径和 ServerCnxn(ServerCnxn 代表一个客户端和服务端的连接,
实现了Watcher 的 process 接口,此时可以看成一个 Watcher 对象)存储在WatcherManager 的 WatchTable 和 watch2Paths 中去。
Watcher 触发
以服务端接收到 setData() 事务请求触发 NodeDataChanged 事件为例:
2.1 封装 WatchedEvent
将通知状态(SyncConnected)、事件类型(NodeDataChanged)以及节点路径封装成一个 WatchedEvent 对象
2.2 查询 Watcher
从 WatchTable 中根据节点路径查找 Watcher
2.1 封装 WatchedEvent
将通知状态(SyncConnected)、事件类型(NodeDataChanged)以及节点路径封装成一个 WatchedEvent 对象
2.2 查询 Watcher
从 WatchTable 中根据节点路径查找 Watcher
调用 process 方法来触发 Watcher;通过 ServerCnxn 对应的 TCP 连接发送 Watcher 事件通知。
客户端回调watch
客户端 SendThread 线程接收事件通知,交由 EventThread 线程回调 Watcher。
客户端的 Watcher 机制同样是一次性的,一旦被触发后,该 Watcher 就失效了。
客户端的 Watcher 机制同样是一次性的,一旦被触发后,该 Watcher 就失效了。
Paxos
ZAB 用来构建高可用的分布式数据主备系统(Zookeeper),
Paxos 是用来构建分布式一致性状态机系统。
Paxos 是用来构建分布式一致性状态机系统。
权限控制
UGO(User,Group,Ohters)
在 Linux/Unix 文件系统中使用,也是使用最广泛的权限控制方式。是一种粗粒度的文件系统权限控制模式。
访问控制列表
ACL(Access Control List)
ACL(Access Control List)
三方面
权限模式(Scheme)
(1)IP:从 IP 地址粒度进行权限控制
(2)Digest:最常用,用类似于 username:password 的权限标识来进行权限配置,便于区分不同应用来进行权限控制
(3)World:最开放的权限控制方式,是一种特殊的 digest 模式,只有一个权限标识“world:anyone”
(4)Super:超级用户
(2)Digest:最常用,用类似于 username:password 的权限标识来进行权限配置,便于区分不同应用来进行权限控制
(3)World:最开放的权限控制方式,是一种特殊的 digest 模式,只有一个权限标识“world:anyone”
(4)Super:超级用户
授权对象
权限 Permission
(1)CREATE:数据节点创建权限,允许授权对象在该 Znode 下创建子节点
(2)DELETE:子节点删除权限,允许授权对象删除该数据节点的子节点
(3)READ:数据节点的读取权限,允许授权对象访问该数据节点并读取其数据内容或子节点列表等
(4)WRITE:数据节点更新权限,允许授权对象对该数据节点进行更新操作
(5)ADMIN:数据节点管理权限,允许授权对象对该数据节点进行 ACL 相关设置操作
(2)DELETE:子节点删除权限,允许授权对象删除该数据节点的子节点
(3)READ:数据节点的读取权限,允许授权对象访问该数据节点并读取其数据内容或子节点列表等
(4)WRITE:数据节点更新权限,允许授权对象对该数据节点进行更新操作
(5)ADMIN:数据节点管理权限,允许授权对象对该数据节点进行 ACL 相关设置操作
集群数据同步
分类
直接差异化同步(DIFF 同步)
先回滚再差异化同步(TRUNC+DIFF 同步)
仅回滚同步(TRUNC 同步)
全量同步(SNAP 同步)
其他
Chroot特性
3.2.0 版本后,添加了 Chroot 特性,
该特性允许每个客户端为自己设置一个命名空间。
如果一个客户端设置了 Chroot,那么该客户端对服务器的任何操作,都将会被限制在其自己的命名空间下。
该特性允许每个客户端为自己设置一个命名空间。
如果一个客户端设置了 Chroot,那么该客户端对服务器的任何操作,都将会被限制在其自己的命名空间下。
能够将一个客户端应用于 Zookeeper 服务端的一颗子树相对应
会话管理
角色
Leader
(1)事务请求的唯一调度和处理者,保证集群事务处理的顺序性
(2)集群内部各服务的调度者
(2)集群内部各服务的调度者
Follow
(1)处理客户端的非事务请求,转发事务请求给 Leader 服务器
(2)参与事务请求 Proposal 的投票
(3)参与 Leader 选举投票
(2)参与事务请求 Proposal 的投票
(3)参与 Leader 选举投票
Observer
(1)3.0 版本以后引入的一个服务器角色,在不影响集群事务处理能力的基础上提升集群的非事务处理能力
(2)处理客户端的非事务请求,转发事务请求给 Leader 服务器
(3)不参与任何形式的投票
(2)处理客户端的非事务请求,转发事务请求给 Leader 服务器
(3)不参与任何形式的投票
状态
Looking
寻 找 Leader 状态。当服务器处于该状态时,它会认为当前集群中没有 Leader,因此需要进入 Leader 选举状态。
Following
Leading
Observering
全局事务
当新产生 proposal 的时候,会依据数据库的两阶段过程,首先会向其他的 server 发出事务执行请求,
如果超过半数的机器都能执行并且能够成功,那么就会开始执行。
如果超过半数的机器都能执行并且能够成功,那么就会开始执行。
zxid来标识
zxid 实际上是一个 64 位的数字,
高 32 位是 epoch( 时期; 纪元; 世; 新时代)用来标识 leader 周期,如果有新的 leader 产生出来,epoch会自增,
低 32 位用来递增计数。
高 32 位是 epoch( 时期; 纪元; 世; 新时代)用来标识 leader 周期,如果有新的 leader 产生出来,epoch会自增,
低 32 位用来递增计数。
Leader主节点存在的意义,减少重复计算,提升性能
扩容
全部重启
逐个重启
3.5 版本开始支持动态扩容。
java客户端
zookeeper自带,zkClient
Apache提供Curator
常用命令
ls
get
delete
create
set
参考:
https://thinkwon.blog.csdn.net/article/details/104397719
https://www.jianshu.com/p/2bceacd60b8a
https://blog.csdn.net/tomato__/article/details/78673365
https://thinkwon.blog.csdn.net/article/details/104397719
https://www.jianshu.com/p/2bceacd60b8a
https://blog.csdn.net/tomato__/article/details/78673365
0 条评论
下一页