十分钟了解ZAB(Zookeeper Atomic Broadcast)协议

栏目: 编程工具 · 发布时间: 6年前

内容简介:Zookeeper基于ZAB(Zookeeper Atomic Broadcast),实现了主备模式下的系统架构,保持集群中各个副本之间的数据一致性。ZAB协议定义了选举(election)、发现(discovery)、同步(sync)、广播(Broadcast)四个阶段。选举(election)是选出哪台为主机;

Zookeeper基于ZAB(Zookeeper Atomic Broadcast),实现了主备模式下的系统架构,保持集群中各个副本之间的数据一致性。

ZAB协议定义了选举(election)、发现(discovery)、同步(sync)、广播(Broadcast)四个阶段。

选举(election)是选出哪台为主机;

发现(discovery)、同步(sync)当主选出后,要做的恢复数据的阶段;

广播(Broadcast)当主机和从选出并同步好数据后,正常的主写同步从写数据的阶段。

下面简单地介绍下ZAB协议,目的是能够快速了解其精髓,快速掌握ZAB协议。然后通过论文了解具体协议的细节。主要介绍选举和广播两个阶段。

基本概念

我们了解下zk的一些基本概念。

zk集群有三种角色:

– leader 就是我们说的主;

– follower 就是我们说的从;

– observer 可以认为是主的clone copy,不参与投票,本文可忽略;

zk集群的一个节点,有三种状态:

– looking 选举状态,当前群龙无首;

– leading leader才有的状态;

– following follower才有的状态;

每次写成功的消息,都有一个全局唯一的标识,叫zxid。是64bit的正整数,高32为叫epoch表示选举纪元,低32位是自增的id,每写一次加一。

可以想象为中国古代的年号,例如万历十五年,万历是epoch,十五年是id。

zk集群一般都是奇数个机器(2n+1),只有一个主机leader,其余都是从机follower。选主还是写数据,要有>=n+1台选举相同,才能执行选举的操作。

投票优先级:优先比较zxid,如果相等,再比较机器的id,都按从大到小的顺序。

选举

当集群新建,或者主机死机,或者主机与一半或以上的从机失去联系后,都会触发选择新的主机操作。有两种算法 fast paxosbasic paxos

fast paxos

默认ZAB采用的算法是fast paxos算法。

每次选举都要把选举轮数加一,类似于zxid里的epoch字段,防止不同轮次的选举互相干扰。

每个进入looking状态的节点,最开始投票给自己,然后把投票消息发给其它机器。内容为 <第几轮投票,被投节点的zxid,被投节点的编号>

其他looking状态的节点收到后,

1 首先判断票是否有效。

是否有效的方法为看票的投票轮数和本地记载的投票轮数是否相等:

2.1 如果比本地投票轮数的小,丢弃。

2.2 如果比本地投票轮数的大

证明自己投票过期了,清空本地投票信息,
更新投票轮数和结果为收到的内容。
通知其他所有节点新的投票方案。

2.3 如果和本地投票轮数相等,按照投票的优先级比较收到的选票和自己投出去的选票。

2.3.1 如果收到的优先级大,
更新自己的投票为对方发过来投票方案,把投票发出去。

2.3.2 如果收到的优先级小,则忽略该投票。

2.3.3 如果收到的优先级相等,
则更新对应节点的投票。

3 每收集到一个投票后,查看已经收到的投票结果记录列表,看是否有节点能够达到一半以上的投票数。如果有达到,则终止投票,宣布选举结束,更新自身状态。然后进行发现和同步阶段。

否则继续收集投票。

basic paxos

1 每个looking节点先发出请求,询问其他节点的投票。

其他节点返回自己的投票 < zk的id,zxid >。第一次都投自己。

2 收到结果后,如果收到的投票比自己投票的zxid大,更新自己的投票。

3 当收到所有节点返回后,统计投票,有一个节点的选举达到一半以上,则选举成功。

否则继续开始下一轮询问,直到选择出leader结束。

basic paxos和fast paxos区别

这里fast是主动推送出,只要结果有更新,就马上同步给其他节点。其他节点可能还没把自己的票通知给所有节点,就发现自己投的票优先级低,要更新投票,然后更新再重新通知给所有节点。

basic则要每一节点都询问完,才能知道新结果,然后再去问其他节点新的选举结果。

fast比basic快的地方,是一个节点,不用和每个节点都交换投票信息后,才能知道自己的票是否要更新。会减少交互次数。

广播——主从同步

主从同步数据比较简单,

当有写操作时,如果是从机接收,会转到主机。做一次转发,保证写都是在主机上进行。

主先提议事务,收到过半回复后,再发提交。

主收到写操作时,先本地生成事务为事务生成zxid,然后发给所有follower节点。

当follower收到事务时,先把提议事务的日志写到本地磁盘,成功后返回给leader。

leader收到过半反馈后对事务提交。再通知所有的follower提交事务,follower收到后也提交事务,提交后就可以对客户端进行分发了。

总结

通过只有主控制写然后同步从,保证了生成全局zxid不冲突。全局唯一的zxid能够给选举和同步数据区分出优先级。

选举主部分了解fast paxos原理即可。

核心思想是 递增的zxid顺序,保证了能够有优先级最高的节点当主。

主从同步通过 提议和提交两个阶段 ,有超过一半的节点写成功,则认为数据写成功。


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

微信力量

微信力量

谢晓萍等著 / 机械工业出版社华章公司 / 2015-10-28 / 59.00

微信俨然已进化为一种万能的连接器,拥有连接一切的能力,彰显出强大的连接力,无处不在,无所不能。本书将为你讲述连接为何能产生如此巨大的力量,这股力量正在商业和民生领域产生的变化,将为你展现微信生态进化的全景世界。 连接即入口,微信上的每一次有效的连接都会形成有效的入口。本书详细讲解了如何通过微信帮助餐饮、酒店、医院、零售、商场、电气、母婴、航空、客运、停车场、商圈、城市服务等数十个传统行业与它......一起来看看 《微信力量》 这本书的介绍吧!

HTML 压缩/解压工具
HTML 压缩/解压工具

在线压缩/解压 HTML 代码

图片转BASE64编码
图片转BASE64编码

在线图片转Base64编码工具

RGB CMYK 转换工具
RGB CMYK 转换工具

RGB CMYK 互转工具