ZooKeeper 简介

1、概念介绍

ZooKeeper 是一个开放源码的分布式应用程序协调服务，为分布式应用提供一致性服务的软件，由雅虎创建，是 Google Chubby 的开源实现，是 Apache 的子项目，之前是 Hadoop 项目的一部分，使用 Java 实现。

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

ZooKeeper 最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心（服务注册与发现中心）。服务生产者将自己提供的服务注册到 ZooKeeper 中心，服务的消费者在进行服务调用的时候先到 ZooKeeper 中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据。

ZooKeeper 的由来

Zookeeper 最早起源于雅虎研究院的一个研究小组。在当时，研究人员发现，在雅虎内部很多大型系统基本都需要依赖一个类似的系统来进行分布式协调，但是这些系统往往都存在分布式单点问题。所以，雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架，以便让开发人员将精力集中在处理业务逻辑上。

关于“ZooKeeper”这个项目的名字，其实也有一段趣闻。在立项初期，考虑到之前内部很多项目都是使用动物的名字来命名的（例如著名的 Pig 项目)，雅虎的工程师希望给这个项目也取一个动物的名字。时任研究院的首席科学家 Raghu Ramakrishnan 开玩笑地说：“在这样下去，我们这儿就变成动物园了！”

此话一出，大家纷纷表示就叫动物园管理员吧，因为各个以动物命名的分布式组件放在一起，雅虎的整个分布式系统看上去就像一个大型的动物园了。而 Zookeeper 正好要用来进行分布式环境的协调，于是，Zookeeper 的名字也就由此诞生了。

三种角色

① 领导者（leader），负责进行投票的发起和决议，更新系统状态。

② 学习者（learner），包括跟随者（follower）和观察者（observer）。

follower 用于接受客户端请求并向客户端返回结果，在选举过程中参与投票
Observer 可以接受客户端连接，将写请求转发给 leader，但 observer 不参加投票过程，只同步 leader 的状态，observer 的目的是为了扩展系统，提高读取速度

③ 客户端（client），请求发起方

一个 ZooKeeper 集群同一时刻只会有一个 Leader，ZooKeeper 集群的所有机器通过选举过程来选定一台被称为 Leader 的机器，Leader 服务器为客户端提供读和写服务。其他都是 Follower 或 Observer。

leader 负责客户端 writer 类型的请求,Follower 和 Observer 都能提供读服务，不能提供写服务。两者唯一的区别在于，Observer 不参与 Leader 选举过程，也不参与写操作的『过半写成功』策略，因此 Observer 可以在不影响写性能的情况下提升集群的读性能。

节点状态

每个集群中的节点都有一个状态 LOOKING, FOLLOWING, LEADING, OBSERVING。都属于这 4 种，每个节点启动的时候都是 LOOKING 状态，如果这个节点参与选举但最后不是 leader，则状态是 FOLLOWING，如果不参与选举则是 OBSERVING，leader的状态是 LEADING。

集群服务器数

ZooKeeper 官方建议集群服务器的数量为奇数，这是因为一个 ZooKeeper 集群如果要对外提供可用的服务，那么集群中必须要有过半的机器正常工作并且彼此之间能够正常通信。

基于这个特性，如果想搭建一个能够允许 N 台机器 down 掉的集群，那么就要部署一个由 2*N+1 台服务器构成的 ZooKeeper 集群。因此，一个由 3 台机器构成的 ZooKeeper 集群，能够在挂掉 1 台机器后依然正常工作，而对于一个由 5 台服务器构成的 ZooKeeper 集群，能够对 2 台机器挂掉的情况进行容灾。

注意：如果是一个由 6 台服务器构成的 ZooKeeper 集群，同样只能够挂掉 2 台机器，因为如果挂掉 3 台，剩下的机器就无法实现过半了。 zookeeper 有这样一个特性：集群中只要有超过过半的机器是正常工作的，那么整个集群对外就是可用的。

可伸缩性

ZooKeeper 为什么要引入 Observer 这个角色呢？其实在 ZooKeeper 中引入Observer，主要是为了使 ZooKeeper 具有更好的可伸缩性。那么，何为可伸缩性？

如果我们的工作负载可以通过给系统分配更多的资源来分担，那么这个系统就是可伸缩的；一个不可伸缩的系统却无法通过增加资源来提升性能，甚至会在工作负载增加时，性能会急剧下降。

Session

Session 是指客户端会话，在 ZooKeeper 中，客户端会话是指客户端和ZooKeeper 服务器之间的 TCP 长连接。

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

