zookeeper核心之ZAB协议就是这么简单！

背景

咱们都知道 Zookeeper 是基于 ZAB 协议实现的，在介绍 ZAB 协议以前，先回顾一下 Zookeeper 的起源与发展。java

Zookeeper 到底是在什么样的时代背景下被提出？为了解决了哪些棘手的问题？面试

Zookeeper 最先起源于雅虎研究院的一个研究小组。当时，研究人员发现，在雅虎的不少大型系统基本都须要依赖一个相似的系统来进行分布式协调，可是这些系统都存在分布式单点问题，因此雅虎的开发人员就试图开发出一个通用的无单点问题的分布式协调框架，以便让开发人员将精力集中在处理业务逻辑上。算法

因而，Zookeeper 就诞生了！数据库

Zookeeper 的出现不只解决了分布式系统下数据一致性的问题，并且经历过线上验证，不管是从性能、易用性、稳定性上来讲，都是工业级产品的标准。能够说在分布式系统中具备不可替代的核心地位，Hadoop、HBase、Storm 和 Solr 等大型分布式系统都已经将 Zookeeper 做为其核心组件，用于分布式协调。即使 Zookeeper 如此优秀，可是 Zookeeper 依然是免费且开源的，全世界成千上万的开发者都关注着它，陪同着一块儿成长和发展。缓存

做为一个开发者不管是为了应付面试、晋升仍是我的技术成长的须要，都须要对 Zookeeper 有所了解，而学习 Zookeeper 的关键就是理解其核心部分：服务器

ZAB 协议，全称（Zookeeper Atomic Broadcast）Zookeeper 原子消息广播协议。微信

它与 Paxos 相似，也是一种数据一致性的算法。网络

Zookeeper应该具有的特性

在 ZAB 协议的开发设计人员在协议设计之初并无要求 ZAB 具备很好的扩展性，最初只是为了雅虎公司内部哪些高吞吐量、低延迟、健壮、简单的分布式系统场景设计的。基于 ZAB 协议，Zookeeper 实现了一种主备模式的系统架构来保持集群中各副本之间数据的一致性，简单架构图以下：架构

Zookeeper 用一个单一的主进程来接收并处理客户端的全部事物请求，并采用 ZAB 的原子广播协议将服务器数据状态以事物 Proposal 的形式广播到全部的副本进程中去。这样的模式就保证了，在同一时刻只有一个主进程来广播服务器的状态更变，所以可以很好地处理客户端大量的并发请求，这在 ZAB 协议中叫：消息广播。并发

除此以外，在分布式环境中事物的执行顺序也会存在必定的前后关系，好比：事务 C 的写入须要依赖事务 B 的写入，而事务 B 写入须要依赖事务 A 写入。这种先后依赖的顺序也对 ZAB 协议提出了一个要求：ZAB 协议须要保证若是一个状态的变动被处理了，那么全部其依赖的状态变动都已经被提早处理了。也就是须要顺序执行。

另外除了能正常广播消息、消息的顺序执行，主进程也可能随时会由于断电、机器宕机等异常状况没法提供服务，所以，ZAB 协议还须要作到在当前主进程出现上述异常状况的时候依然可以正常工做，这在 ZAB 协议中叫：崩溃恢复。

因此整个 ZAB 协议须要具有的核心特性已经被描述出来了，处理事务的请求的方式能够简单理解为：

> 全部的事务请求必须由一个全局惟一的服务器来协调处理，这样的服务器叫：Leader 服务器。其余的服务器被称为 Follower 服务器。Leader 服务器将客户端事务请求转化成一个事务 Prososal（提议），并将改 Proposal 分发给集群中全部的 Follower 服务器。以后 Leader 服务器接收了正确的反馈后，那么 Leader 就会再次向全部的 Follower 服务器分发 Commit 消息，要求将前一个 Proposal 提交。

这就简单阐述了ZAB 协议中消息广播模式的部份内容。

ZAB协议的两种模式

ZAB 协议的包括两种模式：崩溃恢复、消息广播。

既然有两种模式，那 Zookeeper 集群何时进入奔溃恢复模式？何时进入消息广播模式呢？

在进入奔溃恢复模式时 Zookeeper 集群会进行 Leader 选举，通常有两种状况会发生选举：

