ZAB协议详解

浅识ZooKeeper

ZooKeeper是一个开放源代码的分布式协调服务，由知名互联网公司雅虎创建，是Google Chubby的开源实现。ZooKeeper的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。

ZooKeeper是什么

ZooKeeper是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。

ZooKeeper可以保证如下分布式一致性特性

• 顺序一致性：从同一个客户端发起的事务请求，最终将会严格地按照其发起顺序被应用到ZooKeeper 中去。
• 原子性：所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说要么整个集群所有机器都成功应用了某一个事务，要么都没有应用，一定不会出现集群中部分机器应用了该事务，而另外一部分没有应用的情况。
• 单一视图：无论客户端连接的是哪个ZooKeeper服务器，其看到的服务端数据模型都是一致的。
• 可靠性：一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会被一直保留下来，除非有另一个事务又对其进行了变更。
• 实时性：通常人们看到实时性的第一反应是，一旦一个事务被成功应用，那么客户端能够立即从服务端上读取到这个事务变更后的最新数据状态。==这里需要注意的是，ZooKeeper仅仅保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态==。

ZooKeeper的设计目标

ZooKeeper 致力于提供一个高性能、高可用，且具有严格的顺序访问控制能力(主要是写操作的严格顺序性)的分布式协调服务。

高性能 → 使得ZooKeeper能够应用于那些对系统吞吐有明确要求的大型分布式系统中

高可用 → 使得分布式的单点问题得到了很好的解决

严格的顺序访问 → 使得客户端能够基于ZooKeeper实现一些复杂的同步原语

目标一：简单的数据模型

ZooKeeper使得分布式程序能够通过一个共享的、树型结构的名字空间来进行相互协调。这里所说的树型结构的名字空间，是指ZooKeeper 服务器内存中的一个数据模型，其由一系列被称为ZNode的数据节点组成，总的来说，其数据模型类似于一个文件系统，而ZNode 之间的层级关系，就像文件系统的目录结构一样。不过和传统的磁盘文件系统不同的是，ZooKeeper将全量数据存储在内存中，以此来实现提高服务器吞吐、减少延迟的目的。

目标二：可以构建集群

一个ZooKeeper 集群通常由一组机器组成，一般3~5台机器就可以组成一个可用的ZooKeeper 集群。

组成ZooKeeper集群的每台机器都会在内存中维护当前的服务器状态，并且每台机器之间都互相保持着通信。值得一提的是，只要集群中存在超过一半的机器能够正常工作，那么整个集群就能够正常对外服务。

ZooKeeper的客户端程序会选择和集群中任意一台机器共同来创建一个TCP连接,而旦客户端和某台 ZooKeeper 服务器之间的连接断开后,客户端会自动连接到集群中的其他机器。

目标三：顺序访问

对于来自客户端的每个更新请求，ZooKeeper都会分配一个全局唯一的递增编号，这个编号反映了所有事务操作的先后顺序，应用程序可以使用ZooKeeper的这个特性来实现更高层次的同步原语。

目标四：高性能

由于ZooKeeper 将全量数据存储在内存中，并直接服务于客户端的所有非事务请求，因此它尤其适用于以读操作为主的应用场景。作者曾经以3台3.4.3版本的ZooKeeper服务器组成集群进行性能压测，100%读请求的场景下压测结果是12~13W的QPS。

ZooKeeper的基本概念

这里先对ZooKeeper的几个概念做一下了解，方便后面深入ZAB协议

集群角色

传统的集群模式：Master/Slave模式(主备模式)。在这种模式中，我们把能够处理所有写操作的机器称为Master机器,把所有通过异步复制方式获取最新数据,并提供读服务的机器称为Slave 机器。

ZooKeeper中，这些概念被颠覆了。它没有沿用传统的Master/Slave 概念，而是引入了Leader、Follower和Observer 三种角色。

ZooKeeper 集群中的所有机器通过一个Leader 选举过程来选定一台被称为“Leader”的机器，Leader 服务器为客户端提供读和写服务。除Leader外，其他机器包括Follower和Observer。

Follower和 Observer 都能够提供读服务，唯一的区别在于，Observer机器不参与Leader选举过程，也不参与写操作的“过半写成功”策略，因此Observer 可以在不影响写性能的情况下提升集群的读性能。

会话(Session)

