ZooKeeper为分布式应用提供了高效且可靠的分布式协调服务，提供了诸如tong’yi统一命名服务、配置管理和分布式锁等分布式的基础服务。在解决分布式数据一致性方面，ZooKeeper并没有直接采用Paxos算法，而是采用了一种被称为ZAB（ZooKeeper Atomic Broadcast）的一致性协议。

一、初始ZooKeeper

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

1. ZooKeeper介绍

1.1 ZooKeeper是什么

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

顺序一致性

从同一个客户端发起的事务请求，最终将会严格按照其发起顺序被应用到ZooKeeper中去。

原子性

所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群所有机器都成功应用了某一个事务，要么都没有应用，一定不会出现集群中部分机器应用了该事务，而另外一部分没有应用的情况。

单一视图（Single System Image）

无论客户端连接的是哪个ZooKeeper服务器，其看到的服务端数据模型都是一致的。

可靠性

一旦服务端成功应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更会被一直保留下来，除非有另一个事务又对其进行了变更。

实时性

通常人们看到实时性的第一反应是，一旦一个事务被成功应用，那么客户端能够立即从服务端上读取到这个事务变更后的最新数据状态。这里需要注意的是，ZooKeeper仅仅保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。

1.2 ZooKeeper的设计目标

ZooKeeper致力于提供一个高性能、高可用，且具有严格的顺序访问控制能力（主要是写操作的严格顺序性）的分布式协调服务。高性能使得ZooKeeper能够应用于那些对系统吞吐有明确要求的大型分布式系统中，高可用使得分布式的单点问题得到了很好地解决，而严格的顺序访问控制使得客户端能够基于ZooKeeper实现一些复杂的同步原语。

目标一：简单的数据模型

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

目标二：可以构建集群

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

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

目标三：顺序访问

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

目标四：高性能

由于ZooKeeper将全量数据存储在内存中，并直接服务于客户端的所有非事务请求，因此它尤其适用于以读操作为主的应用场景。

1.2 ZooKeeper从何而来

大型动物园的故事

1.3 ZooKeeper的基本概念

集群角色

最典型的集群模式使Master/Slave模式（主从模式），这种模式中，能够处理所有鞋操作的机器成为Master机器，把所有通过异步复制方式获取最新数据，并提供读服务的机器成为Slave机器。

而在ZooKeeper中，引用了Leader、Follower和Observer三种角色。ZooKeeper集群的所有机器通过一个leader选举过程选定一台被称为“Leader”的机器，Leader服务器为客户端提供读和写服务。除Leader外，其他机器包括Follower和Observer。Follower和Observer都能提供读服务，唯一的区别在于，Observer机器不参与Leader选举过程，也不参与写操作的“过半写成功”策略，因此Observer可以在不影响写性能的情况下提升集群的读性能。

会话（Session）

在ZooKeeper中，一个客户端连接是指客户端和服务器之间的一个TCP长连接。ZooKeeper对外的服务端口默认是2181，客户端启动的时候，首先会与服务器建立一个TCP连接，从第一次连接建立开始，客户端会话的生命周期也开始了，通过这个连接，客户端能够通过心跳监测与服务器保持有效的会话，也能够向ZooKeeper服务器发送请求并接受响应，通过还能够通过该连接接收来自服务器的Watch事件通知。Session的sessionTimeout值用来设置一个客户端会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在sessionTimeout规定的时间内能够重新连上集群中任意一台服务器，那么值钱创建的会话仍然有效。

数据节点（Znode）

在ZooKeeper中，“节点”分为两类，第一类同样是构成集群的机器节点；第二类则是数据模型中的数据单元，我们称之为数据节点–ZNode。ZooKeeper将所有数据存储在内存中，数据模型是一棵树（ZNode Tree），由斜杠（/）进行分割的路径，就是一个Znode。每个ZNode上都会保存自己的数据内容，同时还会保存一系列属性信息。

ZNode可以分为持久节点和临时节点两类。所谓持久节点是指一旦这个ZNode被创建了，除非主动进行移除操作，否则这个ZNode将一直保存在ZooKeeper上。而临时节点的生命周期和客户端会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会被移除。另外，ZooKeeper还允许用户为每个节点添加一个特殊的属性：SEQUENTIAL。一旦节点被标记上这个属性，那么这个节点被创建的时候，ZooKeeper会自动在其节点名后面追加上一个整形数字，这个整型数字是一个由父节点维护的自增数字。

版本

对于每个ZNode，ZooKeeper都会为其维护一个叫做Stat的数据结构，Stat中记录了这个ZNode的三个数据版本，分别是version(当前ZNode的版本)、cversion(当前ZNode子节点的版本)和aversion(当前ZNode的ACL版本)。

Watcher

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

ACL（Access Control Lists）

实现权限控制，定义了5种权限：

• CREATE
• READ
• WRITE
• DELETE
• ADMIN

1.4 为什么选择ZooKeeper

• 已经达到了一个工业级产品的标准
• 开放源代码
• 免费
• 已经得到了广泛的应用，诸如Hadoop、HBase、Storm和Solr。

二、ZooKeeper的ZAB协议

2.1 ZAB协议

ZooKeeper并没有完全采用Paxos算法，而是使用了一种称为ZooKeeper Atomic Broadcast（ZAB，ZooKeeper原子消息广播协议）的协议作为其数据一致性的核心算法。ZAB协议是为分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复的原子广播协议。

