Zookeeper Zap协议

偏执的太偏执、 2022-09-08 13:49 228阅读 0赞

## 什么是zap协议？ ##

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

## zap协议内容？ ##

Zab 协议包括两种基本的模式：**崩溃恢复** 和 **消息广播**

### **协议过程** ###

>         当整个集群启动过程中，或者当 Leader 服务器出现网络中弄断、崩溃退出或重启等异常时，Zab协议就会 **进入崩溃恢复模式**，选举产生新的Leader。
> 
>         当选举产生了新的 Leader，同时集群中有**过半**的机器与该 Leader 服务器**完成了状态同步**（即数据同步）之后，Zab协议就会退出崩溃恢复模式，**进入消息广播模式**。
> 
>         这时，如果有一台遵守Zab协议的服务器加入集群，因为此时集群中已经存在一个Leader服务器在广播消息，那么该**新加入的服务器自动进入恢复模式**：找到Leader服务器，并且完成数据同步。同步完成后，作为新的Follower一起参与到消息广播流程中。

### 协议状态切换 ###

>         当Leader出现崩溃退出或者机器重启，亦或是集群中不存在超过半数的服务器与Leader保存正常通信，Zab就会再一次进入崩溃恢复，发起新一轮Leader选举并实现数据同步。同步完成后又会进入消息广播模式，接收事务请求。

### 保证消息有序 ###

> 在整个消息广播中，Leader会将每一个事务请求转换成对应的 proposal 来进行广播，并且在广播 事务Proposal 之前，Leader服务器会首先为这个事务Proposal分配一个全局单递增的唯一ID，称之为事务ID（即zxid），由于Zab协议需要保证每一个消息的**严格的顺序关系**，因此必须**将每一个proposal按照其zxid的先后顺序进行排序和处理**。

### 崩溃恢复 ###

**一旦 Leader 服务器出现崩溃或者由于网络原因导致 Leader 服务器失去了与过半 Follower 的联系，那么就会进入崩溃恢复模式。**

在 Zab 协议中，为了保证程序的正确运行，整个恢复过程结束后需要选举出一个新的 Leader 服务器。因此 Zab 协议需要一个高效且可靠的 Leader 选举算法，从而确保能够快速选举出新的 Leader 。

Leader 选举算法不仅仅需要让 Leader 自己知道自己已经被选举为 Leader ，同时还需要让集群中的所有其他机器也能够快速感知到选举产生的新 Leader 服务器。

崩溃恢复主要包括两部分：**Leader选举** 和 **数据恢复**

### 消息广播 ###

1）在zookeeper集群中，数据副本的传递策略就是采用消息广播模式。zookeeper中数据副本的同步方式与二段提交相似，但是却又不同。二段提交要求协调者必须等到所有的参与者全部反馈ACK确认消息后，再发送commit消息。要求所有的参与者要么全部成功，要么全部失败。二段提交会产生严重的阻塞问题。

2）Zab协议中 Leader 等待 Follower 的ACK反馈消息是指“只要半数以上的Follower成功反馈即可，不需要收到全部Follower反馈”

![808202145f7bd5f400e21bb19e16e971.png][]

**消息广播具体步骤**

1）客户端发起一个写操作请求。

2）Leader 服务器将客户端的请求转化为事务 Proposal 提案，同时为每个 Proposal 分配一个全局的ID，即zxid。

3）Leader 服务器为每个 Follower 服务器分配一个单独的队列，然后将需要广播的 Proposal 依次放到队列中取，并且根据 FIFO 策略进行消息发送。

4）Follower 接收到 Proposal 后，会首先将其以事务日志的方式写入本地磁盘中，写入成功后向 Leader 反馈一个 Ack 响应消息。

5）Leader 接收到超过半数以上 Follower 的 Ack 响应消息后，即认为消息发送成功，可以发送 commit 消息。

6）Leader 向所有 Follower 广播 commit 消息，同时自身也会完成事务提交。Follower 接收到 commit 消息后，会将上一条事务提交。

**zookeeper 采用 Zab 协议的核心，就是只要有一台服务器提交了 Proposal，就要确保所有的服务器最终都能正确提交 Proposal。这也是 CAP/BASE 实现最终一致性的一个体现。**

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

## zab 协议如何保证数据一致性 ##

假设两种异常情况：  
1、一个事务在 Leader 上提交了，并且过半的 Folower 都响应 Ack 了，但是 Leader 在 Commit 消息发出之前挂了。  
2、假设一个事务在 Leader 提出之后，Leader 挂了。

要确保如果发生上述两种情况，数据还能保持一致性，那么 Zab 协议选举算法必须满足以下要求：

**Zab 协议崩溃恢复要求满足以下两个要求**：  
1）**确保已经被 Leader 提交的 Proposal 必须最终被所有的 Follower 服务器提交**。  
2）**确保丢弃已经被 Leader 提出的但是没有被提交的 Proposal**。

