什么是ZooKeeper？可以做什么?ZooKeeper分布式事务详解篇

前言

什么是ZooKeeper，你真的了解它吗。我们一起来看看吧~

一、什么是 ZooKeeper？

ZooKeeper 是 Apache 的一个顶级项目，为分布式应用提供高效、高可用的分布式协调服务，提供了诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知和分布式锁等分布式基础服务。由于 ZooKeeper 便捷的使用方式、卓越的性能和良好的稳定性，被广泛地应用于诸如 Hadoop、HBase、Kafka 和 Dubbo 等大型分布式系统中。

Zookeeper 有三种运行模式：单机模式、伪集群模式和集群模式。

单机模式：

这种模式一般适用于开发测试环境，一方面我们没有那么多机器资源，另外就是平时的开发调试并不需要极好的稳定性。

集群模式：

一个 ZooKeeper 集群通常由一组机器组成，一般 3 台以上就可以组成一个可用的 ZooKeeper 集群了。组成 ZooKeeper 集群的每台机器都会在内存中维护当前的服务器状态，并且每台机器之间都会互相保持通信。

伪集群模式：
这是一种特殊的集群模式，即集群的所有服务器都部署在一台机器上。当你手头上有一台比较好的机器，如果作为单机模式进行部署，就会浪费资源，这种情况下，ZooKeeper 允许你在一台机器上通过启动不同的端口来启动多个 ZooKeeper 服务实例，以此来以集群的特性来对外服务。

ZooKeeper 的相关知识

Zookeeper 中的角色：

领导者（leader）：

负责进行投票的发起和决议，更新系统状态。

跟随者（follower）：

用于接收客户端请求并给客户端返回结果，在选主过程中进行投票。

观察者（observer）：

可以接受客户端连接，将写请求转发给 leader，但是observer 不参加投票的过程，只是为了扩展系统，提高读取的速度。

Zookeeper 的数据模型

1.层次化的目录结构，命名符合常规文件系统规范，类似于 Linux。

2.每个节点在 Zookeeper 中叫做 Znode，并且其有一个唯一的路径标识。

3.节点 Znode 可以包含数据和子节点，但是 EPHEMERAL 类型的节点不能有子节点。

4.Znode 中的数据可以有多个版本，比如某一个路径下存有多个数据版本，那么查询这个路径下的数据就需要带上版本。

5.客户端应用可以在节点上设置监视器。

6.节点不支持部分读写，而是一次性完整读写。

ZooKeeper 的节点特性

ZooKeeper 节点是生命周期的，这取决于节点的类型。在 ZooKeeper 中，节点根据持续时间可以分为持久节点（PERSISTENT）、临时节点（EPHEMERAL），根据是否有序可以分为顺序节点（SEQUENTIAL）、和无序节点（默认是无序的）。

持久节点一旦被创建，除非主动移除，不然一直会保存在 Zookeeper 中（不会因为创建该节点的客户端的会话失效而消失）。

Zookeeper 的应用场景

ZooKeeper 是一个高可用的分布式数据管理与系统协调框架。基于对 Paxos 算法的实现，使该框架保证了分布式环境中数据的强一致性，也正是基于这样的特性，使得 ZooKeeper 解决很多分布式问题。

值得注意的是，ZooKeeper 并非天生就是为这些应用场景设计的，都是后来众多开发者根据其框架的特性，利用其提供的一系列 API 接口（或者称为原语集），摸索出来的典型使用方法。

数据发布与订阅（配置中心）

发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到 ZooKeeper 节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。

应用中用到的一些配置信息放到 ZooKeeper 上进行集中管理。这类场景通常是这样：应用在启动的时候会主动来获取一次配置，同时在节点上注册一个 Watcher。这样一来，以后每次配置有更新的时候，都会实时通知到订阅的客户端，从来达到获取最新配置信息的目的。

分布式搜索服务中，索引的元信息和服务器集群机器的节点状态存放在 ZooKeeper 的一些指定节点，供各个客户端订阅使用。

分布式日志收集系统

这个系统的核心工作是收集分布在不同机器的日志。收集器通常是按照应用来分配收集任务单元，因此需要在 ZooKeeper 上创建一个以应用名作为 path 的节点 P，并将这个应用的所有机器 IP，以子节点的形式注册到节点 P 上。这样一来就能够实现机器变动的时候，能够实时通知到收集器调整任务分配。

系统中有些信息需要动态获取，并且还会存在人工手动去修改这个信息的发问。通常是暴露出接口，例如 JMX 接口，来获取一些运行时的信息。引入 ZooKeeper 之后，就不用自己实现一套方案了，只要将这些信息存放到指定的 ZooKeeper 节点上即可。

注意：
在上面提到的应用场景中，有个默认前提——数据量很小，但是数据更新可能会比较快的场景。

负载均衡

这里说的负载均衡是指软负载均衡。在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑，其中比较典型的是消息中间件中的生产者，消费者负载均衡。

命名服务（Naming Service）

