上篇文章paxos与一致性说到zab是在paxos的基础上做了重要的改造,解决了一系列的问题,这一篇我们就来说下这个zab。
zab协议的全称是ZooKeeper Atomic Broadcast即zookeeper“原子”“广播”协议。它规定了两种模式:崩溃恢复和消息广播
恢复模式什么时候进入?
当整个服务框架在启动过程中
当Leader服务器出现网络中断崩溃退出与重启等异常情况
当有新的服务器加入到集群中且集群处于正常状态(广播模式),新服会与leader进行数据同步,然后进入消息广播模式
这三种情况ZAB都会进入恢复模式
干了什么?
选举产生新的Leader服务器,同时集群中已有的过半的机器会与该Leader完成状态同步,这些工作完成后,ZAB协议就会退出崩溃恢复模式
广播模式什么时候进入?
集群状态稳定,有了leader且过半机器状态同步完成,退出崩溃恢复模式后进入消息广播模式
干了什么?
正常的消息同步,把日常产生数据从leader同步到learner的过程
总结一下zab协议规定的两种模式在实际操作中经历了三个步骤,如上图,下面我再详细地说下这两个过程都干了些什么
1.崩溃恢复状态 - 即选主过程进入崩溃恢复模式说明集群目前是存在问题的了,那么此时就需要开始一个选主的过程。
zookeeper使用的默认选主算法是FastLeaderElection,它是标准的Fast Paxos算法实现,可解决LeaderElection选举算法收敛速度慢的问题(上篇文章也有提到过)。
zab协议规定的状态LOOKING 当前集群没有leader,准备选举
FOLLOWING 已经存在leader,当前服务器为跟随者
LEADING 唯一的领导,维护与Follower间的心跳
OBSERVING 观察者状态。表明当前服务器角色是Observer
投票流程
投票的依据投票的依据就是下面的两个id,投票即是给所有服务器发送(myid,zxid)信息
myid:用户在配置文件中自己配置,每个节点都要配置的一个唯一值,从1开始往后累加。
zxid:zxid有64位,分成两部分:
高32位是Leader的epoch:选举时钟,每次选出新的Leader,epoch累加1
低32位是在这轮epoch内的事务id:对于用户的每一次更新操作集群都会累加1。
注意:zk把epoch和事务id合在一起,每次epoch变化,都将低32位的序号重置,这样做是为了方便对比出最新的数据,保证了zxid的全局递增性。(其实这样也会存在问题,虽然概率小,这里就先不说了后面的文章会详细讲)。
关于发送选票第一轮投给自己,之后每个服把上述所有信息发送给其他所有服,票箱中只会记录每一投票者的最后一票
关于接收投票服务器会尝试从其它服务器获取投票,并记入自己的投票箱内。如果无法获取任何外部投票,则会确认自己是否与集群中其它服务器保持着有效连接。如果是,则再次发送自己的投票;如果否,则马上与之建立连接。
关于选举轮次由于所有有效的投票都必须在同一轮次中。每开始新一轮投票自身的logicClock自增1。
接收到的logicClock大于自己的。说明自己落后了,更新logicClock后正常。
接收到的logicClock小于自己的。忽略该票。
接收到的logickClock与自己的相等,正常判断。
关于选票判断对比自身的和接收到的(myid,zxid)
首先对比zxid高32位的选举时钟epoch
一致则对比zxid低32的事务id
仍然一致则对比用户自己配置的myid
选完后广播选出的(myid,zxid)
关于选举结束
过半服务器选了同一个,则投票结束,根据投票结果更新自身状态为leader或者follower
上面说过zookeeper是一个原子广播协议,在这个崩溃恢复的过程就体现了它的原子性,zookeeper在选主过程保证了两个问题:
commit过的数据不丢失
未commit过的数据丢弃
(myid,zxid)的选票设计刚好解决了这两个问题。
commit过的数据半数以上参加选举的follwer都有,而且成为leader的条件是要有最高事务id即数据是最新的。
未commit过的数据只存在于leader,但是leader宕机无法参加首轮选举,epoch会小一轮,最终数据会丢弃。
2.消息广播状态 - 即数据同步如上图,client端发起请求,读请求由follower和observer直接返回,写请求由它们转发给leader。
Leader 首先为这个事务分配一个全局单调递增的唯一事务ID (即 ZXID )。