zookeeper--一致性协议 ZAB

一、简介

ZAB 协议全称：Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）。 是一个为分布式应用提供高效且可靠的分布式协调服务。在解决分布式一致性方面，Zookeeper 并没有使用 Paxos ，而是采用了 ZAB 协议。

ZAB 协议定义：ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持 崩溃恢复 和 原子广播 协议。基于该协议，Zookeeper 实现了一种 主备模式 的系统架构来保持集群中各个副本之间 数据一致性。具体如下图所示：

二、ZAB协议内容

1.消息广播

ZAB 协议的消息广播过程使用的是一个原子广播协议，类似一个 2PC提交过程。

（1）对于客户端发送的写请求，全部由 Leader 接收

（2）Leader 将请求封装成一个事务 Proposal，将其发送给所有 Follwer

（3）然后，根据所有 Follwer 的反馈，如果超过半数成功响应，则执行 commit 操作（先提交自己，再发送 commit 给所有 Follwer）

其他问题：

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

（2）在 Leader 和 Follwer 之间还有一个消息队列，用来解耦他们之间的耦合，解除同步阻塞。Leader 服务器会为每一个 Follower 服务器都各自分配一个单独的队列，然后将需要广播的事务 Proposal 依次放入这些队列中去，并且根据 FIFO策略进行消息发送。每一个 Follower 服务器在接收到这个事务 Proposal之后，都会首先将其以事务日志的形式写入到本地磁盘中去，并且在成功写入后反馈给 Leader 服务器一个 Ack 响应。当 Leader 服务器接收到超过半数 Follower 的 Ack 响应后，就会广播一个 Commit 消息给所有的 Follower 服务器以通知其进行事务提交，同时 Leader 自身也会完成对事务的提交，而每一个 Follower 服务器在接收到 Commit 消息后，也会完成对事务的提交。

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

2.崩溃恢复

消息广播过程中，如果Leader 崩溃怎么办？还能保证数据一致吗？如果 Leader 先本地提交了，然后 commit 请求没有发送出去，怎么办？所以zookeeper引入了崩溃恢复模式，一旦 Leader 服务器出现崩溃，或者说由于网络原因导致 Leader 服务器失去了与过半 Follower 的联系，那么就会进入崩溃恢复模式

ZAB 定义了 2 个原则：

 

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

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

3.选举方式

当leader进入了崩溃恢复模式时，需要选出一个新的leader

所以，ZAB 设计了下面这样一个选举算法：能够确保提交已经被 Leader 提交的事务，同时丢弃已经被跳过的事务。

针对这个要求，如果让 Leader 选举算法能够保证新选举出来的 Leader 服务器拥有集群总所有机器编号（即 ZXID 最大）的事务，那么就能够保证这个新选举出来的 Leader 一定具有所有已经提交的提案。因为在收到客户端请求之后会生成一个自增的ZXID 

4.数据同步

完成 Leader 选举之后，在正式开始工作（即接收客户端的事务请求，然后提出新的提案）之前，Leader 服务器会首先确认事务日志中的所有 Proposal 是否都已经被集群中过半的机器提交了，即是否完成数据同步。下面我们就来看看 ZAB 协议的数据同步过程。

所有正常运行的服务器，要么成为 Leader，要么成为 Follower 并和 Leader 保持同步。 Leader服务器需要确保所有的 Follower 服务器能够接收到每一条事务提案，并且能够正确地将所有已经提交了的事务提案应用到内存数据库中去。具体的，Leader 服务器会为每一个 Follower 服务器都准备一个队列，并将那些没有被各 Follower 服务器同步的事务以提案消息的形式逐个发送给 Follower 服务器，并在每一个 Proposal 消息后面紧接着再发送一个 Commit 消息，以表示该事务已经被提交。等到 Follower 服务器将所有其尚未同步的事务提案都从 Leader 服务器上同步过来并成功应用到本地数据库中后，Leader 服务器就会将该 Follower 服务器加入到真正的可用 Follower 列表中，并开始之后的其他流程

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

 

三、总结

ZAB 让整个 Zookeeper 集群在两个模式之间转换，消息广播和崩溃恢复，消息广播可以说是一个简化版本的 2PC，通过崩溃恢复解决了 2PC 的单点问题，通过队列解决了 2PC 的同步阻塞问题。并采取过半即成功的机制保证服务可用

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