在为客户端创建会话之前，服务端首先会为每个客户端都分配一个 sessionID。sessionID 是Zookeeper 会话的一个重要标识，许多与会话相关的运行机制都是基于这个 sessionID 的。因此，无论是哪台服务器为客户端分配的 sessionID，都务必保证全局唯一。

2、ZNode

zookeeper 节点分类

在 ZooKeeper 中，节点分为两类:

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

znode 节点

ZooKeeper 将所有数据存储在内存中，维护一个类似文件系统的数据结构, 根节点为"/"，每个子目录都被称作为 znode(目录节点)，和文件系统一样，我们能够自由的增加、删除 znode，在一个 znode 下增加、删除子 znode，唯一的不同在于 znode是可以存储数据的。

ZooKeeper 数据模型的结构整体上可以看作是一棵树，每个节点称做一个 ZNode。每个 ZNode 都可以通过其路径唯一标识在每个 ZNode 上可存储少量数据(默认是 1M, 可以通过配置修改, 通常不建议在 ZNode 上存储大量的数据)

znode 四种类型

① PERSISTENT-持久化目录节点：客户端与 zookeeper 断开连接后，该节点依旧存在

② PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点：客户端与 zookeeper 断开连接后，该节点依旧存在，只是 Zookeeper 给该节点名称进行顺序编号。

③ EPHEMERAL-临时目录节点：客户端与 zookeeper 断开连接后，该节点被删除

④ EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点：客户端与 zookeeper 断开连接后，该节点被删除，只是 Zookeeper 给该节点名称进行顺序编号。

znode 版本

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

① version（当前 ZNode 的版本）

② cversion（当前 ZNode 子节点的版本）

③ aversion（当前 ZNode 的 ACL 版本）

Stat 里面的版本号表示的是对数据节点的内容、子节点列表或者 ACL 信息的修改次数。节点创建时 dataversion、aclversion，cversion 都为 0，每次修改响应内容其对应的版本号加 1。

Watcher

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

注意：ZooKeeper 中的 Watcher 是一次性的，即触发一次就会被取消，如果想继续 Watch 的话，需要客户端重新设置 Watcher。

ACL

ZooKeeper 采用 ACL（Access Control Lists）策略来进行权限控制。ZooKeeper 定义了如下 5 种权限:

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

注意：CREATE 和 DELETE 都是针对子节点的权限控制。

事务操作

ZooKeeper 中，能改变 ZooKeeper 服务器状态的操作称为事务操作。一般包括数据节点创建与删除、数据内容更新和客户端会话创建与失效等操作。对应每一个事务请求，ZooKeeper 都会为其分配一个全局唯一的事务 ID，用 ZXID 表示，每一个 ZXID 对应一次更新操作，从这些 ZXID 中可以间接地识别出

ZooKeeper 处理这些事务操作请求的全局顺序。由于 zxid 的递增性质, 如果 zxid1 小于 zxid2, 那么zxid1 肯定先于 zxid2 发生。

实际上，ZooKeeper 的每个节点维护着三个 zxid 值，为别为：cZxid、mZxid、pZxid。

cZxid：是该节点创建时所对应的事物 ID。
mZxid：是该节点最近一次被修改时所对应的事物 ID，与其子节点无关。
pZxid：是该节点的子节点最近一次被修改时的事物 ID。

3、ZooKeeper 工作原理

Zookeeper 的核心是原子广播，这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 Zab 协议。Zab 协议有两种模式，它们分别是恢复模式和广播模式。

恢复模式

① 当服务启动或者 leader 崩溃或者 leader 失去大多数的 follower，这时候zookeeper 进入恢复模式，恢复模式需要重新选举出一个新的 leader，让所有的 server 都恢复到一个正确的状态。

② 每个 Server 启动以后都询问其它的 Server 它要投票给谁。

③ 对于其他 server 的询问，server 每次根据自己的状态都回复自己推荐的 leader的 id 和上一次处理事务的 zxid（系统启动时每个 server 都会推荐自己）

④ 收到所有 Server 回复以后，就计算出 zxid 最大的哪个 Server，并将这个 Server 相关信息设置成下一次要投票的 Server

⑤ 计算这过程中获得票数最多的 server 为获胜者，如果获胜者的票数超过半数，则该 server 被选为 leader。否则，继续这个过程，直到 leader 被选举出来。

⑥ leader 就会开始等待 server 连接

⑦ Follower 连接 leader，将最大的 zxid 发送给 leader

⑧ Leader 根据 follower 的 zxid 确定同步点

⑨ 完成同步后，通知 follower 已经成为 uptodate 状态

⑩ Follower 收到 uptodate 消息后，又可以重新接受 client 的请求进行服务了

广播模式

