ZAB协议介绍2

Zookeeper依赖ZAB协议来实现分布式数据的一致性,其中ZAB协议包括原子广播和崩溃恢复两个阶段。

基于该协议,Zookeeper实现了一种主备模式的系统架构来保持Zookeeper为高可用的一致性协调框架,自然的Zookeeper也有着一致性算法的实现。

Zookeeper使用ZAB协议作为数据一致性的算法,其中ZAB即ZooKeeper Atomic Broadcast 的缩写,其全称为:原子消息广播协议。

ZAB协议可以说是在Paxos算法基础上进行了扩展改造而来的,ZAB协议设计了支持崩溃恢复,Zookeeper使用单一主进程Leader处理客户端所有的事务请求,采用ZAB协议将服务器数状态以事务形式广播到所有Follower上。由于事务间可能存在着依赖关系,ZAB协议保证Leader广播的变更序列被顺序的处理:一个状态被处理后,它所依赖的状态也已经提前被处理;ZAB协议支持的崩溃恢复可以保证在Leader进程崩溃的时候可以重新选出Leader并且保证数据的完整性。

在Zookeeper中所有的事务请求都由一个主服务器也就是Leader节点来处理。其他服务器为Follower节点或者Observer节点,Leader将客户端的事务请求转换为事务Proposal提议,并且将Proposal分发给集群中其他所有的Follower节点,然后Leader等待Follower的反馈,当有过半数(>=N/2+1) 的Follower反馈信息OK后,Leader将再次向集群内所有Follower节点广播Commit提交信息,Commit即为将之前的Proposal提交。


ZAB协议中的状态

ZAB协议中存在着三种状态,每个节点都属于以下三种状态中的一种:

  1. Looking :系统刚启动时或者Leader崩溃后正处于Leader选举状态;
  2. Following :Follower节点所处的状态,Follower与Leader处于数据同步阶段;
  3. Leading :Leader节点所处状态,当前集群中有一个Leader为主进程时的状态;

Zookeeper启动时所有节点初始状态均为Looking,这时集群会尝试选举出一个Leader节点,选举出的Leader节点切会换为Leading状态。当节点发现集群中已经选举出Leader则该节点会切换到Following状态,然后和Leader节点保持同步;当Follower节点与Leader失去联系时Follower节点则会切换到Looking状态,开始新一轮的Leader选举。在ZooKeeper的整个生命周期中每个节点都会在Looking、Following、Leading状态间不断转换。

image

ZAB协议中状态切换

选举出Leader节点后,ZAB协议将进入原子广播阶段,这时Leader节点会为和自己同步的每个Follower节点创建一个操作序列。在一个周期内,每个Follower节点只能和一个Leader节点保持同步,Leader节点与Follower节点使用心跳检测来感知对方的存在。当Leader节点在超时时间内收到来自Follower的心跳检测,那么Follower节点就会一直与该节点保持连接;若超时时间内Leader节点没有接收到来自过半Follower节点的心跳检测或者TCP连接断开,那么Leader节点就会结束当前周期的领导,同时切换到Looking状态。所有Follower节点也会放弃该Leader节点,同时切换到Looking状态,然后开始新一轮Leader选举。


ZAB协议中的各个阶段

ZAB协议定义了:选举(election)、发现(discovery)、同步(sync)、广播(Broadcast) 四个阶段。ZAB协议选举(election)时,当Follower存在ZXID(事务ID)时判断所有Follower节点的事务日志,只有last ZXID的节点才有资格成为Leader,这种情况下选举出来的Leader总有最新的事务日志,基于这个原因,Zookeeper实现的时候把发现(discovery)与同步(sync)合并为恢复(recovery) 阶段。

  1. Election(选举) :在Looking状态中选举出Leader节点,Leader的lastZXID总是最新的;

  2. Discovery (发现):Follower节点向准Leader推送FOllOWERINFO,该信息中包含了上一周期的epoch,接受准Leader的NEWLEADER指令,检查newEpoch有效性,准Leader要确保Follower的epoch与ZXID小于或等于自身的;

  3. Sync (同步):将Follower与Leader的数据进行同步,由Leader发起同步指令,最总保持集群数据的一致性;

  4. Broadcast (广播):Leader广播Proposal与Commit,Follower接受Proposal与Commit;

  5. Recovery (恢复):在Election阶段选举出Leader后本阶段主要工作就是进行数据的同步,使Leader具有highestZXID,集群保持数据的一致性;


  1. 选举(Election)