根据上述要求  
Zab协议需要保证选举出来的Leader需要满足以下条件：  
1）**新选举出来的 Leader 不能包含未提交的 Proposal** 。  
即新选举的 Leader 必须都是已经提交了 Proposal 的 Follower 服务器节点。  
2）**新选举的 Leader 节点中含有最大的 zxid** 。  
这样做的好处是可以避免 Leader 服务器检查 Proposal 的提交和丢弃工作。

**Zab 节点有三种状态**：

*  Following：当前节点是跟随者，服从 Leader 节点的命令。
 *  Leading：当前节点是 Leader，负责协调事务。
 *  Election/Looking：节点处于选举状态，正在寻找 Leader。

代码实现中，多了一种状态：Observing 状态  
这是 Zookeeper 引入 Observer 之后加入的，Observer 不参与选举，是只读节点，跟 Zab 协议没有关系。

**节点的持久状态**：

*  history：当前节点接收到事务 Proposal 的Log
 *  acceptedEpoch：Follower 已经接受的 Leader 更改 epoch 的 newEpoch 提议。
 *  currentEpoch：当前所处的 Leader 年代
 *  lastZxid：history 中最近接收到的Proposal 的 zxid（最大zxid）

Zab 的四个阶段

**1、选举阶段（Leader Election）**  
节点在一开始都处于选举节点，只要有一个节点得到超过半数节点的票数，它就可以当选准 Leader，只有到达第三个阶段（也就是同步阶段），这个准 Leader 才会成为真正的 Leader。

**Zookeeper 规定所有有效的投票都必须在同一个 轮次 中，每个服务器在开始新一轮投票时，都会对自己维护的 logicalClock 进行自增操作**。

每个服务器在广播自己的选票前，会将自己的投票箱（recvset）清空。该投票箱记录了所受到的选票。  
例如：Server\_2 投票给 Server\_3，Server\_3 投票给 Server\_1，则Server\_1的投票箱为(2,3)、(3,1)、(1,1)。（每个服务器都会默认给自己投票）

前一个数字表示投票者，后一个数字表示被选举者。票箱中只会记录每一个投票者的最后一次投票记录，如果投票者更新自己的选票，则其他服务器收到该新选票后会在自己的票箱中更新该服务器的选票。

**这一阶段的目的就是为了选出一个准 Leader ，然后进入下一个阶段。**  
协议并没有规定详细的选举算法，后面会提到实现中使用的 Fast Leader Election。

![fc6a7572cb771e05b031ef162b4581ea.png][]

**2、发现阶段（Descovery）**  
在这个阶段，Followers 和上一轮选举出的准 Leader 进行通信，同步 Followers 最近接收的事务 Proposal 。  
一个 Follower 只会连接一个 Leader，如果一个 Follower 节点认为另一个 Follower 节点，则会在尝试连接时被拒绝。被拒绝之后，该节点就会进入 Leader Election阶段。

**这个阶段的主要目的是发现当前大多数节点接收的最新 Proposal，并且准 Leader 生成新的 epoch ，让 Followers 接收，更新它们的 acceptedEpoch**。

![a2dc5e06829edd46ac2ea074ae8be7d1.png][]

**3、同步阶段（Synchronization）**  
**同步阶段主要是利用 Leader 前一阶段获得的最新 Proposal 历史，同步集群中所有的副本**。  
只有当 quorum（超过半数的节点） 都同步完成，准 Leader 才会成为真正的 Leader。Follower 只会接收 zxid 比自己 lastZxid 大的 Proposal。

![0a058d0911879da8c33a4a6399948b08.png][]

**4、广播阶段（Broadcast）**  
到了这个阶段，Zookeeper 集群才能正式对外提供事务服务，并且 Leader 可以进行消息广播。同时，如果有新的节点加入，还需要对新节点进行同步。  
需要注意的是，Zab 提交事务并不像 2PC 一样需要全部 Follower 都 Ack，只需要得到 quorum（超过半数的节点）的Ack 就可以。

![7564e3c29b37f7b77cf59646c7c44afc.png][]

[808202145f7bd5f400e21bb19e16e971.png]: /images/20220829/79ce061d8cca49cbacd9227bbc7b7c31.png
[fc6a7572cb771e05b031ef162b4581ea.png]: /images/20220829/b846b516912646ebb393759adc1b9c2b.png
[a2dc5e06829edd46ac2ea074ae8be7d1.png]: /images/20220829/93cf12d76e38474eacfb2dba36c424ac.png
[0a058d0911879da8c33a4a6399948b08.png]: /images/20220829/be0126638ba04be79185599acf2eecdd.png
[7564e3c29b37f7b77cf59646c7c44afc.png]: /images/20220829/161c8f9fa0c44538ac528d18e6209412.png