• ZooKeeper Atomic Broadcast(ZAB，ZooKeeper原子消息广播协议)是为分布式协调服ZooKeeper专门设计的一种支持崩溃恢复的原子广播协议。
• Zookeeper主要依赖ZAB协议来实现分布式数据一致性，实现了一种主备模式的系统架构来保持集群中个副本之间数据的一致性。

ZAB协议核心：所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，而余下的其他服务器则成为Follower服务器。Leader服务器负责将一个客户端事务请求转换成一个事务Proposal(提议)，并将该Proposal方发给集群中所有的Follower服务器。之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈后，那么Leader就会再次向所有的Follower服务器方发Commmit消息，要求其将前一个Proposal进行提交。

ZAB协议的两种模式

• 崩溃恢复

  一旦Leader服务器出现崩溃，或者由于网络原因导致Leader服务器失去了过半Follower的联系。则进入崩溃恢复模式。为了保证程序正确运行，在恢复过程结束后需要选举产生新的Leader服务器，而且需要让Leader自己知道自身已经被选举为Leader，同时需要让集群中的所有其他机器也能够快速感知到选举产生的新的Leader服务器。

  • 崩溃恢复过程可能出现的两个数据不一致性的隐患及针对这些情况ZAB协议所需要保证的特性

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

    • ZAB协议需要确保丢弃那些只在Leader服务器上被提出的事务

      如何处理那些需要被丢弃的事务Proposal的？
      在ZAB协议的事务编号ZXID设计中，ZXID是一个64位的数字，其中低32位可以看作是一个简单的单调递增的计数器，针对客户端的每一个事务请求，Leader服务器在产生一个新的事务Proposal的时候，都会对该计数器进行加1操作；而高32位则代表了Leader周期epoch的编号，每当选举产生一个新的Leader服务器，就会从这个Leader服务器上取出其本地日志中最大事务Proposal的ZXID，并从该ZXID中解析出对应的epoch值，然后再对其进行加1操作，之后就会以此编号作为新的epoch，并将低32位置0来开始生产新的ZXID。通过epoch编号来区分Leader周期变化的策略，能够有效避免不同的Leader服务器错误地使用相同的ZXID编号提出不一样的事务Proposal的异常情况。

• 消息广播

  ZAB协议的消息广播过程使用的是一个原子广播协议，类似于二阶段提交过程。
  针对客户端的事务请求，Leader服务器会为其生成对应的事务Proposal，并将其发送给集群中其余所有的机器，然后再分别收集各自的选票，最后进行事务提交。
  与二阶段提交差异：移除了中断逻辑，所有的Follower服务器要么正常反馈Leader提出的事务Proposal，要么就抛弃Leader服务器。ZAB协议将二阶段提交中的中断逻辑移除意味着我们可以在过半的Follower服务器已经提交Ack之后就开始提交事务Proposal，无需等待集群中所有的Follower服务器都反馈响应。该简化了二阶段提交过程，带来数据不一致的问题，ZAB协议中采用崩溃恢复模式来解决这个问题。