选举(election)的阶段必须确保选出的Leader具有highest的ZXID,否则在Recovery阶段没法保证数据的一致性,Recovery阶段Leader要求Follower向自己同步数据没有Follower要求Leader保持数据同步,所有选举出来的Leader要具有最新的ZXID;

在选举的过程中会对每个Follower节点的ZXID进行对比只有highest的ZXID的Follower才可能当选为Leader;

选举流程:
  1. 每个Follower都向其他节点发送选自身为Leader的Vote投票请求,等待回复;

  2. Follower接受到的Vote如果比自身的大(ZXID更新)时则投票,并更新自身的Vote,否则拒绝投票;

  3. 每个Follower中维护着一个投票记录表,当某个节点收到过半的投票时,结束投票并把该Follower选为Leader,投票结束;

ZAB协议中使用ZXID作为事务编号,ZXID为64位数字,低32位为一个递增的计数器,每一个客户端的一个事务请求时Leader产生新的事务后该计数器都会加1,高32位为Leader周期epoch编号,当新选举出一个Leader节点时Leader会取出本地日志中最大事务Proposal的ZXID解析出对应的epoch把该值加1作为新的epoch,将低32位从0开始生成新的ZXID;ZAB使用epoch来区分不同的Leader周期。

恢复(Recovery)

在election阶段选举出来的Leader已经具有最新的ZXID,所有本阶段的主要工作是根据Leader的事务日志对Follower节点数据进行更新;

Leader:Leader生成新的ZXID与epoch,接收Follower发送过来的FOllOWERINFO(含有当前节点的Last的ZXID)然后往Follower发送NEWLEADER;Leader根据Follower发送过来的LastZXID根据数据更新策略向Follower发送更新指令。

同步策略:
  1. SNAP :如果Follower数据太老,Leader将发送快照SNAP指令给Follower同步数据;
  2. DIFF :Leader发送从Follower.lastZXID到Leader.lastZXID议案的DIFF指令给Follower同步数据;
  3. TRUNC :当Follower.lastZXID比Leader.lastZXID大时,Leader发送从Leader.lastZXID到Follower.lastZXID的TRUNC指令让Follower丢弃该段数据;

Follower:往Leader发送FOLLOWERINFO指令,Leader拒绝就转到Election阶段;接收Leader的NEWLEADER指令,如果该指令中epoch比当前Follower的epoch小那么Follower转到Election阶段;Follower还有主要工作是接收SNAP/DIFF/TRUNC指令同步数据与ZXID,同步成功后回复ACKNETLEADER,然后进入下一阶段;Follower将所有事务都同步完成后Leader会把该节点添加到可用Follower列表中;

SNAP与DIFF用于保证集群中Follower节点已经Committed的数据的一致性,TRUNC用于抛弃已经被处理但是没有Committed的数据;

广播(Broadcast)

客户端提交事务请求时,Leader节点为每一个请求生成一个事务Proposal,将其发送给集群中所有的Follower节点,收到过半Follower的反馈后开始对事务进行提交,ZAB协议使用了原子广播协议;在ZAB协议中只需要得到过半的Follower节点反馈Ack就可以对事务进行提交,这也导致了Leader节点崩溃后可能会出现数据不一致的情况,ZAB使用了崩溃恢复来处理数字不一致问题;消息广播使用了TCP协议进行通讯所有保证了接受和发送事务的顺序性。广播消息时Leader节点为每个事务Proposal分配一个全局递增的ZXID(事务ID),每个事务Proposal都按照ZXID顺序来处理;

Leader节点为每一个Follower节点分配一个队列,按事务ZXID顺序放入到队列中,且根据队列的规则FIFO来进行事务的发送。Follower节点收到事务Proposal后会将该事务以事务日志方式写入到本地磁盘中,成功后反馈Ack消息给Leader节点,Leader在接收到过半Follower节点的Ack反馈后就会进行事务的Commit提交,与此同时向所有的Follower节点广播Commit消息,Follower节点收到Commit后开始对事务进行提交。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,905评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,140评论 2 379
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,791评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,483评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,476评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,516评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,905评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,560评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,778评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,557评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,635评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,338评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,925评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,898评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,142评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,818评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,347评论 2 342

推荐阅读更多精彩内容