全称：Zookeeper Atomic Broadcast（Zookeeper原子广播），Zookeeper通过ZAB协议来保证分布式事物的最终一致性。
ZAB协议的核心是定义了对于那些会改变ZooKeeper服务器数据状态的事物请求的处理方式。所有事物请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，余下的服务器则称为Follower服务器，Leader服务器负责将一个客户端事物请求转换成一个事物Proposal（提议），并将该Proposal分发给集群中所有的Follower服务器，之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行来正确的反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求将前一个Proposal进行提交。

ZAB协议内容

崩溃恢复

当整个服务器框架启动过程中，或者是Leader服务器出现网络中断、崩溃退出或重启等异常情况时，ZAB协议就会进入崩溃恢复模式，同时选举产生新的Leader服务器。当选举产生来新的Leader服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步（数据同步）之后，ZAB协议就会退出恢复模式。

消息广播

当集群中已经有过半的Follower服务器完成了和Leader服务器的状态同步，那么整个服务框架就可以进行消息广播模式，当一台同样遵守ZAB协议的服务器启动之后加入到集群中，如果此时集群中已经存在一个Leader服务器在负责进行消息广播，那么加入的服务器就会自动进入数据恢复模式，找到Leader所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。
ZAB协议的消息广播过程使用原子广播协议，类似于一个二阶段提交过程，针对客户端的事物请求，Leader服务器会为其生成对应的事物proposal，并将其发送给集群中其余所有的机器，然后再分别收集各自的选票，最后进行事物提交。

ZAB协议特性

  • 1）ZAB协议需要确保那些已经在Leader服务器上提交的事物最终都被所有的服务器提交。

  • 2）ZAB协议需要确保丢弃那些只在Leader上被提出而没有被提交的事物。

    运行时状态分析

    在ZAB协议的设计中，每个进程都有可能处于如下三种状态之一：

  • LOOKING：Leader选举阶段

  • FOLLOWING：Follower服务器和Leader服务器保持同步状态，服从Leader节点的指令
  • LEADING：Leader服务器作为主进程状态，开始协调事物

参考资料：
知乎-Zookeeper——一致性协议:Zab协议