zookeeper的zab协议工作原理

原子广播

说zab协议之前必须提一下 paxos 协议

paxos协议主要就是如何保证在分布式环网络环境下，各个服务器如何达成一致最终保证数据的一致性问题

ZAB协议，基于paxos协议的一个改进。

zab协议为分布式协调服务zookeeper专门设计的一种支持崩溃恢复的原子广播协议

zookeeper并没有完全采用paxos算法， 而是采用zab Zookeeper atomic broadcast

zab协议的原理

1. 在zookeeper 的主备模式下，通过zab协议来保证集群中各个副本数据的一致性

2. zookeeper使用的是单一的主进程来接收并处理所有的事务请求，并采用zab协议，
   把数据的状态变更以事务请求的形式广播到其他的节点

3. zab协议在主备模型架构中，保证了同一时刻只能有一个主进程来广播服务器的状态变更

4. 所有的事务请求必须由全局唯一的服务器来协调处理，这个的服务器叫leader，其他的叫follower，leader节点主要负责把客户端的事务请求转化成一个事务提议（proposal），并分发给集群中的所有follower节点，再等待所有follower节点的反馈。一旦超过半数服务器进行了正确的反馈，那么leader就会commit这条消息。

5. 然后再进行leader 和 follower 直接的数据同步。

这里有几个地方要注意一下：

1、follower服务器的投票并不是真正意义上的投票，而是follower 服务器 表示收到了 leader节点发过来的消息，给予一个收到的提示。 跟分布式事务中的 两阶段提交 中的第一阶段类似。

2、zab协议 与 分布式事务不同的是， 分布式事务 的两阶段提交要求所有事务处理节点（器）都要投票同意。 而zab协议中 只要求半数 服务器节点投票同意即可。为什么只要半数就可以了呢？是因为zab协议就是为了保证在网络不可靠的情况下，整个集群还能正常的工作。有超过半数的服务器投票同意，那么leader节点就执行写的操作，commit之后，再进行原子广播给其它的follower节点， 让 follower节点来同步数据，如果跟两阶段提交一样，还需要所有节点都同意的话，那明显与zab协议的使用场景不同了。

图的流程大致是：

1、客户端发来一个request给第一个follower节点，如果是读请求，follower节点直接将数据返回。

2、如果是写请求，也就是事务请求，那么follower节点就将请求转发给leader，leader再像集群中的 follower节点发起一个事务请求提议（proposal）。

3、follower节点正常情况下 都会返回一个ack 给 leader ，表示 follower 节点收到 leader的消息了，这里就是所谓的投票。正常情况下都会投票的，没有投票的情况就是 有的follower 节点 挂掉了 投不了票就没投。

3、当机器中超过半数的服务器 都投票了（leader 自己本身也参与投票），那么 leader就commit 这个事务请求，然后再通过原子广播 通知 集群中其它的 follower 跟 Ob 节点来同步数据。

崩溃恢复

一、什么情况下zab协议会进入崩溃恢复模式？

1、当服务器启动时
2、当leader 服务器出现网络中断，崩溃或者重启的情况
3、当集群中已经不存在过半的服务器与Leader服务器保持正常通信。

二、zab协议进入崩溃恢复模式会做什么？

1、当leader出现问题，zab协议进入崩溃恢复模式，并且选举出新的leader。当新的leader选举出来以后，如果集群中已经有过半机器完成了leader服务器的状态同（数据同步），退出崩溃恢复，进入消息广播模式。

2、当新的机器加入到集群中的时候，如果已经存在leader服务器，那么新加入的服务器就会自觉进入崩溃恢复模式，找到leader进行数据同步。

三、特殊情况下需要解决的两个问题：
1、已经被处理的事务请求（proposal）不能丢
2、没被处理的事务请求（proposal）不能再次出现

什么时候会出现事务请求被丢失呢？

当 leader 收到合法数量 follower 的 ACKs 后，就向各个 follower 广播 COMMIT 命令，同时也会在本地执行 COMMIT 并向连接的客户端返回「成功」。但是如果在各个 follower 在收到 COMMIT 命令前 leader 就挂了，导致剩下的服务器并没有执行都这条消息。

如何解决 已经被处理的事务请求（proposal）不能丢（commit的）呢？

1、选举拥有 proposal 最大值（即 zxid 最大） 的节点作为新的 leader：由于所有提案被 COMMIT 之前必须有合法数量的 follower ACK，即必须有合法数量的服务器的事务日志上有该提案的 proposal，因此，zxid最大也就是数据最新的节点保存了所有被 COMMIT 消息的 proposal 状态。

2、新的 leader 将自己事务日志中 proposal 但未 COMMIT 的消息处理。
3、新的 leader 与 follower 建立先进先出的队列， 先将自身有而 follower 没有的 proposal 发送给 follower，再将这些 proposal 的 COMMIT 命令发送给 follower，以保证所有的 follower 都保存了所有的 proposal、所有的 follower 都处理了所有的消息。通过以上策略，能保证已经被处理的消息不会丢。

问题二出现的场景是：

当 leader 接收到消息请求生成 proposal 后就挂了，其他 follower 并没有收到此 proposal，因此经过恢复模式重新选了 leader 后，这条消息是被跳过的。 此时，之前挂了的 leader 重新启动并注册成了 follower，他保留了被跳过消息的 proposal 状态，与整个系统的状态是不一致的，需要将其删除。

解决方案是：

Zab 通过巧妙的设计 zxid 来实现这一目的。一个 zxid 是64位，高 32 是纪元（epoch）编号，每经过一次 leader 选举产生一个新的 leader，新 leader 会将 epoch 号 +1。低 32 位是消息计数器，每接收到一条消息这个值 +1，新 leader 选举后这个值重置为 0。这样设计的好处是旧的 leader 挂了后重启，它不会被选举为 leader，因为此时它的 zxid 肯定小于当前的新 leader。当旧的 leader 作为 follower 接入新的 leader 后，新的 leader 会让它将所有的拥有旧的 epoch 号的未被 COMMIT 的 proposal 清除。