Zookeeper的ZAB协议原理详解

如何保证数据一致性。

Paxos，

吸收了主从。

zk = 数据模型+Watch机制

zab zookeeper原子广播协议。

ZooKeeper是通过Zab协议来保证分布式事务的最终一致性。

Zab(ZooKeeper Atomic Broadcast,.ZooKeeper原子广播协议)支持崩溃恢复，基于该协议，ZooKeeper实现了一种主备模式的系统架构来保持集群中各个副本之间数据一致性。

在ZooKeeper集群中，所有客户端的请求都是写入到Leader进程中的，然后，由Leader同步到其他节点，称为Follower.。在集群数据同步的过程中，如果出现Follower节点崩溃或者Leader进程崩溃时，都会通过Zab协议来保证数据一致性。 Zab协议的具体实现可以分为以下两部分：

消息广播阶段

崩溃恢复阶段

不能对外提供功能，CP

选举问题

比如Leader宕机，会进入到崩溃恢复节点，重新进行选举，崩溃恢复阶段还包括数据同步的操作，同步集群中最新的数据，保持集群一 致性

一般情况下，数据最新的会当选为主节点

当Leader可用时，正常的消息广播阶段 当Leader不可用时，进入到崩溃恢复阶段，选举完成新的Leader)后会进行数据同步，当数据同步完成以后，此时才会重新进入到消息广播阶 段。

ZXid(64位) = epoch（年代） + 递增器 32

Zxid是Zb协议的一个事务编号，Zxd是一个64位的数字，其中低32位是一个简单的单调递增计数器，针对客户端每一个事务请求，计数器 加1；而高32位则代表Leader周期年代(Epoch)的编号。

周期年代的概念和Raft中Term(任期)概念是一样的。

每次有一个新的Leader选举出现时候，Leader服务器取出本地日志中最大的事务ZXID,读取epoch值，进行+1操作，作为新的周期ID。

ZAB流程可以拆分为：消息广播–>崩溃恢复–>数据同步

在ZooKeeper中所有的事务请求都由Leader节点来处理，其他服务器为Follower,Leader将客户端的事务请求转换为事务Proposal,并且将Proposal分发给集群中其他所有的Follower。 完成广播之后，Leader等待Follwer反馈，当有过半数的Follower反馈信息后，Leader就commit，将再次向集群内Follower广播Commit信息，Commit信息就是确认将之前的Proposal提交。

Acknowledge 承认

ACK （Acknowledge character）即是确认字符

下面的几种情况都会进入崩溃恢复阶段：

初始化集群，刚刚启动的时候，无主

Leader崩溃，因为故障宕机

Leader失去了半数的机器支持，与集群中超过一半的节点断连，比如：发生了网络分区

崩溃恢复模式会开启新一轮的选举，选举产生的Leader会与过半的Follower进行数据同步，使数据一致，推出崩溃恢复模式，进入到消息广播模式。

server2 Leader节点挂了

在选举过程中，如果有节点获得超过半数的投票数，则会成为Leader节点，反之则重新投票选举。

崩溃恢复完成选举以后，接下来的工作就是数据同步，在选举过程中，通过投票已经确认Leader服务器是最大Zxid的节点，同步阶段就是利用 Leader前一阶段获得的最新Proposal历史，同步集群中所有的副本。