一旦 leader 已经和过半数的 follower 进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个 server 加入 zookeeper 服务中，它会在恢复模式下启动，发现 leader，并和 leader 进行状态同步。待到同步结束，它也参与消息广播。Zookeeper 服务一直维持在 Broadcast 状态，直到 leader 崩溃了或者 leader失去了大部分的 followers 支持。广播模式需要保证 proposal 被按顺序处理，因此 zookeeper 采用了递增的事务 id号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了 zxid。

4、ZooKeeper 设计目标

ZooKeeper 是一种高性能、可扩展的服务。ZooKeeper 的读写速度非常快，并且读的速度要比写快。它具有如下特点：

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

② 原子性：所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。

③ 单一系统映像（最终一致性）：无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的。

④ 可靠性：可靠性方面使其不会成为单点故障。

⑤ 实时性：Zookeeper 保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper 不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用 sync() 接口。

5、ZooKeeper 应用场景

ZooKeeper 是一个高可用的分布式数据管理与协调框架。基于对 ZAB 算法的实现，该框架能够很好地保证分布式环境中数据的一致性。也是基于这样的特性，使得ZooKeeper 成为了解决分布式一致性问题的利器。

配置管理

zookeeper 提供了节点watch的功能，zookeeper 的 client（对外提供服务的 server）监控 zookeeper 上的节点（znode），当节点变动的时候，client 会收到变动事件和变动后的内容，基于 zookeeper 的这个特性，我们可以给服务器集群中的所有机器（client）都注册 watch 事件，监控特定 znode，节点中存储部署代码的配置信息，需要更新代码的时候，修改 znode 中的值，服务器集群中的每一台 server 都会收到代码更新事件，然后触发调用，更新目标代码。

现在有很多开源项目使用 Zookeeper 来维护配置，比如在 HBase 中，客户端就是连接一个 Zookeeper，获得必要的 HBase 集群的配置信息，然后才可以进一步操作。还有在开源的消息队列 Kafka 中，也使用 Zookeeper 来维护 broker 的信息。

命令服务

命名服务也是分布式系统中比较常见的一类场景。在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。

注册一个持久节点/service/business/what，他下面的每个子节点都是一个可用服务，保存了服务的地址端口等信息，服务调用者通过 zookeeper 获取 /service/business/what 所有子节点信息来得到可用的服务。

下面的节点都是临时节点，服务器启动的时候会过来注册一个临时节点，服务器挂掉之后或主动关闭之后，临时节点会自动移除，这样就可以保证使用者获取的 what 服务都是可用的，而且可以动态的扩容缩容。

分布式协调/通知

ZooKeeper 中特有 Watcher 注册与异步通知机制，能够很好的实现分布式环境下不同机器，甚至不同系统之间的通知与协调，从而实现对数据变更的实时处理。使用方法通常是不同的客户端都对 ZooKeeper 上同一个 ZNode 进行注册，监听ZNode 的变化（包括 ZNode 本身内容及子节点的），如果 ZNode 发生了变化，那么所有订阅的客户端都能够接收到相应的 Watcher 通知，并做出相应的处理。 ZooKeeper 的分布式协调/通知，是一种通用的分布式系统机器间的通信方式。

心跳检测

机器间的心跳检测机制是指在分布式环境中，不同机器（或进程）之间需要检测到彼此是否在正常运行，例如 A 机器需要知道 B 机器是否正常运行。在传统的开发中，我们通常是通过主机直接是否可以相互 PING 通来判断，更复杂一点的话，则会通过在机器之间建立长连接，通过 TCP 连接固有的心跳检测机制来实现上层机器的心跳检测，这些都是非常常见的心跳检测方法。基于 ZooKeeper 的临时节点的特性，可以让不同的进程都在 ZooKeeper 的一个指定节点下创建临时子节点，不同的进程直接可以根据这个临时子节点来判断对应的进程是否存活。通过这种方式，检测和被检测系统直接并不需要直接相关联，而是通过 ZooKeeper 上的某个节点进行关联，大大减少了系统耦合。

6、ZooKeeper 工作流程

Leader 工作流程

Leader 主要有三个功能：

① 恢复数据；

② 维持与 Learner 的心跳，接收 Learner 请求并判断 Learner 的请求消息类型；

③ Learner 的消息类型主要有 PING 消息、REQUEST 消息、ACK 消息、根据不同的消息类型，进行不同的处理。

PING 消息是指 Learner 的心跳信息；REQUEST 消息是 Follower 发送的提议信息，包括写请求及同步请求；ACK 消息是 Follower 的对提议的回复，超过半数的 Follower通过，则 commit 该提议；REVALIDATE 消息是用来延长 SESSION 有效时间。