【Zookeeper】集群模式：数据一致性保证 --ZAB 协议

冷不防 2022-12-20 11:19 229阅读 0赞

ZAB（Zookeeper Atomic Broadcast） 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的**数据一致性**。

ZAB协议包括两种基本模式，分别是：崩溃恢复和消息广播。

*  **崩溃恢复**：当整个集群在启动时，或者 leader 节点出现网络中断、 崩溃等情况时，ZAB 协议就会进入崩溃恢复模式

> 崩溃恢复->消息广播：和leader 节点进行数据同步。同步完成后即可正常对外提供非事务请求的处理
> 
> 1.  选举产生新的Leader
> 2.  使集群中有过半的机器和该leader节点完成数据同步（即数据状态一致）

*  **消息广播**：当集群中已经有过半的 Follower 节点完成了和 Leader 状态同步后，那么整个集群就进入了消息广播模式
    
    注：leader结点可以处理事务请求和非事务请求（写），follower结点只能处理非事务请求（读）并转发事务

> 消息广播->崩溃恢复：在Leader节点正常工作时，启动一台新的服务器加入到集群，那这个服务器会直接进入数据恢复模式

另外，每一个对znode树的更新操作，都会被赋予一个全局唯一的ID，我们称之为 **zxid**（ZooKeeper Transaction ID）更新操作的ID按照发生的时间顺序升序排序。例如，z\_\{1\}z1小于z\_\{2\}z2，那么z\_1z1的操作就早于z\_2z2操作。

## 1.消息广播原理 ##

消息广播实际上是一种类2pc协议，即简化版的二阶段提交过程

1).leader 接收到消息请求后，将消息赋予一个全局唯一的 64位自增id(zxid)，将带有zxid 的消息作为一个提案（proposal，包括了事务内容）分发给所有的 follower

> 注：leader为每个follower准备了一个FIFO队列（通过TCP 协议来实现，以实现了全局有序这一个特点）,通过zxid的大小比较即可以实现因果有序这个特征

2).当follower接收到proposal，先把proposal写到磁盘， 写入成功以后再向leader回复一个ack

3).当leader接收到合法数量（超过半数节点）的ACK后， leader就会向这些 follower 发送commit命令，同时会在本地最先执行该提交

> 注：另外小半数可能是因为先后关系，收到Proposal晚，导致发送ACK晚；但leader没必要等慢的到了再决定提交。还有另一种极端情况，follower节点不同意这个Proposal，那么他就会放弃这个leader（退出集群）

4).当 follower 收到消息的 commit命令以后，会提交该消息

画一个图来看的话，以四步分别对应下图的四个箭头：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center]

与完成2PC事务不同之处在于：

*  zab 协议不能终止事务， follower 节点要么 ACK 给 leader ，要么抛弃 leader ，只需要保证过半数的节点响应这个消息并提交了即可
 *  虽然在某一个时刻 follower 节点和 leader 节点的状态会不一致（注：等所有结点都提交后就一致了），但是也是这个特性提升了集群的整体性能。 当然这种数据不一致的问题， zab 协议提供了一种恢复模式来进行数据恢复

这里需要注意的是： leader 的投票过程，不需要 Observer 的 ack，也就是 Observer不需要参与投票过程，但是Observer必须要同步 Leader 的数据从而在处理请求的时候保证数据的一致性

## 2.崩溃恢复原理 ##

上面我们说了，ZAB协议的消息广播机制是简化版本的2PC协议，这种协议只需要集群中过半的节点响应提交即可。但是它无法处理Leader服务器崩溃带来的数据不一致问题。因此在 ZAB 协议中添加了一个“崩溃恢复模式”来解决这个问题。

在正常情况下消息广播是没有问题的，但是一旦Leader节点崩溃，或者由于网络问题导致 Leader 服务器失去了过半的 Follower 节点的联系（leader失去与过半follower节点联系，可能是 leader节点和follower节点之间产生了网络分区，那么此时的leader不再是合法的leader了），那么就会进入到崩溃恢复模式。

### 2.1 新 leader 的两个要求 ###

那么 ZAB 协议中的崩溃恢复需要保证，如果一个事务 Proposal 在一台机器上被处理成功，那么这个事务应该在所有机器上都被处理成功，哪怕是出现故障。为了达到这个目的，我们先来设想一下，在zookeeper中会有哪些场景导致数据不一致性，以及针对这个场景，zab 协议中的崩溃恢复应该怎么处理。