Session是指客户端会话，在ZooKeeper 中,一个客户端连接是指客户端和服务器之间的一个TCP长连接。ZooKeeper对外的服务端口默认是 2181,客户端启动的时候,首先会与服务器建立一个TCP连接,从第一次连接建立开始，客户端会话的生命周期也开始了，通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能够向ZooKeeper服务器发送请求并接受响应,同时还能够通过该连接接收来自服务器的Watch事件通知。

Session的sessionTimeout值用来设置一个客户端会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在sessionTimeout规定的时间内能够重新连接上集群中任意一台服务器,那么之前创建的会话仍然有效。

数据节点(Znode)

在谈到分布式的时候，我们通常说的“节点”是指组成集群的每一台机器。然而，在ZooKeeper中,“节点”分为两类。

• 第一类同样是指构成集群的机器，我们称之为机器节点。
• 第二类则是指数据模型中的数据单元，我们称之为数据节点——ZNode。

ZooKeeper将所有数据存储在内存中，数据模型是一棵树(ZNodeTree)，由斜杠(/)进行分割的路径，就是一个Znode，例如*/foo/path1*。每个ZNode 上都会保存自己的数据内容，同时还会保存一系列属性信息。

在ZooKeeper中，ZNode可以分为持久节点和临时节点两类。

• 持久节点是指一旦这个ZNode 被创建了，除非主动进行ZNode的移除操作，否则这个ZNode 将一直保存在ZooKeeper上。
• 临时节点就不一样了，它的生命周期和客户端会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会被移除。

ZooKeeper还允许用户为每个节点添加一个特殊的属性:SEQUENTIAL。一旦节点被标记上这个属性，那么在这个节点被创建的时候，ZooKeeper会自动在其节点名后面追加上一个整型数字，这个整型数字是一个由父节点维护的自增数字。

版本

ZooKeeper的每个ZNode上都会存储数据，对应于每个ZNode，ZooKeeper 都会为其维护一个叫作Stat的数据结构，Stat中记录了这个ZNode 的三个数据版本

• version(当前ZNode的版本)
• cversion(当前ZNode 子节点的版本)
• aversion(当前 ZNode的 ACL 版本)

Watcher

Watcher(事件监听器)，是ZooKeeper中的一个很重要的特性。ZooKeeper允许用户在指定节点上注册一些 Watcher，并且在一些特定事件触发的时候，ZooKeeper 服务端会将事件通知到感兴趣的客户端上去，该机制是ZooKeeper实现分布式协调服务的重要特性。

ACL

ZooKeeper采用ACL(Access Control Lists)策略来进行权限控制，类似于 UNIX 文件系统的权限控制。

ZooKeeper定义了如下5种权限：

• CREATE：创建子节点的权限。
• READ：获取节点数据和子节点列表的权限。
• WRITE：更新节点数据的权限。
• DELETE：删除子节点的权限。
• ADMIN：设置节点ACL的权限。

CREATE 和 DELETE 这两种权限都是针对子节点的权限控制。

为什么要选择ZooKeeper

• 在解决分布式数据一致性上，除了ZooKeeper 之外，目前还没有一个成熟稳定且被大规模应用的解决方案。ZooKeeper无论从性能、易用性还是稳定性上来说，都已经达到了一个工业级产品的标准。
• ZooKeeper是开放源代码的，所有人都在关注它的发展，都有权利来贡献自己的力量，你可以和全世界成千上万的ZooKeeper 开发者们一起交流使用经验，共同解决问题。
• ZooKeeper是免费的，你无须为它支付任何费用。这点对于一个小型公司，尤其是初创团队来说，无疑是非常重要的。
• ZooKeeper已经得到了广泛的应用。越来越多的大型分布式项目都已经将ZooKeeper作为其核心组件，用于分布式协调。

ZAB协议简介

ZooKeeper Atomic Broadcast(ZAB，ZooKeeper原子消息广播协议)，ZAB协议是为分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复的原子广播协议。它是一种特别为ZooKeeper 设计的崩溃可恢复的原子消息广播算法。

在ZooKeeper中,主要依赖ZAB协议来实现分布式数据一致性,基于该协议,ZooKeeper实现了一种主备模式的系统架构来保持集群中各副本之间数据的一致性。

ZAB协议包括两种基本的模式，分别是崩溃恢复和消息广播

ZAB协议的核心是定义了对于那些会改变ZoKeeper服务器数据状态的事务请求的处理方式，即：

