ZooKeeper 一致性协议 ZAB 原理

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

一致性协议有很多种，比如 Paxos，Raft，2PC，3PC等等，今天我们讲一种协议，ZAB 协议，该协议应该是所有一致性协议中生产环境中应用最多的了。为什么呢？因为他是为 Zookeeper 设计的分布式一致性协议！

---

一、什么是 ZAB 协议？

1. ZAB 协议全称：Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）。

2. Zookeeper 是一个为分布式应用提供高效且可靠的分布式协调服务。在解决分布式一致性方面，Zookeeper 并没有使用 Paxos，而是采用了 ZAB 协议。

3. ZAB 协议定义：ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持 崩溃恢复 和 原子广播协议。

4. 基于该协议，Zookeeper 实现了一种 主备模式 的系统架构来保持集群中各个副本之间 数据一致性。

二、消息广播

ZAB 协议的消息广播过程使用的是一个原子广播协议。对于客户端发送的写请求，全部由 Leader 接收，Leader 将请求封装成一个事务 Proposal，将其发送给所有 Follwer ，然后，根据所有 Follwer 的反馈，如果超过半数成功响应，则执行 commit 操作（先提交自己，再发送 commit 给所有 Follwer）。

如果集群中的Learner 节点收到客户端的事务请求，那么这些Learner会将请求转发给Leader服务器。然后再执行如下过程：

1. Leader接收到事务请求后，为事务赋予一个全局唯一的64位自增id，即zxid，通过zxid的大小比较即可实现事务的有序性管理，然后将事务封装成一个Proposal。
2. Leader 根据Follower 列表获取到所有的Follower，然后将Proposal通过这些Follower的队列将提案发送给各个Follower。
3. 当Follower 接收到提案后，会先将提案的zxid与本地记录的事务日志中的最大zxid进行比较。若当前提案的zxid大于最大zxid，则将当前提案记录到本地事务日志中，并向Leader 返回一个ACK。
   当Leader接收到过半的ACKs后，Leader 就会向所有Follower 的队列发送Commit 消息，向所有Observer的队列发送Proposal。
4. 当Follower接收到Commit消息后，就会将事务正式更新到本地。当Observer 收到Proposal 后，会直接将事务更新到本地。
5. 无论是Follower 还是 Observer ，在同步完成后都需要向Leader 发送成功ACK。

通过以上步骤，就能够保持集群之间数据的一致性。实际上，在 Leader 和 Follwer 之间还有一个消息队列，用来解耦他们之间的耦合，避免同步，实现异步解耦。

细节：

1. Leader 在收到客户端请求之后，会将这个请求封装成一个事务，并给这个事务分配一个全局递增的唯一 ID，称为事务ID（ZXID），ZAB 兮协议需要保证事务的顺序，因此必须将每一个事务按照 ZXID 进行先后排序然后处理。

2. 在 Leader 和 Follwer 之间还有一个消息队列，用来解耦他们之间的耦合，解除同步阻塞。

3. zookeeper集群中为保证任何所有进程能够有序的顺序执行，只能是 Leader 服务器接受写请求，即使是 Follower 服务器接受到客户端的请求，也会转发到 Leader 服务器进行处理。

4. 实际上，这是一种简化版本的 2PC，不能解决单点问题。等会我们会讲述 ZAB 如何解决单点问题（即 Leader 崩溃问题）。

三、崩溃恢复

消息广播过程中，Leader 崩溃怎么办？还能保证数据一致吗？如果 Leader 先本地提交了，然后 commit 请求没有发送出去，怎么办？
实际上，当 Leader 崩溃，即进入我们开头所说的崩溃恢复模式（崩溃即：Leader 失去与过半 Follwer 的联系）。下面来详细讲述。

假设1：Leader 在复制数据(未提交)给所有 Follwer 之后崩溃，怎么办？

假设2：Leader 在收到 Ack 并提交了自己，同时发送了部分 commit 出去之后崩溃怎么办？

针对这些问题，ZAB 定义了 2 个原则：

1、ZAB 协议确保那些已经在 Leader 提交的事务最终会被所有服务器提交。

2、ZAB 协议确保丢弃那些只在 Leader 提出事务/复制，但没有提交的事务。

让 Leader 选举算法能够保证新选举出来的 Leader 服务器拥有集群总所有机器编号（即 ZXID 最大）的事务，那么就能够保证这个新选举出来的 Leader 一定具有所有已经提交的提案。

而且这么做有一个好处是：可以省去 Leader 服务器检查事务的提交和丢弃工作的这一步操作。

四、数据同步

具体过程如下：

1. 为了保证Leader向Learner发送提案的有序，Leader会为每一个Learner 服务器准备一个队列
2. Leader 将那些没有被各个Leader同步的事务封装为Proposal
3. Leader 将那些Proposal逐条发给各个Learner，并在每个Proposal后紧跟一个Commit消息，表示该事务已经被提交，Learner可以直接接收并执行
4. Learner接收来自于Leader 的 Proposal，并将其更新到本地
5. 当Learner 更新成功后，会向准Leader 发送ACK信息
6. Leader 服务器在收到来自Learner的ACK后就会将该Learner加入到真正可用的Follower列表或Observer列表。没有反馈ACK，或反馈了但Leader没有收到的Learner，Leader不会将其加入到相应列表。

当崩溃恢复之后，需要在正式工作之前（接收客户端请求），Leader 服务器首先确认事务是否都已经被过半的 Follwer 提交了，即是否完成了数据同步。目的是为了保持数据一致。

当所有的 Follwer 服务器都成功同步之后，Leader 会将这些服务器加入到可用服务器列表中。

实际上，Leader 服务器处理或丢弃事务都是依赖着 ZXID 的，那么这个 ZXID 如何生成呢？

答：在 ZAB 协议的事务编号 ZXID 设计中，ZXID 是一个 64 位的数字，其中低 32 位可以看作是一个简单的递增的计数器，针对客户端的每一个事务请求，Leader 都会产生一个新的事务 Proposal 并对该计数器进行 + 1 操作。

而高 32 位则代表了 Leader 服务器上取出本地日志中最大事务 Proposal 的 ZXID，并从该 ZXID 中解析出对应的 epoch 值，然后再对这个值加一。

高 32 位代表了每代 Leader 的唯一性，低 32 代表了每代 Leader 中事务的唯一性。同时，也能让 Follwer 通过高 32 位识别不同的 Leader。简化了数据恢复流程。

基于这样的策略：当 Follower 链接上 Leader 之后，Leader 服务器会根据自己服务器上最后被提交的 ZXID 和 Follower 上的 ZXID 进行比对，比对结果要么回滚，要么和 Leader 同步。

总结

ZAB 协议和我们之前看的 Raft 协议实际上是有相似之处的，比如都有一个 Leader，用来保证一致性（Paxos 并没有使用 Leader 机制保证一致性）。再有采取过半即成功的机制保证服务可用（实际上 Paxos 和 Raft 都是这么做的）。

ZAB 让整个 Zookeeper 集群在两个模式之间转换，消息广播和崩溃恢复，消息广播可以说是一个简化版本的 2PC，通过崩溃恢复解决了 2PC 的单点问题，通过队列解决了 2PC 的同步阻塞问题。

而支持崩溃恢复后数据准确性的就是数据同步了，数据同步基于事务的 ZXID 的唯一性来保证。通过 + 1 操作可以辨别事务的先后顺序。