1）已经被处理的消息不能丢（即前leader已提交情况）

当 leader 收到合法数量 follower 的 ACKs 后，就向各个 follower 广播 COMMIT 命令，同时也会在本地执行 COMMIT 并向连接的客户端返回「成功」。但是如果在各个 follower 在收到 COMMIT 命令前 leader 就挂了，导致剩下的服务器并没有执行都这条消息。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 1]

图中的C2就是一个典型的例子，在集群正常运行的某一个时刻，Server1是leader角色，先后广播了消息P1/P2/C1/P3/C2，其中当leader服务器把消息C2（Commit事务Proposal2）发出后就立即崩溃了，那么针对这种情况，ZAB协议就需要确保事务Proposal2最终能够在所有的服务器上都能被提交成功，否则就会出现不一致。

==> ZAB必须保证恢复处理后P2在所有服务器上都提交成功

2）被丢弃的消息不能再次出现（即前leader未提交情况）

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 2]

当leader收到请求并生成Proposal后就挂了，其他Follower并没有收到此Proposal。因此，经过恢复模式重新选举了leader后，这条消息是被跳过的。此时，之前挂过的leader重新启动并注册成了Follower，但他保留了被跳过消息的Proposal，与整个系统状态是不一致的，需要将其删除。

==> ZAB必须将恢复后（此时已经有新leader了，已经跳过P3）重新注册的Server1日志中删除P3

ZAB 协议需要满足上面两种情况，就必须要设计一个 leader 选举算法：能够确保已经被 leader 提交的事务 Proposal能够提交、同时丢弃已经被跳过的事务Proposal。

### 2.2 leader 选举依据 ###

如果 leader 选举算法能够保证新选举出来的 Leader 服务器拥有集群中所有机器最高编号（ZXID最大）的事务 Proposal，那么就可以保证这个新选举出来的 Leader 一 定具有已经提交的提案。因为所有提案被 COMMIT 之前必须有超过半数的 follower ACK，即必须有超过半数节点的服务器的事务日志上有该提案的 proposal，因此， 只要有合法数量的节点正常工作，就必然有一个节点保 存了所有被 COMMIT 消息的 proposal 状态

**关于ZXID**

ZXID 其实就是事务id，为了保证事务的顺序一致性，zookeeper 采用了递增的事务 id 号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了 zxid。

ZXID是64位的数字，高32位是epoch编号，低32位是消息计数器：

*  高32位：epoch（ZAB协议通过epoch 编号来区分 Leader 周期变化的策略），用来标识 leader 关系是否改变，每次一个 leader 被选出来，所有结点的新 epoch=原来的epoch+1（初始值=1）。  
    可以理解成，标识当前属于那个leader的统治时期，保证了即使旧leader恢复后也没有人再听它的（数据同步后就成了follower），因为 follower 只听从当前年代的 leader 的命令。
 *  低32位：用于递增计数，每接收到一条消息这个值+1。新 leader选举后这个值重置为0。

![在这里插入图片描述][20201112201130182.png_pic_center]

> 这样设计的好处在于老的leader挂了以后重启，它不会被选举为 leader，因此此时它的 zxid 肯定小于当前新的 leader。当老的 leader 作为 follower 接入新的 leader 后，新的 leader 会让它将所有的拥有旧的 epoch 号的未被 COMMIT 的 proposal 清除

在同一epoch下，通过对比新提案的ZXID与自身最新ZXID是否相差“1”，来保证事务严格按照顺序生效的。

具体的leader选举过程可以看这篇 [【Zookeeper】原理分析：Leader 选举过程分析][Zookeeper_Leader]…

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/49e308fcc33b46fa9e2605bfb6b5c185.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221120/4fd59bd81b354897a9439778a189f15d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 2]: https://img-blog.csdnimg.cn/20201112200200781.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw==,size_16,color_FFFFFF,t_70#pic_center
[20201112201130182.png_pic_center]: https://img-blog.csdnimg.cn/20201112201130182.png#pic_center
[Zookeeper_Leader]: https://blog.csdn.net/weixin_43935927/article/details/109659944