这也太简单了！！Zookeeper核心ZAB协议

来源：https://t.1yb.co/l5oJ

ZAB协议是什么？

ZAB 协议全称：Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）， 它保证Zookeeper 在主从系统架构下，集群中各个节点之间数据的一致性。保证数据一致性的分两种情况讨论，一种集群正常运行，一种集群不正常。

Zookeeper集群正常运行时采用「消息广播」模式保证；

Leader节点宕机情况下采用「崩溃恢复」模式，保证；

消息广播

消息广播，就是集群正常运行时接收客户端写请求，需要保证集群数据的一致。

消息广播是一个原子广播协议，类似二阶段提交过程。主要3个步骤：

Leader 接收客户端的写请求

Leader 封装事物Proposal消息，广播给集群中的所有Follower，等待ACK响应

当Leader接收 Follwer的ACK响应数过半(当然包括自己)，就commit自己本地数据，然后将commit请求广播给集群中的Follwer

消息广播大概流程如下：

结合上图，看看消息广播的具体细节：

Leader 接收到请求后在进行广播事务 Proposal 之前会为这个事务分配一个 ZXID，再进行广播。

Leader 会为每个Follower都各自分配一个单独的队列，然后将需要广播的事务 Proposal 依次放入这些队列中去，并根据 FIFO 策略进行消息的发送。

每个Follower 在接收到后都会以事务日志的形式写入到本地磁盘中，并且在成功写入后返回给 Leader一个 ACK 响应。

当有超过半数的Follower ACK 响应后，Leader 就会广播一个 Commit 消息给所有的 Follower，Follower 接收到后就完成对事务的提交操作。

ZXID 的设计也很有特点，是一个全局有序的 64 位的数字，可以分为两个部分：

高 32 位是：epoch（纪元），代表着周期，每当选举产生一个新的 Leader 服务器时

就会取出其本地日志中最大事务的 ZXID ，解析出epoch（纪元）值操作加 1作为新的 epoch ，

并将低 32 位置零。

低 32 位是：counter（计数器），它是一个简单的单调递增的计数器，针对客户端的每个事务请求都会进行加 1

画个更详细的图：

崩溃恢复

崩溃恢复，就是在Leader节点宕机的时候，重新选举出Leader后（关于选举机制可以参看这片文章），Follower 同步新Leader时，需要保证一致性。

在Leader节点宕机时，可能会发生2种情况，针对这两种情况我们来分析，它是怎么保证数据一致的。

Leader 在广播事务 Proposal 给所有 Follwer 之后宕机，数据怎么处理？

Leader 在收到 ACK 并commit自己，同时发送了部分 commit 出去之后宕机，数据怎么处理？

针对这2个情况，ZAB 定义了2个原则：

ZAB 协议会保存那些被Leader广播Proposal且提交的事务。

ZAB 协议会丢弃那些被Leader广播Proposal但没提交的事务。

说白了，就是Follwer接收到Leader的 commit请求的那些数据才有效。

在选举机制这篇文章，我们就可以确定出新的Leader节点数据一定是最新的。然后Follower就进行数据同步咯。

- END -