当服务器启动时期会进行 Leader 选举。
当服务器运行期 Leader 服务器的出现网络中断、奔溃退出、重启等异常状况，或者当集群中半数的服务器与该 Leader 服务器没法通讯时，进入崩溃恢复模式，开始 Leader 选举。

选举出 Leader 服务器后，会进入消息广播模式，开始接收处理客户端的请求，前文已经描述，这里再也不赘述。

消息广播模式

知道了这些名词，和上文提到的零散的知识点，其实崩溃恢复模式和消息广播模式的过程你们大体有所了解了。

先看看消息广播模式吧！

消息广播的模式的过程简图以下所示：

整个过程相似一个二阶段提交的过程，但却有所不一样，ZAB 协议简化了二阶段提交模型，在超过半数的 Follower 服务器已经反馈 ACK 以后就开始提交事务 Prososal 了，无需等待全部服务器响应。

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

Leader 服务器接收到请求后在进行广播事务 Proposal 以前会为这个事务分配一个 ZXID，再进行广播。
Leader 服务器会为每一个 Follower 服务器都各自分配一个单独的队列，而后将须要广播的事务 Proposal 依次放入这些队列中去，并根据 FIFO 策略进行消息的发送。
每一个Follower 服务器在接收到后都会将其以事务日志的形式写入到本地磁盘中，而且在成功写入后返回 Leader 服务器一个 ACK 响应。
当有超过半数的服务器 ACK 响应后，Leader 就会广播一个 Commit 消息给全部的 Follower 服务器，Follower 接收到后就完成对事务的提交操做。

在画一张详细点的流程图，更直观：

这就完成了整个消息广播了！

崩溃恢复模式

前文已经反复提过崩溃恢复模式了，其实就是从新选举出新的 Leader 服务器，选举完成后 Follower 服务器在再去同步 Leader 的数据。

运行中的服务再次进行从新选举，必定是出现某种异常，咱们知道在出现异常状况以前 Leader 的消息广播可能会处在任何一个阶段，有可能客户端的请求只是在 Leader 服务器上提出并未被提交，也可能请求已经被 Leader 服务器提交。

ZAB 协议对于不一样阶段的出现的数据不一致的状况作了兼容，保证：

已经在 Leader 服务器上提交的事务，最终会被全部服务器都提交
只在 Leader 服务器上提出的事务，要丢弃

针对以上的两个要求，在进行 Leader 选举时，之须要选举出集群中 ZXID 最大的事务 Proposal 便可，这样就能够省去 Leader 服务器检查 Proposal 的提交和丢弃工做了。由于 Leader 服务器的事务是最大的，一切以 Leader 服务器的数据为标准便可。

ZXID 在集群中其实并非惟一的，因此也有可能出现多 Follower 服务器 ZXID 相同的状况，这时候就须要比较 Zookeeper 的 SID 值。什么是 SID？SID 是一个数字，和 zookeeper 的 myid 一致，myid 就不要解释了，安装过 Zookeeper 的都知道，每台服务器都须要配置一个这样的文件，里面只有一个数字，用来标识这台服务器。由于每台机器的 myid 配置都不同，因此集群选举的时不会出现相等的状况。

选举时，比较大小的源码以下：

前面已经说过，出现选举 Leader 可能会出现两种状况：

服务启动时期，发起选举
服务运行期间，出现异常，发起选举

但不管是启动期仍是运行期进行 Leader 选举，其选举过程都差不太多，我简单画个流程图：

结合上图，奔溃恢复模式下 Leader 选举的过程细节以下：

检测节点处于 LOOKING 阶段，开发选举 Leader
发起投票时有两种状况：
- 在服务启动的初始阶段，每一个服务器都会投票给本身以（myid，zxid）的信息形式发送，那初始阶段没有 zxid 值，就会发送（myid，0）
- 在服务器运行期间，每一个服务器上的 zxid 都有值，且 zxid 都不相同，因此就正常发送（myid，zxid）
各节点收到信息后将收到的（myid，zxid）和本身的比较，比较的过程前面已经说过，这里再也不赘述
而后判断是否有半数的机器投票选出 Leader，若是否，在进入新一轮投票，直到选出
选出 Leader 后，其余节点就变成 Follower 角色，并向 Leader 发送本身服务器的最大 zxid ，Leader 服务器收到后会和本身本地的提议缓存队列进行比较，判断使用那种策略进行同步（后面详细说明同步的四种策略）
当同步完成，集群就能够正常的处理请求了，就进入消息广播模式了。

