ZooKeeper的ZAB协议？

分析&回答

---

Zab（Zookeeper Atomic Broadcast）是为ZooKeeper协设计的崩溃恢复原子广播协议，它保证zookeeper集群数据的一致性和命令的全局有序性。

ZAB协议的两种基本模式：崩溃恢复模式和消息广播模式。

崩溃恢复模式

ZAB协议会让ZK集群进入崩溃恢复模式的情况如下：

1. 当服务框架在启动过程中
2. 当Leader服务器出现网络中断，崩溃退出与重启等异常情况。
3. 当集群中已经不存在过半的服务器与Leader服务器保持正常通信。

ZAB协议进入恢复崩溃模式会做什么事情？

1. 当Leader出现问题，则进入恢复模式并选举出新的Leader服务器。确保当Leader出现单点问题，在新选举出Leader后，保证数据一致性。当选举出新的Leader服务器，同时集群中已经有过半的机器与该Leader服务器完成状态同步（数据同步），退出崩溃恢复模式。进入消息广播模式。
   • ZAB协议需要确保那些已经在Leader服务器上提交的事务最终被所有服务器都提交。
   • ZAB协议需要确保丢弃那些只在Leader服务器上被提出的事务。
2. 当新加入一台机器到集群中，如果此时集群已经存在一个Leader服务器在负责进行消息广播，那么新加入的服务器就会自觉地进入数据恢复模式。找到Leader服务器，并与其进行数据同步，然后进入消息广播模式，一起参与到消息广播流程中去。

消息广播模式

• ZAB协议与二阶段提交协议不同的是，ZAB协议在二阶段提交过程中，移除了中断逻辑。
• ZAB协议在有过半的Follower服务器已经反馈Ack之后就开始提交Proposal了，而不需要等待集群中所有Follower服务器都反馈响应。
• 关于ZAB在Leader出现单点宕机如果保证事务提交，保证数据一致性，则引入崩溃恢复模式来解决这个问题。
• ZAB的消息广播协议是基于具有FIFO（先进先出）特性的TCP协议来进行网络通信，保证消息广播过程中消息的接收与发送的顺序性。

在整个消息广播过程中，Leader服务器会为每一个事务请求处理步骤：

1. Leader服务器会为事务请求生成一个全局的的递增事务ID（即ZXID），保证每个消息的因果关系的顺序。
2. Leader服务器会为该事务生成对应的Proposal，进行广播。
3. Leader服务器会为每一个Follower服务器都各自分配一个单独的队列，让后将需要广播的事务Proposal依次放入这些队列中去，并根据FIFO策略进行消息发送。
4. 每一个Follower服务器在接收到这个事务Proposal之后，首先以日志形式写入本地磁盘，并且成功写入后反馈给Leader服务器一个Ack响应
5. 当Leader服务器接收超过半数的Follower的Ack响应，Leader自身也会完成对事务的提交。同时就会广播一个Commit消息给所有的Follower服务器以通知进行事务提交。每一个Follower服务器在接收到Commit消息后，也会完成对事务的提交。

ZAB的Leader选举算法要求

1. 旧Leader宕机后，选举新Leader中，旧的Leader重启后不可能再次成为这次选举的新Leader。
2. 旧Leader宕机后，在剩下的Follower服务器选取新Leader的标准，一定是事务ID最大的那个Follower成为新Leader。（即数据同步最新的那台Follower服务器）
3. 事务ID（ZXID）是64位的数字。其中低32位可以靠做是一个简单的单调递增的计数器，高32位则代表一个Leader从生到死的epoch编号。
4. 新Leader选举出来，从事务proposal中分析出旧Leader的epoch编号，并递增1,作为新的事务ID的高32位，然后新事务ID的低32位从0位重新开始计数。
5. 新Leader通过事务ID和所有的Follower机器上的事务ID进行对比，确保数据同步。保证数据在所有的Follower上与之达成同步。旧Leader上新被提出的事务被抛弃。当数据达到同步，才将Follower服务器加入可用的Follower服务器列表。然后开始消息广播。

反思&扩展

---

ZAB协议和Paxos协议的区别？

• ZAB协议和Paxos算法的本质区别，两者的设计目标不太一样。
• ZAB协议主要用于构建一个高可用的分布式数据主备系统。例如ZooKeeper
• Paxos算法则是用于构建一个分布式的一致性状态机系统。

---

喵呜面试助手： 一站式解决面试问题，你可以搜索微信小程序 [喵呜面试助手] 或关注 [喵呜刷题] -> 面试助手 免费刷题。如有好的面试知识或技巧期待您的共享！