Zab(Zookeeper Atomic Broadcast)协议

一、什么是 Zab协议


Zab( Zookeeper Atomic Broadcast:Zookeeper原子广播)Zookeeper 通过 Zab 协议保证分布式事务的最终一致性。
【1】Zab协议是为分布式协调服务 Zookeeper专门设计的,是 Zookeeper保证数据一致性的核心算法。Zab借鉴了 Paxos算法,但又不像 Paxos那样,是一种通用的分布式一致性算法。支持崩溃恢复 和 原子广播协议。
【2】在 Zookeeper中主要依赖 Zab协议来实现数据一致性,基于该协议,zk实现了一种主备模型(即 LeaderFollower模型)的系统架构来保证集群中各副本之间数据的一致性。主备系统架构模型指只有一台客户端(Leader)负责处理外部的写事务请求,然后 Leader客户端将数据同步到其他 Follower节点。

Zookeeper 客户端会随机的连接到 Zookeeper 集群中的一个节点,如果是读请求,就直接从当前节点中读取数据;如果是写请求,那么节点就会向 Leader 提交事务,Leader 接收到事务提交,会广播该事务,只要超过半数节点写入成功,该事务就会被提交
Zab(Zookeeper Atomic Broadcast)协议Zab(Zookeeper Atomic Broadcast)协议

就这样,客户端发送来的写请求,全部给 Leader,然后 Leader再转给 Follower。这时候需要解决两个问题:
【1】Leader服务器是如何把数据更新到所有的 Follower的;
【2】Leader服务器突然间失效了,怎么办?
因此 ZAB协议为了解决上面两个问题,设计了两种模式:
【1】消息广播模式:把数据更新到所有的 Follower;
【2】崩溃恢复模式:Leader发生崩溃时,如何恢复;

二、消息广播模式


在 Zookeeper集群中数据副本的传递策略就是采用消息广播模式。如果你了解 2PC协议的话,理解起来就简单很多了,消息广播的过程实际上是一个简化版本的二阶段提交过程。与二阶段提交相似但是却又不同。二阶段提交的要求协调者必须等到所有的参与者全部反馈 ACK确认消息后,再发送 commit消息。要求所有的参与者要么全部成功要么全部失败。二阶段提交会产生严重阻塞问题。我们来看一下 ZAB的这个过程:ZAB协议中 Leader等待 Follower的 ACK反馈是指 “只要半数以上的Follower成功反馈即可,不需要收到全部 Follower反馈”
Zab(Zookeeper Atomic Broadcast)协议
【1】Leader将客户端的 Request转化成一个 Proposal(提议)。同时为每个 proposal分配一个全局唯一ID,即ZXID;
【2】Leader节点再数据写完之后,将向所有的 Follower节点发送数据广播请求(或数据复制),等待所有的 Follower节点反馈。Leader为每一个 Follower准备了一个 FIFO队列,并把 Proposal(带有 zxid的消息)发送到队列上;
【3】Follower从队列中取出消息处理完(写入本地事物日志中或将 proposal写到磁盘)后,向 Leader服务器发送 ACK确认。Leader若收到 Follower的半数以上 ACK反馈。Leader就会向所有的 Follower发送 commit。即将 Leader节点上的数据同步到 Follower节点之上;
Zab(Zookeeper Atomic Broadcast)协议

Leader服务器与每个 Follower之间都有一个单独的队列进行收发消息,使用队列消息可以做到异步解耦。Leader和 Follower之间只要往队列中发送了消息即可。如果使用同步方式容易引起阻塞。性能上要下降很多。

三、崩溃恢复模式


当整个集群正在启动时,或者当 Leader节点出现网络中断、崩溃等情况时,ZAB协议就会进入恢复模式并选举产生新的 Leader,当 Leader服务器选举出来后,并且集群中有过半的机器和该 Leader节点完成数据同步后(同步指的是数据同步,用来保证集群中过半的机器能够和 Leader服务器的数据状态保持一致),ZAB协议就会退出恢复模式。

当集群中已经有过半的 Follower节点完成了和 Leader状态同步以后,那么整个集群就进入了消息广播模式。这个时候,在 Leader节点正常工作时,启动一台新的服务器加入到集群,那这个服务器会直接进入数据恢复模式,和 Leader节点进行数据同步。同步完成后即可正常对外提供非事务请求的处理。
【1】Zookeeper集群中为保证所有进程能够有序的顺序执行,只能是 Leader服务器接受写请求,即使是 Follower服务器接受到客户端的请求,也会转发到 Leader服务器进行处理。
【2】如果 Leader服务器发生崩溃,则 zab协议要求 Zookeeper集群进行崩溃恢复和 Leader服务器选举。

