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