上期介绍了 ZooKeeper 的基本概念、角色、工作机制等内容，为了后续更好地学习 ZooKeeper 的原理，本期先给大家介绍一种分布式一致性协议——ZAB(ZooKeeper Atomic Broadcast，ZooKeeper 原子消息广播协议)。
1. 什么是ZAB
在介绍 ZAB 之前，先给大家介绍下 ZooKeeper 的由来。
ZooKeeper 最早起源于雅虎研究院的一个研究小组，当时雅虎内部很多大型系统都需要依赖一个类似的系统来进行分布式协调，为了让把精力集中在业务逻辑上，雅虎研发人员开发了一个通用的解决了单点问题的分布式协调框架。
ZooKeeper 名字的由来：
立项之初，考虑到很多项目都是使用动物的名字来命名的，雅虎的工程师希望给这个项目也取一个动物的名字。有人开玩笑地说：“在这样下去，我们这儿就变成动物园了！”此话一出，大家纷纷表示就叫动物园管理员吧。
而 ZAB 协议最初也只是为雅虎内部那些高吞吐量、低延迟的分布式系统场景设计的，它并不是一种通用的分布式一致性算法，而是专门为 ZooKeeper 设计的一种支持崩溃恢复的原子广播协议，实现了一种主备模式的系统架构来保持集群中各副本之间数据的一致性。
2. 两个概念
1）当前集群的周期号：Epoch
集群中每次 Leader 的重新选举都会产生一个新的周期号（也有叫年代号的，都一个意思），周期号的产生规则则是在上一个周期号上加1，这样当之前的 Leader 奔溃恢复后会发现自己的周期号比当前的周期号小，说明此时集群已经产生了一个新的 Leader，旧的 Leader 会再次以 Follower 的角色加入集群。
2）ZAB 协议的事务编号：Zxid
Zxid 是一个64位的数字，其中低32位存储的是一个简单的单调递增的计数器，针对客户端的每个事务请求，计数器都会加1。高32位存储的是 Leader 的周期号 Epoch。每次选举产生一个新的 Leader 时，该 Leader 就会从当前服务器的日志中取最大事务的 Zxid，获取其中高32位的 Epoch 值并加1，以此作为一个新的 Epoch，并会将低32位从0开始重新计数。
3. 两种模式
1）集群选主：恢复模式
当集群 Leader 出现崩溃，或者由于网络原因导致 Leader 和过半的 Follower 失去联系，那么集群将开始选主，该过程为恢复模式。
Leader 的选举机制不仅可以让 Leader 节点知道自身被选举为 Leader，同时还能需要让集群中其他节点也能快速感知到选举的新的 Leader 节点。
2）数据同步：广播模式
当 Leader 被选举出来后，Leader 将最新的集群状态广播给其他 Follower，该过程为广播模式。在半数以上的 Follower 完成与 Leader 的状态同步后，广播模式结束。
4. ZAB 的实现过程
1）选举阶段
选举阶段的目的就是产生一个准 Leader，节点在一开始都处于选举阶段，只要有一个节点得到超过半数节点的票数，那么它就可以当选准Leader，只有到达第三阶段（同步阶段）这个准Leader才会成为真正的Leader。
2）发现阶段
在该阶段中 Follower 和上一阶段选举出的准 Leader 进行通信，同步 Follower 最近接收的事务提议。这一阶段的目的是发现当前大多数节点接收的最新提议，并且准 Leader 生成新 的epoch，然后让 Follower 接收，更新它们的acceptedEpoch。
如果节点1认为节点L是 Leader，那么当节点1尝试连接节点L时，如果连接遭到拒绝，则集群将会重新进入选举阶段。
3）同步阶段
同步阶段主要是将 Leader 在前一阶段获得的最新提议信息同步到集群中所有的副本。并且只有当超过半数的节点都同步完成后，准 Leader 才会成为真正的 Leader 。Follower 只会接收 Zxid比自己 lastZxid 大的提议。
同步完成之后，集群的选主操作才算完成，新的 Leader 将产生。
4）广播阶段
在该阶段，ZooKeeper 集群正式对外提供事务服务，这时 Leader 进行消息广播，将其上的状态通知到其他 Follower。若后续有新的节点加入进来，则 Leader 会对新节点进行状态同步。
以上是本期分享，如有帮助请
点关注
支持下哦～
下期继续讲解 ZooKeeper 内容。
可扫码关注
