Zookeeper
2019-06-17 11:01:53 0 举报AI智能生成
登录查看完整内容
zookeeper 架构、核心概念、关键流程
作者其他创作
大纲/内容
Zookeeper
特点
顺序一致性
从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到 ZooKeeper 中去
原子性
要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用
单一系统镜像
无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的
写操作并不保证更新被所有的 Follower 立即确认，因此通过部分 Follower 读取数据并不能保证读到最新的数据，而部分 Follwer 及 Leader 可读到最新数据
如果一定要保证单一系统镜像，可在读操作前使用 sync 方法
可靠性
一旦一次更改请求被应用，更改的结果就会被持久化
最终一致性
写操作最终（而非立即）会对客户端可见
组成
znode
data（数据内容）
stat（状态信息）
角色
leader
一个ZooKeeper集群同一时间只会有一个实际工作的Leader
发起并维护与各Follwer及Observer间的心跳
所有的写操作必须要通过Leader完成再由Leader将写操作广播给其它服务器
follower
一个ZooKeeper集群可能同时存在多个Follower
响应Leader的心跳
直接处理并返回客户端的读请求
将写请求转发给Leader处理
具有leader投票权
observer
和follower类似，不具有投票权
操作
写操作
写leader
1、客户端向Leader发起写请求
2、Leader将写请求以Proposal的形式发给所有Follower并等待ACK
3、Follower收到Leader的Proposal后返回ACK
4、Leader得到过半数的ACK（Leader对自己默认有一个ACK）后向所有的Follower和Observer发送Commmit
5、Leader将处理结果返回给客户端
写Follower/Observer
Follower/Observer均可接受写请求，但不能直接处理，而需要将写请求转发给Leader处理
除了多了一步请求转发，其它流程与直接写Leader无任何区别
读操作
读操作不需要服务器之间交互
Follower/Observer越多，整体可处理的读请求量越大，也即读性能越好
选举
FastLeaderElection（基于TCP）
基本概念
myid
每个ZooKeeper服务器，都需要在数据文件夹下创建一个名为myid的文件
该文件包含整个ZooKeeper集群唯一的ID（整数）
zxid（Zookeeper Transaction Id）
标识一次更新操作的Proposal ID
为了保证顺序性，该zkid必须单调递增
高32位是Leader的epoch，从1开始，每次选出新的Leader，epoch加一
低32位为该epoch内的序号，每次epoch变化，都将低32位的序号重置
服务器状态
LOOKING（不确定Leader状态）
该状态下的服务器认为当前集群中没有Leader，会发起Leader选举
FOLLOWING（跟随者状态）
表明当前服务器角色是Follower，并且它知道Leader是谁
LEADING（领导者状态）
表明当前服务器角色是Leader，它会维护与Follower间的心跳
OBSERVING（观察者状态）
表明当前服务器角色是Observer
选票数据结构
logicClock
每个服务器会维护一个自增的整数
表示这是该服务器发起的第多少轮投票
state
当前服务器状态
self_id
当前服务器myid
self_zxid
当前服务器最大的zxid
vote_id
被推选的服务器myid
vote_zxid
被推选的服务器最大的zxid
投票流程
1、自增选举轮次
ZooKeeper规定所有有效的投票都必须在同一轮次中
每个服务器在开始新一轮投票时，会先对自己维护的logicClock进行自增操作
2、初始化选票
每个服务器在广播自己的选票前，会将自己的投票箱清空
票箱中只会记录每一投票者的最后一票
3、发送初始化选票
每个服务器最开始都是通过广播把票投给自己
4、接收外部投票
服务器会尝试从其它服务器获取投票，并记入自己的投票箱内
如果无法获取任何外部投票，则会确认自己是否与集群中其它服务器保持着有效连接
如果是，则再次发送自己的投票
如果否，则马上与之建立连接
5、判断选举轮次
外部投票的logicClock大于自己的logicClock
说明该服务器的选举轮次落后于其它服务器的选举轮次
立即清空自己的投票箱并将自己的logicClock更新为收到的logicClock
再对比自己之前的投票与收到的投票以确定是否需要变更自己的投票
最终再次将自己的投票广播出去
外部投票的logicClock小于自己的logicClock
当前服务器直接忽略该投票，继续处理下一个投票。
外部投票的logickClock与自己的相等
进行选票PK
6、选票PK
若外部vote_zxid较大
将自己的票中的vote_zxid与vote_myid更新为收到的票中的vote_zxid与vote_myid并广播出去
若vote_zxid相同，若外部投票的vote_myid比较大
将自己的票中的vote_myid更新为收到的票中的vote_myid并广播出去
7、统计选票
已经确定有过半服务器认可了自己的投票，则终止投票，否则继续投票
8、更新服务器状态
若过半的票投给了自己
服务器状态更新为LEADING
否则，FOLLOWING
Watch机制
流程
所有的读操作都可以附带一个watch
一旦相应数据被改变，该watch就会被触发
主动推送
Watch被触发时，由 ZooKeeper 服务器主动将更新推送给客户端，而不需要客户端轮询
一次性
数据变化时，Watch 只会被触发一次
想得到后续更新的通知，必须要在 Watch 被触发后重新注册一个 Watch
可见性
更新通知先于更新结果
客户端在读请求中附带 Watch，Watch 被触发的同时再次读取数据，客户端在得到 Watch 消息之前肯定不可能看到更新后的数据
顺序性
如果多个更新触发了多个 Watch ，那 Watch 被触发的顺序与更新顺序一致
0 条评论
回复 删除
下一页
