Zookeeper 从入门到放弃之 Zookeeper 典型应用场景

前言

今天来聊一下，Zookeeper 的典型应用场景。

本文将从以下场景，来进行描述：

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

• 命名服务

• Master 选举

• 分布式队列

• 分布式锁

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

何为配置中心

当系统架构由单机架构进入分布式架构之后，系统的复杂性大幅度上升，针对分布式应用的配置内容，很难以管理。为了更好地管理，分布式系统内各应用的配置项，采用配置中心化，使用一个中间件配置中心来进行统一配置的管理。

zookeeper 实现配置中心

Zookeeper 用来实现配置中心，因为我们之前讲过的，Zookeeper 具有的一些特殊性

• znode 能够存储数据

• watch 能够监听数据改变

znode 能够按照要求，定制化保存所有的配置内容，同时使用 watch 监听机制，能够实时刷新客户端的配置获取，保证各客户端应用，能够实时获取到最新的配置。

常用的，可以采用两种配置形式来实现：

1. 一个配置项一个 znode

2. 一个配置文件一个 znode

命名服务

何为命名服务

命名服务，即动态的维护服务地址，保证调用可用性。

Zookeeper 实现命名服务

场景：

工程师小明 负责 A 服务的开发，工程师小丽 负责 B 服务的开发，A 服务其中有业务逻辑，需要依赖 B 服务，调用 B 服务，完成功能实现。当小明已经完成 A 服务开发之后，被安排开发别的项目，但是此时 B 服务仍未完成。思考，小明如何实现不停机，上线 A 服务？

如图所示，我们可以通过 zookeeper 来实现

A 服务客户端，注册一个 watch 监听到节点 znode（/ServiceB）,B 服务完成节点 znode（/ServiceB）的创建，当 B 服务完成上线后，节点发生数据变化，激活监听机制，A 服务收到数据变化，进行刷新 B 服务地址，从而实现不停机，上线 A 服务。

Master 选举

何为 Master 选举

在集群方案中，无法保证 Master 是一直可用的，当 Master 失去可用性，挂掉，那么 slave 实例必须能够进行 Master 的选举，保证整个系统的可用，这就是 Master 选举。

Zookeeper 实现 Master 选举

实现 Master 选举，市面上有很多成熟的方案。那么，我们主要聊一下，采用 Zookeeper 实现 Master 选举。其实，采用 Zookeeper 实现 Master 选举非常简单。

如下图所示：

我们需要将所有 slave 客户端应用都使用 watch 机制，监听 Master 注册的临时节点 znode（/Master)，当 Master 发生故障，宕机之后，节点 znode（/Master）因为是临时节点，因此发生 session 失效。各 slave 客户端，监听到变化，争抢创建临时主节点 znode(/Master)，当一个 slave 创建成功之后，便成为新的 Master，其他 slave 就还进入等待中。同时，获取 Master 的实时信息，进行数据同步。

与此同时，我们可以将所有的客户端实例，都注册临时或者临时顺序节点，在一个集群节点 znode（/servers）下，因此，我们可以通过，获取（/servers）可以查看分布式应用中，所有应用的健康状态，可以进行心跳检测。同时，采用最小节点为 Master 方式，也能实现 Master 选举

分布式队列

何为分布式队列

在分布式系统应用中，我们可以采用生产者-消费者的设计模式，来实现异步数据传输，完成各种队列功能。市面上，常见的分布式队列中间件，包括 RabbitMQ、RocketMQ、ActiveMQ、Kafka 等，那么 zookeeper 同样可以实现分布式队列。

Zookeeper 实现分布式队列

Zookeeper 实现分布式队列，因为我们之前讲核心概念中的特性，FIFO。

如下图所示：

生产者客户端应用，可以创建顺序节点 在一个集群节点 znode(/Queue)下，然后消费者，监听集群节点 znode（/Queue），读取最新的子节点信息，消费最小号节点的数据值。

此处，重点在于创建的是顺序节点。

同时，队列分为有界队列，无界队列。无界队列，生产者，可以争抢创建顺序节点，有界队列，则需要进行控制生产者的创建，此时，就需要分布式锁的出现，来控制生产者创建节点。

分布式锁

何为分布式锁

分布式应用中，对于集群中应用的业务操作，有所控制，需要有机制来进行管理，即为分布式锁，通过对资源加锁，实现，管理。

Zookeeper 实现分布式锁

实现分布式锁，存在两种实现方式

1. 创建临时节点

如下图所示，可以通过创建临时节点 znode(/Lock)，争抢创建，当创建成功后，获得锁，然后删除临时节点

实现逻辑如下图所示：

缺点是会发生惊群效应，当锁被释放，会一波激起千层浪，引发大范围的通知，如果高并发的系统，可能会引发灾难性的问题。

1. 创建顺序临时节点

场景：

小明在医院中治疗感冒，来到医院，先需要进行取号操作，完成取号后，按照号码顺序，进行医疗室。如果前边的号码病人因为某些原因，提前离开，不就诊，小明无需再次取号，可以直接递进。

Zookeeper 实现分布式锁，就可以采用场景中类似的实现。

如下图所示，可以通过创建临时顺序节点，到一个集群节点 znode(/Lock)上，实现锁的实现。每个实例，通过 watch 监听前一个顺序节点实例状态。

实现逻辑如下图所示：

总结

以上就是今天我们聊得内容，Zookeeper 作为分布式协调服务，因其一些特性，有非常丰富的使用场景。