命名服务也是分布式系统中比较常见的一类场景。在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。被命名的实体通常可以是集群中的机器，提供的服务地址，远程对象等等——这些我们都可以统称它们为名字（Name）。其中较为常见的就是一些分布式服务框架中的服务地址列表。通过调用 ZooKeeper 提供的创建节点的 API，能够很容易创建一个全局唯一的path，这个 path 就可以作为一个名字。

阿里巴巴集团开源的分布式服务框架 Dubbo 中使用 ZooKeeper 来作为其命名服务，维护全局的服务地址列表。在 Dubbo 的实现中：

1.服务提供者在启动的时候，向 ZooKeeper 上的指定节点 /dubbo/${serviceName}/providers 目录下写入自己的 URL 地址，这个操作就完成了服务的发布。

2.服务消费者启动的时候，订阅 /dubbo/serviceName/providers目录下的提供者URL地址，并向/dubbo/{serviceName}/providers 目录下的提供者 URL 地址， 并向 /dubbo/serviceName/providers目录下的提供者URL地址，并向/dubbo/{serviceName} /consumers 目录下写入自己的 URL 地址。

注意：
所有向 ZooKeeper 上注册的地址都是临时节点，这样就能够保证服务提供者和消费者能够自动感应资源的变化。

另外，Dubbo 还有针对服务粒度的监控。方法是订阅 /dubbo/${serviceName} 目录下所有提供者和消费者的信息。

分布式通知/协调

ZooKeeper 中特有 Watcher 注册与异步通知机制，能够很好的实现分布式环境下不同系统之间的通知与协调，实现对数据变更的实时处理。使用方法通常是不同系统都对 ZooKeeper 上同一个 Znode 进行注册，监听 Znode 的变化（包括 Znode 本身内容及子节点的），其中一个系统 Update 了 Znode，那么另一个系统能够收到通知，并作出相应处理。

另一种心跳检测机制：检测系统和被检测系统之间并不直接关联起来，而是通过 ZooKeeper 上某个节点关联，大大减少系统耦合。

另一种系统调度模式：某系统有控制台和推送系统两部分组成，控制台的职责是控制推送系统进行相应的推送工作。管理人员在控制台作的一些操作，实际上是修改了 ZooKeeper 上某些节点的状态，而 ZooKeeper 就把这些变化通知给它们注册 Watcher 的客户端，即推送系统。于是，作出相应的推送任务。

另一种工作汇报模式：一些类似于任务分发系统。子任务启动后，到 ZooKeeper 来注册一个临时节点，并且定时将自己的进度进行汇报（将进度写回这个临时节点）。这样任务管理者就能够实时知道任务进度。

分布式锁

分布式锁主要得益于 ZooKeeper 为我们保证了数据的强一致性。锁服务可以分为两类：一类是保持独占，另一类是控制时序。

所谓保持独占，就是所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁。通常的做法是把 ZooKeeper 上的一个 Znode 看作是一把锁，通过 create znode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。

控制时序，就是所有视图来获取这个锁的客户端，最终都是会被安排执行，只是有个全局时序了。做法和上面基本类似，只是这里 /distribute_lock 已经预先存在，客户端在它下面创建临时有序节点（这个可以通过节点的属性控制：CreateMode.EPHEMERAL_SEQUENTIAL 来指定）。ZooKeeper 的父节点（/distribute_lock）维持一份 sequence，保证子节点创建的时序性，从而也形成了每个客户端的全局时序。

1.由于同一节点下子节点名称不能相同，所以只要在某个节点下创建 Znode，创建成功即表明加锁成功。注册监听器监听此 Znode，只要删除此 Znode 就通知其他客户端来加锁。

2.创建临时顺序节点：在某个节点下创建节点，来一个请求则创建一个节点，由于是顺序的，所以序号最小的获得锁，当释放锁时，通知下一序号获得锁。

分布式队列

队列方面，简单来说有两种：一种是常规的先进先出队列，另一种是等队列的队员聚齐以后才按照顺序执行。对于第一种的队列和上面讲的分布式锁服务中控制时序的场景基本原理一致，这里就不赘述了。

第二种队列其实是在 FIFO 队列的基础上作了一个增强。通常可以在 /queue 这个 Znode 下预先建立一个 /queue/num 节点，并且赋值为 n（或者直接给 /queue 赋值 n）表示队列大小。之后每次有队列成员加入后，就判断下是否已经到达队列大小，决定是否可以开始执行了。

这种用法的典型场景是：分布式环境中，一个大任务 Task A，需要在很多子任务完成（或条件就绪）情况下才能进行。这个时候，凡是其中一个子任务完成（就绪），那么就去 /taskList 下建立自己的临时时序节点（CreateMode.EPHEMERAL_SEQUENTIAL）。当 /taskList 发现自己下面的子节点满足指定个数，就可以进行下一步按序进行处理了。

使用 dokcer-compose 搭建集群

上面我们介绍了关于 ZooKeeper