在ZooKeeper中，主要依赖ZAB协议来实现分布式数据一致性，基于该协议，ZooKeeper实现了一种主备模式的系统架构来保持集群中各副本之间的数据一致性。具体的，ZooKeeper使用一个单一的主进程来接收并处理客户端的所有事务请求，并采用ZAB的原子广播协议，将服务器数据的状态变更为事务Proposal的形式广播到所有的副本进程上去。ZAB协议的这个主备模型架构保证了同一时刻集群中只能够有一个主进程来广播服务器的状态变更，因此能够很好地处理客户端大量的并发请求。另一方面，考虑到在分布式环境中，顺序执行的一些状态变更其前后会存在一定的依赖关系，有些状态变更必须依赖于比他早生成的那些状态变更。这样的依赖关系也对ZAB协议提出了一个要求：ZAB协议必须保证一个全局的变更序列被顺序应用，也就是说，ZAB协议需要保证如果一个状态变更已经被处理了，那么所有其依赖的状态变更都应该已经被提前处理掉了。最后，考虑到主进程在任何时候都有可能出现崩溃退出或重启现象，因此，ZAB协议还需要坐到在当前主进程出现上述异常情况时，依旧能够正常工作。

2.2 协议介绍

ZAB协议包括两种基本的模式：崩溃恢复和消息广播。当服务框架在启动过程中，或是当Leader服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB协议就会进入恢复模式并选举产生新的Leader。当Leader产生，同时集群中过半机器与该Leader服务器完成状态同步之后，ZAB就会退出恢复模式。

当集群中有过半的Follower和Leader完成状态同步后，那么整个服务框架就可以进入消息广播模式了。

消息广播

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

崩溃恢复

一旦Leader服务器出现崩溃，或者由于网络原因导致leader服务器失去了与过半Follower的联系，就会进入崩溃恢复模式。在ZAB协议中，为了保证程序的正确运行，整个恢复过程结束后需要选举出一个新的Leader服务器。因此，ZAB协议需要一个高效且可靠的Leader选举算法，从而确保能够快速的选举出新的leader。同时，Leader选举算法不仅仅需要让Leader自己知道其自身已经被选举为Leader，同时还需要让集群中的所有其他机器也快速的感知到选举产生的新的Leader服务器。

基本特性

• ZAB协议需要确保那些已经在Leader服务器上提交的事务最终被所有服务器都提交。
• ZAB协议需要确保丢弃那些知道Leader服务器上被提出的事务。

数据同步

2.3 深入ZAB协议

系统模型

我们使用Pi和Pj分别表示两个不同进程，使用Cij表示进程Pi和Pj之间的wa通信通道，并满足如下两个基本特性。

• 完整性(Integrity)

进程Pj如果收到来自进程Pi的消息m，那么进程Pi一定确实发送了消息m。

• 前置性(Prefix)

所有的消息都必须按照严格的先后顺序来处理。

问题描述

主进程周期

为了保证主进程每次广播出来的事务消息都是一致的，我们必须确保ZAB协议只有在充分完成崩溃恢复阶段之后，新的主进程才可以开始生成新的事务消息广播。为了实现这个目的，我们假设各个进程都实现了类似于ready(e)这样的一个函数调用，在运行过程中，ZAB协议能够非常明确的告知上层系统是否可以开始进行事务消息的广播，同时，在调用ready(e)函数之后，ZAB还需要为当前主进程设置一个实例值。实例值用于唯一标识当前主进程的周期，在进行消息广播时，主进程使用该实例值来设置事务标识中的epoch字段–当然，ZAB需要保证实例值在不同的主进程周期中是全部唯一的。

事务

我们假设各个进程都存在一个类似于transactions(v,z)这样的函数调用，来实现主线程对状态变更的广播。主进程每次对transaction(v,z)函数的调用都包含了两个字段：实物内容v和事务标识z，而每一个事务标识z=<e,c>也包含两个组成部分，前者是主进程周期e，后者是当前主进程周期内的事务计数c。我们使用epoch(z)来表示一个事务标识中的主进程周期epoch，使用counter(z)来表示事务标识中的事务计数。

算法描述

整个ZAB协议主要包括消息广播和崩溃恢复两个过程，进一步可以细分为三个阶段，分别是发现(Discovery)、同步(Synchronization)和广播(Broadcast)。组成ZAB协议的每一个分布式进程，会循环的执行这三个阶段，我们将这样一个循环称为一个主进程后期。

运行分析

在ZAB协议的设计中，每一个进程都有可能处于以下三种状态之一。

• LOOKING:Leader选举阶段
• FOLLOWING:Follower服务器和Leader保持同步状态
• LEADING:Leader服务器作为主进程领导状态

2.4 ZAB和Paxos算法的联系和区别

联系

• 两者都存在一个类似于Leader进程的角色，由其负责协调多个Follower进程的运行。
• Leader进程都会等待超过半数的Follower做出正确的反馈后，才会将一个提案进行提交。
• 在ZAB协议中，每个Proposal都包含一个epoch值，用来代表当前的Leader周期，在Paxos算法中，同样存在这样的一个标识，只是名字变成了Ballot。

本质区别

两者设计目标不太一样。ZAB协议主要用于构建一个高可用的分布式数据主备系统，而Paxos算法则是用于构建一个分布式的一致性状态机系统。