Zab(Zookeeper Atomic Broadcast)是为ZooKeeper协设计的崩溃恢复原子广播协议,它保证zookeeper集群数据的一致性和命令的全局有序性。
在介绍zab协议之前首先要知道zookeeper相关的几个概念,才能更好的了解zab协议。
可以知道Zookeeper是通过自身的状态来区分自己所属的角色,来执行自己应该的任务。
ZAB状态Zookeeper还给ZAB定义的4中状态,反应Zookeeper从选举到对外提供服务的过程中的四个步骤。状态枚举定义:
public enum ZabState {
ELECTION,
DISCOVERY,
SYNCHRONIZATION,
BROADCAST
}
ZXID
Zxid是极为重要的概念,它是一个long型(64位)整数,分为两部分:纪元(epoch)部分和计数器(counter)部分,是一个全局有序的数字。
epoch代表当前集群所属的哪个leader,leader的选举就类似一个朝代的更替,你前朝的剑不能斩本朝的官,用epoch代表当前命令的有效性,counter是一个递增的数字。
基础概念介绍完了,下面开始介绍zab协议是怎么支持leader选举的。
进行leader有三个问题,什么时候进行?选举规则?选择流程?
下面我会一一解答这三个问题:
/*
* We return true if one of the following three cases hold:
* 1- New epoch is higher
* 2- New epoch is the same as current epoch, but new zxid is higher
* 3- New epoch is the same as current epoch, new zxid is the same
* as current zxid, but server id is higher.
*/
return ((newEpoch > curEpoch)
|| ((newEpoch == curEpoch)
&& ((newZxid > curZxid)
|| ((newZxid == curZxid)
&& (newId > curId)))));
当其他节点的纪元比自身高时,如果纪元相同比较自身的zxid的大小,选举zxid大的节点,这里的zxid代表节点所提交事务最大的id,zxid越大代表该节点的数据越完整。
最后如果epoch和zxid都相等,则比较服务的serverId,这个Id是配置zookeeper集群所配置的,所以我们配置zookeeper集群的时候可以把服务性能更高的集群的serverId配置大些,让性能好的机器担任leader角色。
时机和规则都有了,下面就是leader的选举流程:
4..举例
上图来自《ZooKeeper:分布式过程协同技术详解》,整体流程还是比较简单,这里就不具体分析了。
集群在经过leader选举之后还会有连接leader和同步两个步骤,这里就不具体分析这两个步骤的流程了,主要介绍集群对外提供服务如何保证各个节点数据的一致性。
zab在广播状态中保证以下特征
有序性是zab协议必须要保证的一个很重要的属性,因为zookeeper是以类似目录结构的数据结构存储数据的,必须要求命名的有序性。
比如一个命名a创建路径为/test,然后命名b创建路径为/test/123,如果不能保证有序性a命名在b之前,b命令会因为父节点不存在而创建失败。
如上图所示,整个写请求类似一个二阶段的提交。
当收到客户端的写请求的时候会经历以下几个步骤:
有以上流程可知,zookeeper通过二阶段提交来保证集群中数据的一致性,因为只需要收到过半的ACK就可以提交事务,所以zookeeper的数据并不是强一致性。
zab协议的有序性保证是通过几个方面来体现的,
第一是,服务之前用TCP协议进行通讯,保证在网络传输中的有序性;
第二,节点之前都维护了一个FIFO的队列,保证全局有序性;
第三,通过全局递增的zxid保证因果有序性。
前面介绍了zookeeper服务状态有四种,ZAB状态也有四种。这里就简单介绍一个他们之间的状态流转,更能加深对zab协议在zookeeper工作流程中的作用。
可以知道整个zookeeper服务的工作流程类似一个状态机的转换,而zab协议就是驱动服务状态流转的关键,理解了zab就理解了zookeeper工作的关键原理
本文对zab协议在zookeeper的工作流程中做了简单的介绍,希望对大家理解学习zookeeper有所帮助。