ZAB协议崩溃恢复要求满足如下2个要求:
【1】已经被处理的消息不能丢失**:**当 Leader收到合法数量 Follower的 ack后,就向各个 Follower广播 commit命令,同时也会在本地执行 commit并向连接的客户端返回「成功」。但是如果各个 Follower在收到 commit命令前 Leader就挂了,导致剩下的服务器并没有执行到这条消息。
Zab(Zookeeper Atomic Broadcast)协议
Leader对事务消息发起 commit操作,该消息在 Follower1上执行了,但是 Follower2还没有收到commit,Leader就已经挂了,而实际上客户端已经收到该事务消息处理成功的回执了。所以在 zab协议下需要保证所有机器都要执行这个事务消息,必须满足已经被处理的消息不能丢失。
【2】被丢弃的消息不能再次出现:当 Leader接收到消息请求生成 proposal后就挂了,其他 Follower并没有收到此proposal,因此经过恢复模式重新选了 Leader后,这条消息应跳过。 此时,之前挂了的 Leader重新启动并注册成了 Follower,他保留了被跳过消息的proposal状态,与整个系统的状态是不一致的,需要将其删除。(Leader都换代了,所以以前 Leader的 proposal失效了)。

针对崩溃恢复的两种情况分析:ZAB协议需要满足上面两种情况,就必须要设计一个 Leader选举算法,能够确保已经被 Leader提交的事务 Proposal能够提交、同时丢弃已经被跳过的事务Proposal。如果 Leader选举算法能够保证新选举出来的 Leader服务器拥有集群中所有机器最大 ZXID编号****的事务Proposal,那么就可以保证这个新选举出来的 Leader一定具有已经提交的提案。因为所有提案被 commit之前必须有超过半数的 Follower ack,即必须有超过半数节点的服务器的事务日志上有该提案的 Proposal,因此只要有合法数量的节点正常工作,就必然有一个节点保存了所有被 commit消息的 Proposal状态。

另外一个,zxid是64位,高32位是epoch编号,每经过一次 Leader选举产生一个新的 Leader,新的 Leader会将 epoch号+1,低32位是消息计数器,每接收到一条消息这个值+1,新 Leader选举后这个值重置为0。这样设计的好处在于老的 Leader挂了以后重启,它不会被选举为 Leader,因此此时它的 zxid肯定小于当前新的 Leader。当老的 Leader作为 Follower接入新的 Leader后,新的 Leader会让它将所有的拥有旧的 epoch号的未被 commit的 Proposal清除。

Leader服务器发生崩溃时分为如下场景:
【1】Leader在提出 Proposal时未提交之前崩溃,则经过崩溃恢复之后,新选举的 Leader一定不能是刚才的 Leader。因为这个 Leader存在未提交的 Proposal;
【2】Leader在发送 commit消息之后,崩溃。即消息已经发送到队列中。经过崩溃恢复之后,参与选举的 Follower服务器(刚才崩溃的 Leader有可能已经恢复运行,也属于 Follower节点范畴)中有的节点已经是消费了队列中所有的 commit消息。即该 Follower节点将会被选举为最新的 Leader。剩下动作就是数据同步过程。

四、数据同步


在 Zookeeper集群中新的 Leader选举成功之后,Leader会将自身的提交的最大 Proposal的事务 ZXID发送给其他的 Follower节点。Follower节点会根据 Leader的消息进行回退或者是数据同步操作。最终目的要保证集群中所有节点的数据副本保持一致

数据同步完之后,Zookeeper集群如何保证新选举的 Leader分配的 ZXID是全局唯一呢?这个就要从ZXID的设计谈起。ZXID是一个长度64位的数字,其中低32位是按照数字递增,即每次客户端发起一个 Proposal,低32位的数字简单加1。高32位是 Leader周期的 epoch编号,每当选举出一个新的 Leader时,新的 Leader就从本地事物日志中取出 ZXID,然后解析出高32位的 epoch编号,进行加1,再将低32位的全部设置为0。这样就保证了每次新选举的 Leader后,保证了 ZXID的唯一性而且是保证递增的。
Zab(Zookeeper Atomic Broadcast)协议

五、ZAB协议原理


ZAB协议要求每个 Leader都要经历三个阶段,即发现同步广播
**发现:**要求 zookeeper集群必须选择出一个 Leader,同时 Leader会维护一个 Follower可用列表。客户端可以跟 Follower中的节点进行通信。
**同步:**Leader要负责将本身的数据与 Follower完成同步,做到多副本存储。这样也是体现了 CAP中高可用和分区容错。Follower将队列中未处理完的请求消费完成后,写入本地事物日志中。
**广播:**Leader可以接受客户端新的 proposal请求,将新的 proposal请求广播给所有的 Follower。

上一篇:Paxos算法和Zab协议


下一篇:ZAB协议