所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，而余下的其他服务器则成为 Follower 服务器。Leader 服务器负责将一个客户端事务请求转换成一个事务 Proposal(提议)，并将该Proposal分发给集群中所有的Follower 服务器。之后 Leader 服务器需要等待所有 Follower 服务器的反馈，一旦超过半数的 Follower 服务器进行了正确的反馈后，那么 Leader 就会再次向所有的 Follower服务器分发Commit消息，要求其将前一个Proposal进行提交。

消息广播

ZAB协议的消息广播过程使用的是一个原子广播协议，类似于一个二阶段提交过程。针对客户端的事务请求，Leader服务器会为其生成对应的事务Proposal，并将其发送给集群中其余所有的机器，然后再分别收集各自的选票，最后进行事务提交。

整个消息广播协议是基于具有FIFO特性的TCP协议来进行网络通信的，因此能够很容易地保证消息广播过程中消息接收与发送的顺序性。

在整个消息广播过程中，Leader服务器会为每个事务请求生成对应的Proposal来进行广播，并且在广播事务Proposal之前，Leader服务器会首先为这个事务Proposal分配一个全局单调递增的唯一ID，我们称之为事务ID(即ZXID)。由于ZAB协议需要保证每一个消息严格的因果关系，因此必须将每一个事务Proposal按照其ZXID的先后顺序来进行排序与处理。

在消息广播过程中，Leader服务器会为每一个Follower服务器都各自分配一个单独的队列，然后将需要广播的事务Proposal依次放入这些队列中去，并且根据FIFO策略进行消息发送。每一个Follower服务器在接收到这个事务Proposal之后，都会首先将其以事务日志的形式写入到本地磁盘中去,并且在成功写入后反馈给Leader服务器一个Ack 响应。当Leader服务器接收到超过半数Follower的Ack 响应后，就会广播一个Commit 消息给所有的Follower 服务器以通知其进行事务提交，同时Leader 自身也会完成对事务的提交，而每一个Follower服务器在接收到Commit消息后，也会完成对事务的提交。

崩溃恢复

ZAB协议的这个基于原子广播协议的消息广播过程，在正常情况下运行非常良好，但是一旦Leader服务器出现崩溃，或者说由于网络原因导致Leader服务器失去了与过半Follower的联系，那么就会进入崩溃恢复模式。

在ZAB协议中，为了保证程序的正确运行，整个恢复过程结束后需要选举出一个新的Leader 服务器。因此，ZAB协议需要一个高效且可靠的Leader 选举算法从而确保能够快速地选举出新的Leader。同时，Leader 选举算法不仅仅需要让Leader自己知道其自身已经被选举为Leader,同时还需要让集群中的所有其他机器也能够快速地感知到选举产生的新的Leader 服务器。

基本特性

ZAB 协议需要确保那些已经在 Leader服务器上提交的事务最终被所有服务器都提交

假设一个事务在Leader服务器上被提交了，并且已经得到过半Follower 服务器的Ack反馈，但是在它将Commit消息发送给所有Follower机器之前，Leader服务器挂了。

C2就是一个典型的例子:在集群正常运行过程中的某一个时刻，Server1是 Leader 服务器，其先后广播了消息P1、P2、C1、P3和C2，其中，当Leader 服务器将消息C2发出后就立即崩溃退出了。针对这种情况，ZAB协议就需要确保事务Proposal2最终能够在所有的服务器上都被提交成功，否则将出现不一致。

ZAB 协议需要确保丢弃那些只在Leader服务器上被提出的事务

如果在崩溃恢复过程中出现一个需要被丢弃的提案,那么在崩溃恢复结束后需要跳过该事务Proposal。

假设初始的Leader服务器Server1在提出了一个事务Proposal3之后就崩溃退出了，从而导致集群中的其他服务器都没有收到这个事务Proposal。于是，当Serverl恢复过来再次加入到集群中的时候，ZAB协议需要确保丢弃Proposal3这个事务。

结合上面分析，Leader选举算法必须遵从：能够确保提交已经被Leader提交的事务Proposal，同时丢弃已经被跳过的事务Proposal。

如果让Leader选举算法能够保证新选举出来的Leader服务器拥有集群中所有机器最高编号(即ZXID最大)的事务Proposal那么就可以保证这个新选举出来的Leader 一定具有所有已经提交的提案。更为重要的是如果让具有最高编号事务Proposal的机器来成为Leader，就可以省去Leader服务器检查Proposal的提交和丢弃工作的这一步操作了。

下期预告：

• 更加深入的理解ZAB协议