ZooKeeper的典型应用场景之数据发布/订阅。

最新推荐文章于 2024-03-27 10:27:59 发布

软件求生

最新推荐文章于 2024-03-27 10:27:59 发布

阅读量717

点赞数

分类专栏： # zookeeper 分布式文章标签： zookeeper 应用

zookeeper 同时被 2 个专栏收录

80 篇文章 4 订阅

订阅专栏

分布式

42 篇文章 1 订阅

订阅专栏

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

发布/订阅系统一般一般有两种设计模式，分别是推（Push）模式和拉（Pull）模式。在推模式中，服务端主动将数据更新发送给所有订阅的客户端；而拉模式则是由客户端主动发起请求来获取最新数据，通常客户端都采用定时进行轮询拉去的方式。

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

如果将配置信息存放到ZooKeeper上进行集中管理，那么通常情况下，应用在启动的时候都会主动到ZooKeeper服务端上进行一次配置信息的获取，同时，在指定节点上注册一个Watcher监听，这样一来，但凡配置信息发生变更，服务端都会实时通知到所有订阅的客户端，从而达到实时获取最新配置信息的目的。下面我们通过通过一个“配置管理”的实际案例来展示ZooKeeper在“数据发布/订阅”场景下的使用方式。

在我们平常的应用系统开发中，经常会碰到这样的需求：系统中需要使用一些通用的配置信息，例如机器列表信息、运行时的开关配置、数据库配置信息等。这些全局配置信息通常具备以下3个特性。

数据量通常比较小。
数据内容在运行时会发生动态变化。
集群中各机器共享，配置一致。

对于这类配置信息，一般的做法通常可以选择将其存储在本地配置文件或是内存变量中。无论采用哪种方式，其实都可以简单地实现配置管理。如果采用本地配置文件的方式，那么通常系统可以在应用启动的时候读取到本地磁盘的一个文件来进行初始化，并且在运行过程中定时的进行文件的读取，以此来检测文件内容的变更。在系统的实际运行过程中，如果我们需要对这些配置信息进行更新，那么只要在相应的配置文件中进行修改，等到系统再次读取这些配置文件的时候，就可以读取到最新的配置信息，并更新到系统中去，这样就可以实现系统配置信息的更新。另外一种借助内存变量来实现配置管理的方式也非常简单，以Java系统为例，通常可以采用JMX方式来实现对系统运行时内存变量的更新。

从上面的介绍中，我们基本了解了如何使用本地配置文件和内存变量来实现配置管理。通常在集群机器规模不大，配置变更不是特别频繁的情况下，无论上面提到的哪种方式，都能够非常方便的解决配置管理的问题。但是，一旦机器规模变大，且配置信息变更越来越频繁后，我们发现依靠现有的这两种方式解决配置管理就变得越来越困难了。我们既希望能够快速的做到全局配置信息的变更，同时希望变更成本足够小，因此我们必须需求一种更为分布式化的解决方案。

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

配置存储

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

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

数据库配置

#DBCP

dbcp.driverClassName=com.mysql.jdbc.Driver

dbcp.dbJDBCUrl=jdbc:mysql://127.0.0.1:3306/taokeeper

dbcp.characterEncoding=GBK

dbcp.username=xiaoming

dbcp.password=123456

dbcp.maxActive=30

dbcp.maxIdle=10

dbcp.maxWait=10000