zookeeper使用zab协议来保持集群数据的一致性
zab协议可以认为是一种二段提交协议
主要由两部分组成:崩溃恢复和消息广播,具体过程为
选主 -> 数据同步 -> 广播
消息广播阶段主要完成leader结点向follower结点同步日志,过程如下
1 client发起写请求
2 leader封装写请求为proposal,向follower预写请求
3 leader收到follower返回半数以上的预写请求确认,commit该日志
4 leader向客户端返回成功
5 follower同步leader已提交的日志
PS:只有leader能够处理写请求,follower收到写请求会重定向给leader
崩溃恢复阶段主要进行选主和数据同步
zookeeper中节点有leader和follower两种角色
每个节点有四种状态:LOOKING,FOLLOWING, LEADING, OBSERVING
LOOKING:选主状态
FOLLOWING:following状态
LEADING:leading状态
OBSERVING:观察状态
PS: OBSERVING主要用于集群扩容,不再讨论范围
leader、follower之间通过心跳机制维护状态
当感知leader挂掉之后,follower进入LOOKING状态
follower生成选主请求,投自己一票,然后向其余follower节点发送选主请求,如果收到一半以上的成功回复,则竞选成功
选主请求主要由两部分数据组成:MYID和ZXID
MYID:配置的节点ID
ZXID:64位事务ID,低32位为递增计数,高32位为集群事务ID,依次递增
其他follower接收到选主请求后,会依次比较请求的ZXID和MYID,给数值大者投票
以5结点的集群的启动选主为例,依次启动1、2、3、4、5结点,3结点会成为leader
原因是启动时ZXID一致,3节点正好能够获取超过一般的票数,后续的4、5启动时发现3已经是leader
当完成选主之后,leader便进入数据同步阶段
数据同步阶段主要工作是follower进行与leader之间的差异同步
考虑异常情况:
1 事务在leader上提交,且接收到follower的ACK,但leader发commit消息前崩溃
2 事务在leader上提出,leader崩溃
zab通过两个约束来保持一致性:
1 确保已经提交的日志必须被所有的follower提交
2 确保只丢弃未被leader提交的日志
从而,zab选举出的leader
1 不包含未提交的日志
leader必须都是已经提交了proposal的follower服务器节点
2 新leader含有最高的ZXID
数据同步阶段,leader将自身提交的最大事务ZXID发送给follower,follower根据leader的消息进行回退或者数据同步,保证与leader数据的一致
页面更新:2024-06-05
本站资料均由网友自行发布提供,仅用于学习交流。如有版权问题,请与我联系,QQ:4156828
© CopyRight 2020-2024 All Rights Reserved. Powered By 71396.com 闽ICP备11008920号-4
闽公网安备35020302034903号