zookeeper
2021-11-13 17:36:00 30 举报
AI智能生成
Zookeeper是一个开源的分布式协调服务,由雅虎公司创立并贡献给Apache基金会。它是一个为分布式应用提供一致性服务的软件,提供了一项基础服务——分布式同步。它的作用是帮助节点管理它们的数据、配置信息和状态。当一个节点加入集群时,它会向Zookeeper注册自己的身份信息;当节点离开集群时,它会注销自己的身份信息。这样,其他节点就可以知道集群中有哪些节点以及它们的运行状态。Zookeeper还支持一些高级功能,如选举、分布式锁和队列等。总之,Zookeeper是一个非常有用的工具,可以帮助我们更好地管理和协调分布式系统中的各种资源和服务。
作者其他创作
大纲/内容
提供
文件系统
类似文件目录的树形结构,但每个目录都为一个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 就失效了。
权限控制
UGO(User,Group,Ohters)
在 Linux/Unix 文件系统中使用,也是使用最广泛的权限控制方式。是一种粗粒度的文件系统权限控制模式。
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 同步)
概述
开源分布式协调服务
运用场景
数据发布/订阅
及配置中心:发布者发布数据,订阅者订阅数据
实现方式
数据存储:将数据(配置信息)存储到 Zookeeper 上的一个数据节点(最大1M数据)
数据获取:应用在启动初始化节点从 Zookeeper 数据节点读取数据,并在该节点上注册一个数据变更 Watcher
数据变更:当变更数据时,更新 Zookeeper 对应节点数据,Zookeeper会将数据变更通知发到各客户端,客户端接到通知后重新读取变更后的数据即可
负载均衡
zk 的命名服务(文件系统)
通过指定的名字来获取资源或者服务的地址
利用 zk 创建一个全局的路径,这个路径就可以作为一个名字,指向集群中的集群,提供的服务的地址,或者一个远程的对象等等。
分布式协调通知
通过控制台改变某个节点的状态,然后 zk 将这些变化发送给注册了这个节点的 watcher 的所有客户端。
Master选举
Zookeeper 分布式锁(文件系统、通知机制)
Zookeeper 集群管理(文件系统、通知机制)
zk 的配置管理(文件系统、通知机制)
分布式特征
顺序一致性
来自client的更新请求顺序执行
每个更新请求都有一个全局唯一的时间戳(zxid)
原子性
集群中所有节点要么全部执行,要么全都不执行
单一视图
无论client连接的哪个接口,获取的数据都是一致的
可靠性
一旦更新生效,将一直保留,直到再次更改
实时性(最终一致性)
在特定的一段时间内,任何系统的改变都能被客户端看到,或者被监听到
某一时刻可能出现不一致(ZAB协议)
节点增多
读的吞吐会增高,写的吞吐会降低
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,进入恢复模式。
其他
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
Paxos
ZAB 用来构建高可用的分布式数据主备系统(Zookeeper),
Paxos 是用来构建分布式一致性状态机系统。
Paxos 是用来构建分布式一致性状态机系统。
参考:
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 条评论
下一页