ZooKeeper的典型应用

最新推荐文章于 2024-06-27 21:45:00 发布

空城1995

最新推荐文章于 2024-06-27 21:45:00 发布

阅读量398

点赞数

分类专栏： Zookeeper 文章标签： zookeeper

本文链接：https://blog.csdn.net/fy_java1995/article/details/109104219

版权

Zookeeper 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

Zookeeper是一个关键的分布式协调框架，用于数据发布/订阅、命名服务、集群管理和Master选举。它通过ZAB算法确保数据一致性，并提供临时节点来监控服务存活性。在配置管理中，Zookeeper存储和更新配置信息，客户端通过Watcher监听数据变化。此外，Zookeeper还用于实现分布式锁，支持排他锁和共享锁，保证并发访问的安全。

摘要由CSDN通过智能技术生成

Zookeeper是一个高可用的分布式数据管理与协调框架。基于对ZAB算法的实现，该框架能够很好地保证分布式环境中数据的一致性。

随着近年来互联网系统规模的不断扩大，大数据时代飞速到来，越来越多的分布式系统将Zookeeper作为核心组件使用，如Hadoop、HBase和Kafka等。

1.数据发布/订阅

数据发布/订阅（Publish/Subscribe）系统，即所谓的配置中心，顾名思义就是发布者将数据发布到ZooKeeper的一个或一系列节点上，供订阅者进行数据订阅，从而达到动态获取数据的目的，实现配置信息的集中式管理和数据的动态更新。

在ZooKeeper中，客户端向服务端注册自己需要关注的节点，一旦该节点的数据发生变更，那么服务端就会向相应的客户端发送Watcher事件通知，客户端接收到这个消息通知之后，需要主动到服务端获取更新的数据。

我们以一个“数据库切换”的应用场景展开，看看如何使用ZooKeeper来实现配置管理。

配置存储

在进行配置管理之前，首先我们需要将初始化配置存储到ZooKeeper上去。一般情况下，我们可以在ZooKeeper上选取一个数据节点用于配置的存储，例如/app1/database_config

我们将需要集中管理的配置信息写入该数据节点中，例如：

mysql.url=localhost:3306
mysql.username=root
mysql.password=root

配置获取

集群中每台机器在启动初始化阶段，首先会从上面提到的ZooKeeper配置节点上读取数据库信息，同时，客户端还需要在该配置节点上注册一个数据变更的Watcher监听，一旦发生节点数据变更，所有订阅的客户端都能够后去到数据变更通知。

配置变更

在系统运行过程中，可能会出现需要进行数据库切换的情况，这个时候就需要进行配置变更。我们只需要对ZooKeeper上配置节点的内容进行更新，ZooKeeper就能帮我们将数据变更的通知发送到各个客户端。

2.命名服务

ZooKeeper的命名服务功能主要是根据指定名字来获取资源或服务的地址，提供者等信息，利用其znode的特点和watcher机制，将其作为动态注册和获取服务信息的配置中心，统一管理服务名称和其对应的服务器列表信息，我们能够近乎实时地感知到后端服务器的状态(上线、下线、宕机)。

例如，在Dubbo中使用ZooKeeper来作为其命名服务，维护全局的服务地址列表。在Dubbo实现中：

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

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

命名服务的作用

负载均衡

轮询服务注册表，尽可能将服务请求均匀分配到所有注册有效的服务器上。

健康检查

动态维护服务地址注册表，利用心跳请求实时监控注册服务状态，删除无效服务节点，维护有效的地址注册表。

调用监控

通过统计注册表各个子节点被访问次数来监控服务调用情况。

动态路由

可以通过配置注册表参数，在不修改服务代码的情况下，动态指定服务访问的机器。

动态配置

注册表的子节点可以作为单服务器的配置中心，可以直接修改节点配置而不是修改代码的方式，动态修改服务运行的部分参数。

3.集群管理

ZooKeeper具有以下两大特性：

客户端如果对ZooKeeper的一个数据节点注册Watcher监听，那么当数据节点的内容或是其子节点列表发送变更时，ZooKeeper服务器就会向订阅的客户端发送变更通知
对在ZooKeeper上创建的临时节点，一旦客户端与服务器之间的会话失效，那么该临时节点也被自动清除

利用ZooKeeper的这两大特性，就可以实现另一种集群机器存活性监控的系统。例如：监控系统在/clusterServers节点上注册一个Watcher监听，那么但凡进行动态添加机器的操作，都会在该节点下创建一个临时节点：/clusterServers/[HostName]。这样一来，监控系统就能够实时监测到机器的变动情况。

下面用一个典型例子来看看如何实现集群管理。

在线云主机管理

在线云主机管理通常出现在那些虚拟主机提供商的应用场景中。在这类集群管理中，有很重要的一块就是集群机器的监控。这个场景通常对于集群中的机器状态，尤其是机器在线率的统计有较高的要求，同时需要能够快速地对集群中机器的变更做出相应。

在传统的实现方案中，监控系统通过某种方案（比如检测主机的指定端口）来对每台机器进行定时检测，或者每台机器自己定时向监控系统汇报。但是这种方式需要每一个业务系统的开发人员自己来处理网络通信、协议涉及、调度和容灾等诸多问题。

下面我们看看ZooKeeper怎么实现。

机器上/下线

在新增机器的时候，首先将制定的Agent部署到这些机器上去，启动之后，首先向ZooKeeper的指定节点进行注册。具体的做法就是在机器列表节点下面创建一个临时子节点，如下图：

当Agent在ZooKeeper上创建完这个临时子节点后，关注/XAE/machines节点的监控中心就会接收到“子节点变更”事件，即上线通知，于是就可以对这个新加入的机器开启响应的后台管理逻辑。机器下线也是同理。

机器监控

对于一个在线云主机系统，不仅要对机器的在线状态进行检测，还需要对机器的运行时状态进行监控。在运行的过程中，Agent会定时将主机的运行状态信息写入ZooKeeper的主机节点，监控中心通过订阅这些节点的数据变更通知来间接获取主机的运行时信息。

4.Master选举

Master选举是一个在分布式系统中非常常见的应用场景。在分布式系统中，Master往往用来协调集群中其它系统单元，具有对分布式系统状态变更的决定权。例如，在一些读写分离的应用场景中，客户端的写请求往往是由Master来处理的；而在另一些场景中，Master则常常负责处理一些复杂的逻辑，并将处理结果同步给集群中其它系统单元。

在分布式环境中，经常会碰到这样的应用场景：集群中的所有系统单元需要对前端业务提供数据，比如一个商品id，而这些数据往往需要从一系列的海量数据处理中计算得到-这通常是一个非常耗费IO和CPU资源的过程。鉴于该计算的复杂性，如果让集群中的所有机器都执行这个计算逻辑的话，会耗费非常多的资源。一种比较好的方法就是只让集群中的部分，或者一台机器去处理，处理完成，共享给集群中的其它客户端机器。

这里我们以一个简单的广告投放系统来讲解。