什么是zab协议

  1. 全称：Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）
  2. 基于该协议，zookeeper中实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致性。

zab协议的两种模式

其实zookeeper就是在崩溃恢复和消息广播这两个模式之间进行切换。当Leader服务可以正常使用，就进入广播消息模式，当Leader不可用时，则进入崩溃恢复模式。

主从模式

在上图中有多个客户端向Leader节点发起写入数据操作，Leader节点接收到数据之后将数据备份到多个Slaver中，从而保证数据一致性。

原子广播

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

  1. 客户端首先向zookeeper任意节点发起写请求（事务）。
  2. 如果接收的节点是Fellower/Observer类型，就将请求转发给Leader节点。
  3. Leader节点接收到消息之后对消息进行处理
      1. Leader节点对每条消息（事务）生成一个对应的zxid（全局唯一，递增）
      2. 将带有zxid的消息包装成一个proposal转发给所有的Follower节点。
  4. Follower将proposal这个事务写到磁盘，将结果（ack）返回给leader。
  5. Leader节点统计ack数量。
  6. 最后返回给客户端

简单解释
其实一个写请求就相当于mysql的一个事务
我们将事务发送到每个Follow节点上，节点如果成功操作就返回ack信息
只要成功操作节点的数量大于一半就将事务提交（commit）
否则的话就将事务进行回滚（rollback）

崩溃恢复

将Leader节点宕机或者失去了过半的follower节点的联系时就进入崩溃恢复模式
崩溃恢复的原则

ZAB 协议确保那些已经在 Leader 提交的事务最终会被所有服务器提交。
ZAB 协议确保丢弃那些只在 Leader 提出/复制，但没有提交的事务。
所以，ZAB 设计了下面这样一个选举算法：
能够确保提交已经被 Leader 提交的事务，同时丢弃已经被跳过的事务。
针对这个要求，如果让 Leader 选举算法能够保证新选举出来的 Leader 服务器拥有集群总所有机器编号（即 ZXID 最大）的事务，那么就能够保证这个新选举出来的 Leader 一定具有所有已经提交的提案。
而且这么做有一个好处是：可以省去 Leader 服务器检查事务的提交和丢弃工作的这一步操作。

  1. Leader 在收到 Ack 并提交了自己，同时发送了部分 commit 出去之后崩溃

针对这种情况ZAP定义了：已经被处理的消息不能丢失
因为每次提交的事务都有一个zxid（全局唯一，递增），因此我们只需要找出所有机器内zxid最大的事务（既该事务是最后一个被提交的事务）并且把存放该zxid的机器选举为leader即可

还可以省去 Leader 服务器检查事务的提交和丢弃工作的这一步操作。

  1. 当leader收到事务请求，并且还没有发起事务投票之前，leader宕机。

也就是只有leader服务器中有该事务，但是事务随着leader的宕机被丢弃掉了

针对这种情况ZAP定义了：已经被丢弃的消息不能再次出现

之前宕机的leader节点重新启动之后若再次被选为Leader，要把之前没有commit的事务重新commit，而当前的epoch大于该事务的epoch所以事务会被丢弃而不会被重新加载。也就是只有当事务zxid的epoch和当前的epoch相同时，事务才会被提交

数据同步

实际上，Leader 服务器处理或丢弃事务都是依赖着 ZXID 的，那么这个 ZXID 如何生成呢？
ZXID（64位）：低32位表示消息计数器（自增），高32位（epoch编号），每次leader得到一个事务都会为该事务生成一个ZXID
Epoch（32位）：每产生一个新的leader,那么epoch会+1

高 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 操作可以辨别事务的先后顺序。

Scroll to Top