这就是崩溃恢复模式下选举 Leader 的过程了！

下面再简单介绍下数据同步的四种策略，这四种同步策略保证了Zookeeper 集群中的数据一致性，也解决了前文提出的两个问题，兼容了各类数据不一致的场景。

数据同步的四种策略

在数据同步以前，Leader 服务器会进行数据同步的初始化，首先会从 Zookeeper 的内存数据库中提取出事务前期对应的提议缓存队列，同时会初始化三个 ZXID 的值：

peerLastZxid：这是 Follower 的最后处理 ZXID
minCommittedLog：Leader 服务器的提议缓存队列中最小的 ZXID
maxCommittedLog：Leader 服务器的提议缓存队列中最大的 ZXID

根据这三个参数，就能够肯定四种同步方式，分别为：

直接差别化同步
- 场景：当 minCommittedLog < peerLastZxid < maxCommittedLog 时
先回滚在差别化同步
- 场景：假如集群有 A、B、C 三台机器，此时 A 是 Leader 可是 A 挂了，在挂以前 A 生成了一个提议假设是：03，而后集群有从新选举 B 为新的 Leader，此时生成的的提议缓存队列为：01~02，B 和 C 进行同步以后，生成新的纪元，ZXID 从 10 开始计数，集群进入广播模式处理了部分请求，假设如今 ZXID 执行到 15 这个值，此时 A 恢复了加入集群，这时候就比较 A 最后提交的 ZXID：peerLastZxid 与 minCommittedLog、maxCommittedLog 的关系。此时虽然符合直接差别化同步：minCommittedLog < peerLastZxid < maxCommittedLog 这样的关系，可是提议缓存队列中却没有这个 ZXID ，这时候就须要先回滚，在进行同步。
仅回滚同步
- 场景：这里和先回滚在差别化同步相似，直接回滚就能够。
全量同步
- 场景：peerLastZxid < minCommittedLog，当远远落后 Leader 的数据时，直接全量同步。

这就是四种同步策略，这几种同步方式也解决了上文提出的问题：

只在 Leader 服务器上提出的事务，要丢弃（这个问题会在同步时，会进行回滚，使得只在 Leader 服务器上提出的事务丢弃）

这些就是整个 ZAB 协议中崩溃恢复的内容。

ZAB协议和Paxos算法的区别

ZAB协议看起来和Paxos有着相同之处，但它并非Paxos的典型实现，其实仍是有一些区别，ZAB协议中额外添加了一个同步的阶段，二者设计目标也不太同样，ZAB协议主要用于构建一个高可用的分布式数据主备系统，而Paxos算法则是用于构建一个分布式一致性的状态机。

总结

Zookeeper 做为出色的分布式协调服务，目前读 QPS 达到 12w，出色的性能也让开发者更加青睐，其 ZAB 协议的核心分为两个部分：崩溃恢复、消息广播。

典型的应用场景有：

数据发布/订阅、负载均衡
命名服务
分布式协调通知
集群管理
Master选举
分布式锁
分布式队列
用 Zookeeper 避免脑裂

除此以外在大数据领域也有应用，例如：

Hadoop
HBase
Kafka

在阿里巴巴集团内部实践的 Zookeeper 的产品也有不少，如：

消息中间件：Metamorphosis
RPC 服务框架：Dubbo
基于 MySQL Binlog 的增量订阅和消费组件：Cancel
分布式数据库同步系统：Otter
实时计算引擎：JStorm

你知道的越多，你不知道的越多，我是帅帅，一个在互联网苟且偷生的工具人，欢迎关注个人技术微信公众号：java之旅

zookeeper核心之ZAB协议就是这么简单！

背景

Zookeeper应该具有的特性

ZAB协议的两种模式

相关名词概念

三种角色

三种状态

ZXID

消息广播模式

崩溃恢复模式

数据同步的四种策略

ZAB协议和Paxos算法的区别

总结