内容简介: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 paxos
和 basic 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顺序,保证了能够有优先级最高的节点当主。
主从同步通过 提议和提交两个阶段 ,有超过一半的节点写成功,则认为数据写成功。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 你了解HTTPS,但你可能不了解X.509
- 你真的了解Mybatis的${}和#{}吗?是否了解应用场景?
- 你所了解的 array_diff_uassoc 真的是你了解的那样吗?
- 图文了解 Kubernetes
- 深入了解 JSONP
- 一文了解 Kubernetes
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。