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

Posted owenzhang

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了十分钟了解ZAB(Zookeeper Atomic Broadcast)协议相关的知识,希望对你有一定的参考价值。

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 如果比本地投票轮数的大

 
   
   
 
  1. 证明自己投票过期了,清空本地投票信息,

  2. 更新投票轮数和结果为收到的内容。

  3. 通知其他所有节点新的投票方案。

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

 
   
   
 
  1. 2.3.1 如果收到的优先级大,

  2. 更新自己的投票为对方发过来投票方案,把投票发出去。

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

  4. 2.3.3 如果收到的优先级相等,

  5. 则更新对应节点的投票。

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顺序,保证了能够有优先级最高的节点当主。主从同步通过提议和提交两个阶段,有超过一半的节点写成功,则认为数据写成功。



欢迎关注



以上是关于十分钟了解ZAB(Zookeeper Atomic Broadcast)协议的主要内容,如果未能解决你的问题,请参考以下文章

zookeeper-非常重要的zab协议-《每日五分钟搞定大数据》

了解zookeeper

了解zookeeper

面试官:说一下Zookeeper的ZAB协议?

Zookeeper02——ZAB协议及选主流程

面试官:说一下Zookeeper的ZAB协议?敖丙:不好意思我肚子疼!