A-3：ZAB(zookeeper原子广播协议)

一、ZAB(zookeeper原子广播协议)

ZAB协议是专门为Zookeeper设计的一种支持崩溃恢复的原子广播协议，因为当ZAB协议中的Leader角色崩溃时，ZAB协议中有Leader重新选举功能。

二、ZAB协议中的角色

01 Leader(领导者)：

事务请求的唯一处理者，负责发出事务Proposal，也可以处理客户端的读请求

02 Follower(跟随者)：

对Leader发出的事务Proposal具有投票权，将客户端写的事务请求转发给Leader，处理客户端的读请求，并且可以参与Leader的选择

03 Observer(观察者)：

用于提高Follower的读性能，当读请求并发量上来的时候，Observer可以分担一部分的读请求，有人可能会这么想，我们也可以增加Follower节点的数量，来扛住并发量，如果我们一旦增加Follower节点数量的话，那么事务Proposal(提案)的投票表决和Leader的选举的效率就会降低。Observer不参与Leader的选举

ZAB协议类似于Paxos算法，是一种Paxos算法在工业上的实现。

三、ZAB协议的两种基本模式

3.1 [消息广播模式]

消息广播类似于一个二阶段提交过程。Zookeeper使用一个单一的主进程来接收并处理客户端的所有事务请求，此消息广播协议基于FIFO队列，将需要广播的事务Proposal(提案)依次放入队列中，采用TCP通信。

3.1.1 广播过程

① Leader发送事务提案(proposal)

针对客户端的事务请求，Leader服务器会为其生成对应的事务Proposal，并为该事务Proposal分配一个全局递增的唯一ZXID，ZXID由64位组成，其中高32位表示epoch(每个Leader的周期，年号)，低32位表示xid事务id，然后将事务Proposal发送给Follower进行投票表决

② Follower接收提案并响应ACK

Follower接受到了事务Proposal请求后，并会对其进行投票，返回ACK响应。

③ Leader广播Commit消息

如果Leader收到半数以上的ACK响应后，就会广播一个Commit消息给Follower通知其进行事务提交

3.1.2 [崩溃恢复]出现的契机

在消息广播的过程中，可能会出现Leader崩溃的场景，因此ZAB协议中添加了崩溃恢复模式来解决这个问题，像之前说的2PC和3PC，包括Paxos算法都不存在崩溃恢复模式

3.2 [崩溃恢复模式]

以前说到如果在消息广播模式中，如果一旦出现Leader服务器崩溃，那么就会进入到崩溃恢复模式，在ZAB协议中，为了保证程序的正常运行，需要重新在Follower中选举一个新的Leader

3.2.1 Leader选举两个场景

一个是服务器初始化启动，另一个是Leader服务器崩溃。

3.2.2 looking状态

当需要在集群中选举一个Leader，这种选举状态被称为"LOOKING"，当服务器处于LOOKING状态的时候，那么它就会向集群中所有机器发送消息，称这个消息为"投票"。

3.2.3 服务器SID与事务ZXID

消息包含两个基本信息：所举荐服务器的SID和ZXID，投票信息就是(<SID>,<ZXID>)， 分别表示服务器唯一标识和事务ID。SID是在启动zookeeper进行设置的myid。

3.2.4 选举规则

首先会选举ZXID最大的服务器称为Leader，因为ZXID峰值代表事务是最新的，数据是最新的，如果ZXID相等的话，那么SID较大的服务器就会成为Leader

3.2.5 选举投票过程

① 假设三台服务器投票信息为：(1, 9), (2, 8), (3, 8)SID分别是 1, 2, 3；ZXID分别是 9, 8, 8。在第一次投票的时候，都会投票给自己，再将自己的投票信息分别发送给其他机器。

② 当机器1接收到另外两台机器发送过来的投票信息(2, 8), (3, 8)，发现他们的ZXID都没有自己的ZXID=9大，那么不会修改投票结果，坚持投票给自己

③ 当机器2接受到(1, 9), (3, 8)时，假设先收到(3, 8)，发现它的ZIXD跟自己的ZXID=8相等，然后就会比较SID，发现它的SID比自己的SID=2大，那么就会投票给机器3了，后面再接受到了(1, 9)发现比机器3的ZXID=8要大，后面又会修改投票结果，将投票投给机器1

④ 当机器3接受到(1, 9), (2, 8)，假如先收到(2, 8)，发现它的ZXID跟自己的ZXID=8相等，然后比较SID，发现比自己的小，那么不会修改自己的投票结果，坚持投票给自己，后面再接受到了(1, 9)发现比自己的ZXID=8要大，后面又会修改投票结果，将投票投给机器1

⑤ 最后，三台都投给机器1，获得的投票数超过了半数，即机器1就会当选为Leader服务器

3.2.6 数据同步

崩溃恢复模式中，当Leader选举完成之后，要进行数据同步，因为事务日志可能存在还没有被提交的事务，即是否完成数据同步。

3.2.7 同步过程

① 首先Leader服务器会首先确认事务日志中的所有Proposal是否都已经被集群中过半的机器提交了

② 如果没有的话，Leader服务器会向那么没有被Follower服务器同步的事务以Proposal消息的形式逐个发送给Follower服务器，并在每一个Proposal消息后面紧接着再发送一个Commit消息，表示该事务已经被提交

③ 等到Follower服务器将所有尚未同步的事务Proposal同步过来成功应用到本地数据库后，Leader服务器就可以接受客户端的事务请求了，然后提出新的提案了

四、ZAB与Paxos总陈

总的来说，ZAB协议提交事务提案的过程跟Paxos有点类似，都是由Leader发送给下面的Follower，让Follower进行投票表决，都是超过半数以上才会通过。但是ZAB协议比Paxos多的是崩溃恢复模式，也就是Leader崩溃时，能够自我恢复。所以ZAB协议跟Paxos算法最主要的区别就是：两个设计的目标不同，ZAB协议主要用于构建一个高可用的分布式数据的主备系统，因为有崩溃恢复，Leader崩溃能够重新选举，达到一个高可用的目的。而Paxos算法目的在于构建一个分布式数据一致性系统，强调的是数据的一致性，当Proposer提议者崩溃时不能自我恢复，从而丢失高可用的功能