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

ZAB协议是什么？

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

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

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

消息广播

消息广播，就是集群正常运行时接收客户端写请求，需要保证集群数据的一致。
消息广播是一个原子广播协议，类似二阶段提交过程。主要3个步骤：

1. Leader 接收客户端的写请求
2. Leader 封装事物Proposal消息，广播给集群中的所有Follower，等待ACK响应
3. 当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种情况，针对这两种情况我们来分析，它是怎么保证数据一致的。

1. Leader 在广播事务 Proposal 给所有 Follwer 之后宕机，数据怎么处理？
2. Leader 在收到 ACK 并commit自己，同时发送了部分 commit 出去之后宕机，数据怎么处理？

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

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

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

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

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