之前我更新了一篇文章是关于分布式数据一致性算法Paxos算法的，但是实际上zookeeper并没有使用这种算法作为保持分布式数据一致性算法，使用的是一种叫做ZAB协议来进行zookeeper集群中的节点奔溃恢复和保持数据一致性的。因为ZAB算法其实就是采用了部分Paxos算法的一些思想的。ZAB协议是为分布式协调服务zk专门设计的一直支持奔溃恢复的原子广播协议。
在zk中，主要依赖它来实现数据一致性，基于该协议zk实现了一种主备模式的系统架构来保持集群中各个节点(副本)之间的数据一致性，同时在崩溃恢复时也能保证高可用性。
在zk中是使用单一的主进程来处理所有的事务请求的，并且采用ZAB的原子广播协议，将服务器数据的状态变更然后以事务Proposal的形式广播到所有的副本进程，并且ZAB协议能够保证一个全局的变更序列。
核心
ZAB协议的核心是定义了那些会变更zk服务器数据状态的事务请求的处理方式。
先来解决最主要的两个问题:
集群中，leader奔溃了，数据一致性怎么保证？
选举leader时，整个集群无法处理写操作，如何快速选举和保持一致性。
ZAB协议有很多功能，最主要的就是:
1.消息广播
2.leader选举(快速选举算法 fasetLeaderelection，集群刚启动时，leader还未启动和集群中超过一半节点断连)
3.leader重新选举后，数据如何同步一致性。
ZAB协议的节点有三种状态
following：当前节点是跟随者，服从 leader 节点的命令。
leading：当前节点是 leader，负责协调事务。
election/locking：节点处于选举状态,恢复模式。
ZAB 协议包含两种基本模式，分别是
- 崩溃恢复
- 原子广播
在讲解崩溃恢复时，我们还需要接触一下这两个概念:
事务IDZxid, 在 ZAB 协议的事务编号 Zxid 设计中，Zxid 是一个 64 位的数字，其中低 32 位是一个简单的单调递增的计数器，针对客户端每一个事务请求，计数器加 1；而高 32 位则代表 Leader 周期 epoch 的编号，每个当选产生一个新的 Leader 服务器，就会从这个 Leader 服务器上取出其本地日志中最大事务的ZXID，并从中读取 epoch 值，然后加 1，以此作为新的 epoch，并将低 32 位从 0 开始计数。
epoch：可以理解为当前集群所处的年代或者周期，每个 leader 就像皇帝，都有自己的年号，所以每次改朝换代，leader 变更之后，都会在前一个年代的基础上加 1。这样就算旧的 leader 崩溃恢复之后，也没有人听他的了，因为 follower 只听从当前年代的 leader 的命令。
epoch 的变化大家可以做一个简单的实验
- 启动一个 zookeeper 集群。
- 在 /tmp/zookeeper/VERSION-2 路径下会看到一个currentEpoch 文件。文件中显示的是当前的 epoch
- 把 leader 节点停机，这个时候在看 currentEpoch 会有变化。 随着每次选举新的 leader，epoch 都会发生变化
1.崩溃恢复
当整个集群在启动时，或者当 leader 节点出现网络中断、崩溃等情况时，ZAB 协议就会进入恢复模式并选举产生新的 Leader，当 leader 服务器选举出来后，并且集群中有过半的机器和该 leader 节点完成数据同步后（同步指的是数据同步，用来保证集群中过半的机器能够和 leader 服务器的数据状态保持一致），ZAB 协议就会退出恢复模式。
当集群中已经有过半的 Follower 节点完成了和 Leader 状态同步以后，那么整个集群就进入了消息广播模式。这个时候，在 Leader 节点正常工作时，启动一台新的服务器加入到集群，那这个服务器会直接进入数据恢复模式，和leader 节点进行数据同步。同步完成后即可正常对外提供非事务请求的处理。
2.消息广播的实现原理
如果大家了解分布式事务的 2pc 和 3pc 协议的话,可以跳过往下看，否则可以看看我这篇文章:
https://www.jianshu.com/p/948d843b0489
消息广播的过程实际上是一个简化版本的二阶段提交过程
1.leader在接收到一个写消息请求后，讲消息赋予一个zxid，通过比较这个的大小，既可以实现当前"leader"版本有序。
2.leader为每一个follow准备一个FIFO队列(通过TCP协议来实现，以实现了全局有序这一个特点)将带有zxid的消息作为一个提案Proposal(二阶段协议中的一个概念)分发给所有的follower。
3.当follower接收到proposal，先把proposal写到磁盘，写入成功后再向leader发送一个ACK。
4.当leader接收到超过集群中一半的ACK以后，就发送commit命令，同时会在本地执行该消息。
5.当foller接收到该消息时，会提交。
这就是类2pc提交，也有缺点，但是我们不深入讨论。
提示:
leader 的投票过程，不需要 Observer 的 ack，也就是Observer 不需要参与投票过程，但是 Observer 必须要同步 Leader 的数据从而在处理请求的时候保证数据的一致性
ZAB 协议的这个基于原子广播协议的消息广播过程，在正常情况下是没有任何问题的，但是一旦 Leader 节点崩溃，或者由于网络问题导致 Leader 服务器失去了过半的Follower 节点的联系（leader 失去与过半 follower 节点联系，可能是 leader 节点和 follower 节点之间产生了网络分区(脑裂)，那么此时的 leader 不再是合法的 leader 了），那么就会进入到崩溃恢复模式。在 ZAB 协议中，为了保证程序的正确运行，整个恢复过程结束后需要选举出一个新的Leader 为了使 leader 挂了后系统能正常工作，需要解决以下两个问题 :
- 已经被处理的消息不能丢失
当 leader 收到合法数量 follower 的 ACKs 后，就向各个 follower 广播 COMMIT 命令，同时也会在本地执行 COMMIT 并向连接的客户端返回「成功」。但是如果在各个 follower 在收到 COMMIT 命令前 leader就挂了，导致剩下的服务器并没有执行都这条消息。
leader 对事务消息发起 commit 操作，但是该消息在follower1 上执行了，但是 follower2 还没有收到 commit，就已经挂了，而实际上客户端已经收到该事务消息处理成功的回执了。所以在 zab 协议下需要保证所有机器都要执行这个事务消息
- 被丢弃的消息不能再次出现
当 leader 接收到消息请求生成 proposal 后就挂了，其他 follower 并没有收到此 proposal，因此经过恢复模式重新选了 leader 后，这条消息是被跳过的。 此时，之前挂了的 leader 重新启动并注册成了 follower，他保留了被跳过消息的 proposal 状态，与整个系统的状态是不一致的，需要将其删除。
ZAB 协议需要满足上面两种情况，就必须要设计一个leader 选举算法：能够确保已经被 leader 提交的事务Proposal 能够提交、同时丢弃已经被跳过的事务 Proposal。针对这个要求
(以下要求理解就好)
. 如果 leader 选举算法能够保证新选举出来的 Leader 服务器拥有集群中所有机器最高编号（ZXID 最大）的事务Proposal，那么就可以保证这个新选举出来的 Leader 一定具有已经提交的提案。因为所有提案被 COMMIT 之前必须有超过半数的 follower ACK，即必须有超过半数节点的服务器的事务日志上有该提案的 proposal，因此，只要有合法数量的节点正常工作，就必然有一个节点保存了所有被COMMIT 消息的 proposal 状态。
另外一个，zxid 是 64 位，高 32 位是 epoch 编号，每经过一次 Leader 选举产生一个新的 leader，新的 leader 会将epoch 号+1，低 32 位是消息计数器，每接收到一条消息这个值+1，新 leader 选举后这个值重置为 0.这样设计的好处在于老的 leader 挂了以后重启，它不会被选举为 leader，因此此时它的 zxid 肯定小于当前新的 leader。当老的leader 作为 follower 接入新的 leader 后，新的 leader 会让它将所有的拥有旧的 epoch 号的未被 COMMIT 的 proposal 清除
最后一点，我们需要知道leader选举是怎么样进行选举的，这点想要了解的话，可以看我这篇博客:
感谢您阅读我的文章，整理不易，帮我点个赞，谢谢哈。
思想的碰撞最能促进技术的进步哦。
网友评论