Zookeeper分布式一致性原理（八）：Zookeeper典型应用场景

1. 简介

Zookeeper是一个高可用的分布式数据管理和协调框架，并且能够很好的保证分布式环境中数据的一致性。在越来越多的分布式系统（Hadoop、HBase、Kafka）中，Zookeeper都作为核心组件使用。

典型应用场景

• 数据发布/订阅
• 负载均衡
• 命名服务
• 分布式协调/通知
• 集群管理
• Master选举
• 分布式锁
• 分布式队列

2. 数据发布/订阅

数据发布/订阅系统，即配置中心。需要发布者将数据发布到Zookeeper的节点上，供订阅者进行数据订阅，进而达到动态获取数据的目的，实现配置信息的集中式管理和数据的动态更新。

发布/订阅一般有两种设计模式：推模式和拉模式，服务端主动将数据更新发送给所有订阅的客户端称为推模式；客户端主动请求获取最新数据称为拉模式，Zookeeper采用了推拉相结合的模式，客户端向服务端注册自己需要关注的节点，一旦该节点数据发生变更，那么服务端就会向相应的客户端推送Watcher事件通知，客户端接收到此通知后，主动到服务端获取最新的数据。

2.1 核心思想

若将配置信息存放到Zookeeper上进行集中管理，在通常情况下，应用在启动时会主动到Zookeeper服务端上进行一次配置信息的获取，同时，在指定节点上注册一个Watcher监听，这样在配置信息发生变更，服务端都会实时通知所有订阅的客户端，从而达到实时获取最新配置的目的。

系统中需要使用一些通用的配置信息，例如机器列表信息、运行时的开关配置、数据库配置信息等。这些全局配置信息通畅具备以下三个特性：

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

配置获取

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

配置获取

借助Zookeeper，我们只需要对Zookeeper上配置节点内容进行变更，Zookeeper就能帮组我们将数据变更的通知发送到各个客户端，每个客户端在接受到这个通知后，就能可以重新进行最新数据的获取。

3. 负载均衡

负载均衡是一种相当常见的计算机网络技术，用来对多个计算机、网络连接、CPU、磁盘驱动或其他资源进行分配负载，以达到优化资源使用、最大化吞吐率、最小化响应时间和避免过载的目的。

3.1 动态DNS服务

DNS是域名系统(domain Name System)的缩写，是在因特网中使用最广泛的核心技术之一。DNS系统可以看做是一个超大规模的分布式映射表，用于将域名和IP地址进行樱色，进而方便人们通过域名来访问互联网节点。

域名配置

首先在Zookeeper上创建一个节点来进行域名配置，如DDNS/app1/server.app1.company1.com。

域名解析

应用首先从域名节点中获取IP地址和端口的配置，进行自行解析。同时，应用程序还会在域名节点上注册一个数据变更Watcher监听，以便及时收到域名变更的通知。

域名变更

若发生IP或端口号变更，此时需要进行域名变更操作，此时，只需要对指定的域名节点进行更新操作，Zookeeper就会向订阅的客户端发送这个事件通知，客户端之后就再次进行域名配置的获取。

3.2 自动化的DNS访问

在上面的实现中，当域名对应的IP地址发生变更的时候，我们还是需要人为地介入去修改域名节点上的IP地址和端口。这种方式不利于我们客户端使用的开发工作，所以需要开发一套能够自动化的DNS访问系统。下面我们就来看一看如何使用Zookeeper实现一个更为自动化的DNS服务。

我们首先来看一下在动态DNS的架构体系中几个比较重要的组件及其职责：

• Register：集群负责域名的动态注册
• Dispatcher：集群负责域名的解析
• Scanner：集群负责检测以及维护服务状态（探测服务的可用性，屏蔽异常服务节点等）。
• SDK：提供各种语言的系统接入协议，提供服务注册以及查询接口
• Monitor：负责收集服务信息以及对DDNS自身状态的监控。
• Controller：是一个后台管理Console，负责授权管理、流量控制、静态配置服务和手动屏蔽服务等功能，另外，系统地运维人员也可以在上面管理注册Register、Dispatcher和Scanner等

域名注册

域名解析是针对服务消费者来说的，正好和域名注册相反：服务消费者在使用域名的时候，会向Dispatcher发出域名解析请求。Dispatcher收到请求之后，会从Zookeeper上的指定域名节点读取到相应的IP:PORT列表，通过一定的策略选取其中一个返回个应用。

域名探测

域名探测是指DDNS系统需要对域名下所有注册的IP地址和端口的可用性检测，俗称“健康度检测”。健康度检测一般有两种方式，第一种是服务端主动发起健康度心跳检测，这种方式一般需要在服务端和客户端之间建立起一个TCP长链接；第二种则是客户端主动向服务端发起健康度心跳检测。在DDNS架构中的域名探测，使用的是服务提供者主动向Scanner进行状态汇报（即第二种健康度检测方式）的模式，即每个服务提供者都会定时向Scanner汇报自己的状态。

Scanner会负责记录每个服务提供者最近一次的状态汇报时间，一旦超过5秒没有收到状态汇报，那么就认为该IP地址和端口已经不可用，于是开始进行域名清理过程。在域名清理过程中，Scanner会在ZooKeeper中找到该域名对应的域名节点，然后将该IP地址和端口配置从节点内容中移除。

3. 命名服务

命名服务是分布式系统中比较常见的一类场景。命名服务是分布式系统最基本的公共服务之一。在分布式系统中，被命名的实体通常可以是集群中的机器、提供的服务地址或远程对象等——这些我们都可以统称它们为名字（Name），其中较为常见的就是一些分布式服务框架（如RPC、RMI）中的服务地址列表，通过使用命名服务，客户端应用能够根据指定名字来获取资源的实体、服务地址和提供者的信息等。

Java中的JNDI便是一种典型的命名服务。JNDI是Java命名与目录接口（Java Naming and Irectory Interface）的缩写，是J2EE体系中重要的规范之一，标准的J2EE容器都提供了对JNDI规范的实现。因此，在实际开发中，开发人员常常使用应用服务窗口自带的JNDI实现来完成数据源的配置与管理——使用JNDI方式后，开发人员可以完全不需要关心数据库相关的任何信息，包括数据库类型、JDBC驱动类型及数据库账户等。

Java中的JNDI便是一种典型的命名服务。JNDI是Java命名与目录接口（Java Naming and Irectory Interface）的缩写，是J2EE体系中重要的规范之一，标准的J2EE容器都提供了对JNDI规范的实现。因此，在实际开发中，开发人员常常使用应用服务窗口自带的JNDI实现来完成数据源的配置与管理——使用JNDI方式后，开发人员可以完全不需要关心数据库相关的任何信息，包括数据库类型、JDBC驱动类型及数据库账户等。

所谓ID，就是一个能够唯一标识某个对象的标识符。在我们熟悉的关系型数据库中，各个表都需要一个主键来唯一标识每条数据库记录。于是我们就需要一种能在分布式环境下生成全局唯一ID的方法

ZooKeeper的命名服务有两个应用方向：

1. ZooKeeper提供类似JNDI服务，都能够帮助应用系统通过一个资源引用的方式来实现对资源的定位与实用。
2. 利用ZooKeeper顺序节点的特性，制作分布式的ID生成器。

使用Zookeeper生成唯一ID的步骤：

1. 所有客户端会根据自己的节点类型，在指定类型的任务下通过调用create()接口来创建一个顺序节点，例如创建“job-”节点
2. 节点创建完毕之后，create()方法就会返回一个完整的节点名，例如“job-000000000003”
3. 客户端拿到这个返回值之后，拼接上type类型，例如“type-job-00000000003”，这个就可以作为一个全局唯一的ID了。

4. 分布式协调/通知服务

分布式协调/通知服务是分布式系统中不可缺少的一个环节，是将不同的分布式组件有机结合起来的关键所在。对于一个在多台机器上部署运行的应用而言，通常需要一个协调者（Coordinator）来控制整个系统的运行流程，例如分布式事务的处理、机器间的互相协调等。同时，引入这样一个协调者，便于将分布式协调的职责从应用中分离出来，从而可以大大减少系统之间的耦合性，而且能够显著提高系统的可扩展性。

基于ZooKeeper实现分布式协调与通知功能，通常的做法是不同的客户端都对ZooKeeper上同一个数据节点进行Watcher注册，监听数据节点的变化（包括数据节点本身及其子节点），如果数据节点发生变化，那么所有订阅的客户端都能够接收到相应的Watcher通知，并做出相应的处理。

4.1 MySQL数据复制总线：Mysql_Replicator

MySQL数据复制总线（以下简称“复制总线”）是一个实时数据复制框架，用于在不同的MySQL数据库实例之间进行异步数据复制和数据变化通知。整个系统是一个由MySQL数据库集群、消息队列系统、任务管理监控平台以及ZooKeeper集群等组件共同构成的一个包含数据生产者、复制管道和数据消费者等部分的数据总线系统，下图所示该系统的整体结构图。

在该系统中，ZooKeeper主要负责进行一系列的分布式协调工作，在具体的实现上，根据功能将数据复制组件划分为三个核心子模块：Core、Server和Monitor，每个模块分别为一个单独的进程，通过ZooKeeper进行数据交换。

• Core实现了数据复制的核心逻辑，其将数据复制封装成管道，并抽显出生产者和消费者两个概念，其中生产者通常是MySQL数据库的Binlog日志。
• Server负责启动和停止复制任务。
  Monitor负责监控任务的运行状态，如果在数据复制期间发生异常或出现故障会进行告警。

三个子模块之间的关系如下图所示。

每个模块作为独立的进程运行在服务器，运行时的数据和配置信息均保存在ZooKeeper上，Web控制台通过ZooKeeper上的数据获取到后台进程的数据，同时发布控制信息。

应对复制任务所在的Server机器会出现机器故障或者复制任务故障的问题。MySQL数据复制总线提出了一种任务热备份和任务冷备份两种机制来解决这个问题：

4.2.1 记录执行状态

既然使用了热备份，那么RUNNING任务机器就需要将运行时的上下文状态保留给STANDBY任务机器。在这个场景中，最主要的上下文状态就是数据复制过程中的一些进度信息，例如Binlog日志的消费位点，因此需要将这些信息保存到ZooKeeper上以便共享。在Mysql_Replicator的设计中，选择了/mysql_replicator/task/copy_hot_item/lastCommit作为Binlog日志消费位点的存储节点，RUNNING任务机器会定时向这个节点写入当前的Binlog日志消费位点。

4.2.2 控制台协调

在上文中我们主要讲解了Core组件是如何进行分布式任务协调的，接下来我们再看看Server是如何来管理Core组件的。在Mysql_Replicator中，Server主要的工作就是进行任务的控制，通过ZooKeeper来对不同的任务进行控制与协调。Server会将每个复制任务对用生产者的元数据，即库名、表名、用户名与密码等数据库信息以及消费者的相关信息以配置的形式写入任务节点/mysql_replicator/tasks/copy_hot_item中去，以便该任务的所有任务机器都能够共享该复制任务的配置。

4.2.3 任务热备份

任务注册

Core进程在启动的时候，首先会向/mysql_replicator/tasks节点（以下简称“任务列表节点”）注册任务。例如，对于一个“复制热门商品”的任务。

任务热备份

为了应对复制任务故障或者复制任务所在主机故障，复制组件采用“热备份”的容灾方式，即将同一个复制任务部署在不同的主机上，我们称这样的机器为“任务机器”，主、备任务机器通过ZooKeeper互相检测运行健康状况。

为了实现上述热备方案，无论在第一步中是否创建了任务节点，每台任务机器都需要在/mysql_replicator/task/copy_hot_item/instances节点上将自己的主机名注册上去。注意，这里注册的节点类型很特殊，是一个临时的顺序节点。在注册完这个子节点后，通常一个完整的节点名如下：/mysql_replicator/task/copy_hot_item/instances/[Hostname]-1，其中最后的序列号是临时顺序节点的精华所在。

在完成该子节点的创建后，每台任务机器都可以获取到自己创建的节点的完成节点名以及所有子节点的列表，然后通过对比判断自己是否是所有子节点中序号最小的。如果自己是序号最小的子节点，那么就将自己的运行状态设置为RUNNING，其余的任务机器则将自己设置为STANDBY——我们将这样的热备份策略称为“小序号优先”策略。

热备切换

完成运行状态的标识后，任务的客户端机器就能够正常工作了，其中标记为RUNNING的客户端机器进行正常的数据复制，而标记为STANDBY的客户端机器则进入待命状态。这里所谓待命状态，就是说一旦标记为RUNNING的机器出现故障停止了任务执行，那么就需要在所有标记为STANDBY的客户端机器中再次按照“小序号优先”策略来选出RUNNING机器来执行，具体的做法就是标记为STANDBY的机器都需要在/mysql_replicator/task/copy_hot_item/instances节点上注册一个“子节点列表变更”的Watcher监听，用来订阅所有任务执行机器的变化情况—— 一旦RUNNING机器宕机与ZooKeeper断开链接后，对应的节点就会消失，于是其他机器也就接收到了这个变更通知，从而开始新一轮的RUNNING选举。

4.2.4 任务冷备份

到目前为止我们已经基本了解了Mysql_Replicator的工作原理，现在再回头看上面提到的热备份。在该热备份方案中，针对一个任务，都会至少分配两台任务机器来进行热备份，但是在一定规模的大型互联网公司中，往往有许多MySQL实例需要进行数据复制，每个数据库实例都会对应一个复制任务，如果每个任务都进行双机热备份的话，那么显然需要消耗太多的机器。

因此，我们同时设计了一种冷备份的方案，他和热备份方案最大的不同点在于，对所有任务进行分组，如下图所示。

和热备份中比较大的区别在于，Core进程被配置了所属Group（组）。举个例子来说，假如一个Core进程被标记了group1，那么在Core进程启动后，会到对应的ZooKeeper group1节点下面获取所有的Task列表，假如找到了任务“cop_hot_item”之后，就会遍历这个Task列表的instances节点，但凡还没有子节点的，则会创建一个临时的顺序节点：/mysql_replicator/task/copy_hot_item/instances/[Hostname]-1——当然，在这个过程中，其他Core进程则会自动将自己创建的子节点删除，然后继续遍历下一个Task节点——我们将这样的过程称为“冷备份扫描”。就这样，所有Core进程在一个扫描周期内不断的对相应的Group下面的Task进行冷备份扫描。整个过程可以通过如下图所示的流程图来表示。

冷热备份对比

从上面的讲解中，我们基本对热备份和冷备份两种运行方式都有了一定的了解，现在再来对比下这两种运行方式。在热备份方案中，针对一个任务使用了两台机器进行热备份，借助ZooKeeper的Watcher通知机制和临时顺序节点的特性，能够非常实时的进行互相协调，但缺陷就是机器资源消耗特别大。而在冷备份方案中采用了扫描机制，虽然降低了任务协调的实时性，但是节省了机器资源。

4.3 一种通用的分布式系统机器间通信方式

在绝大部分的分布式系统中，系统机器间的通信无外乎心跳检测、工作进度汇报和系统调度这三种类型。接下来，我们将围绕这三种类型的机器通信来讲解如何基于ZooKeeper去实现一种分布式系统间的通信方式。

4.3.1 心跳检测

机器间的心跳机制是指在分布式环境中，不同机器之间需要检测到彼此是否在正常运行，例如A机器需要知道B机器是否正常运行。在传统的开发中，我们通常是通过主机之间是否可以相互PING通来判断，更复杂一点的话，则会通过在机器之间建立长连接，通过TCP连接固有的心跳检测机制来实现上层机器的心跳检测，这些确实都有一些非常常见的心跳检测方法。

下面来看看如何使用ZooKeeper来实现分布式机器间的心跳检测。基于ZooKeeper的临时节点特性，可以让不同的机器都在ZooKeeper的一个指定节点下创建临时子节点，不同的机器之间可以根据这个临时节点来判断对应的客户端机器是否存活。通过这种方式，检测系统和被检测系统之间并不需要直接相关联，而是通过ZooKeeper上的某个节点进行关联，大大减少了系统耦合。

4.3.2 工作进度会报

在一个常见的任务分发系统中，通常任务被分发到不同的机器上执行后，需要实时的将自己的任务执行进度汇报给分发系统。这个时候就可以通过ZooKeeper来实现。在ZooKeeper上选择一个节点，每个任务客户端都在这个节点下面创建临时子节点，这样便可以实现两个功能：

1. 通过判断临时节点是否存在来确定任务机器是否存活；
2. 各个任务机器会实时的将自己的任务进度写到这个临时节点上去，以便中心系统能够实时的获取到任务的执行进度。

4.3.3 系统调度

使用ZooKeeper，能够实现另一种系统调度模式：一个分布式系统由控制台和一些客户端系统两部分组成，控制台的职责就是需要将一些指令信息发送给所有的客户端，以控制他们进行相应的业务逻辑。后天管理人员在控制台上做的一些操作，实际上就是修改了ZooKeeper上某些节点的数据，而ZooKeeper进一步把这些数据变更以事件通知的形式发送给了对应的订阅客户端。

5. 集群管理

所谓集群管理，包括集群监控与集群控制两大块，前者侧重对集群运行时状态的收集，后者则是对集群进行操作与控制。在日常开发和运维过程中，我们经常会有类似于如下的需求。

• 希望知道当前集群中究竟有多少机器在工作。
• 对集群中每台机器的运行时状态进行数据收集。
• 对集群中机器进行上下线操作。

在传统的基于Agent的分布式集群管理体系中，都是通过在集群中的每台机器上部署一个Agent，由这个Agent负责主动向指定的一个监控中心系统（监控中心系统负责将所有数据进行集中处理，形成一系列报表，并负责实时报警，以下简称“监控中心”）汇报自己所在机器的状态。在集群规模适中的场景下，这确实是一种在生产实践中广泛使用的解决方案，能够快速有效地实现分布式环境集群监控，但是一旦系统的业务场景增多，集群规模变大之后，该解决方案的弊端也就显现出来了。

基于Agent分布式集群管理系统存在的问题:

1. 大规模升级困难
2. 统一的Agent无法满足多样性的需求
3. 编程语言的多样性

ZooKeeper具有以下两大特性。

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

5.1 分布式日志收集系统

分布式日志收集系统的核心工作就是收集分布在不同机器上的系统日志，在这里我们重点来看分布式日志系统（以下简称“日志系统”）的收集器模块。

在一个典型的日志系统的架构设计中，整个日志系统会把所有需要收集的日志机器（下文我们以“日志源机器”代表此类机器）分为多个组别，每个组别对应一个收集器，这个收集器其实就是一个后台机器（下文我们以“收集器机器”代表此类机器），用于收集日志。对于大规模分布式日志收集系统场景，通常需要解决如下两个问题。

• 变化的日志源机器
• 变化的收集器机器

注册收集器机器

使用ZooKeeper来进行日志系统收集器的注册，典型做法是在ZooKeeper上创建一个节点作为收集器的根节点，例如/logs/collector（下文我们以“收集器节点”，代表该数据节点），每个收集器机器在启动的时候，都会在收集器节点下创建自己的节点，例如/logs/collector/[Hostname]，如下图所示。

任务分发

待所有收集器机器都创建好自己对应的节点后，系统根据收集器节点下子节点的个数，将所有日志源机器分成对应的若干组，然后将分组后的机器列表分别写到这些收集器机器创建的子节点（例如/logs/collector/host1）上去。这样一来，每个收集器机器都能够从自己对应的收集器节点上获取日志源机器列表，进而开始进行日志收集工作。

状态汇报

完成收集器机器的注册以及任务分发后，我们还要考虑到这些机器随时都有挂掉的可能。因此，针对这个问题，我们需要有一个收集器的状态汇报机制：每个收集器机器在创建完自己的专属节点后，还需要在对应的子节点上创建一个状态子节点，例如/logs/collector/host1/status，每个收集器机器都需要定期向该节点写入自己的状态信息。我么你可以把这种策略看作是一种心跳检测机制，通常收集器机器都会在这个节点中写入日志收集进度信息。日志系统根据该状态子节点的最后更新时间来判断对应的收集器机器是否存活。

动态分配

如果收集器机器挂掉或是扩容了，就需要动态的进行收集任务的分配。在运行过程中，日志系统始终关注着/logs/collector这个节点下所有子节点的变更，一旦检测到有收集器机器停止汇报或是有新的收集器机器加入，就要开始任务的重新分配。无论是针对收集器机器停止汇报还是新机器加入的情况，日志系统都需要将之前分配给该收集器的所有任务进行转移。为了解决这个问题，通常有两种做法。

• 全局动态分配: 这是一种简单粗暴的做法，在出现收集器机器挂掉或是新机器加入的时候，日志系统需要根据新的收集器机器列表，立即对所有的日志源机器重新进行一次分组，然后将其分配给剩下的收集器机器。
• 局部动态分配: 全局动态分配方式虽然策略简单，但是存在一个问题：一个或部分收集器机器的变更，就会导致全局动态任务的分配，影响面比较大，因此风险也就比较大。所谓局部动态分配，顾名思义就是在小范围内进行任务的动态分配。在这种策略中，每个收集器机器在汇报自己日志收集状态的同时，也会把自己的负载汇报上去，请注意，这里提到的负载并不仅仅只是简单地指机器CPU负载（Load），而是一个对当前收集器任务执行的综合评估，这个评估算法和ZooKeeper本身并没有太大的关系，这里不再赘述。

5.3 注意事项

节点类型

在上面已经提到，/logs/collector节点下面的所有子节点都代表了每个收集器机器，那么初步认为这些子节点必须选择临时节点，原因是日志系统可以根据这些临时节点来判断收集器机器的存活性。

从上面的描述中可以知道，临时节点显然无法满足这里的业务需求，所以我们选择了使用持久节点来标识每一个收集器机器，同时在这个持久节点下面分别创建/logs/collector/[Hostname]/status节点来表征每一个收集器机器的状态。这样一来，既能实现日志系统对所有收集器的监控，同时在收集器机器挂掉后，依然能够准确的将分配于其中的任务还原。

日志系统节点监听

在实际生产运行过程中，每一个收集器机器更改自己状态节点的频率可能非常高（如每秒1次或更短），而且收集器的数量可能非常大，如果日志系统监听所有这些节点变化，那么通知的消息量可能会非常大。另一方面，在收集器机器正常工作的情况下，日志系统没有必要去实时的接收每次节点状态变更，因此大部分这些状态变更通知都是无用的。因此我们考虑放弃监听设置，而是采用日志系统主动轮询收集器节点的策略，这样就节省了不少网卡流量，唯一的缺陷就是有一定的延时（考虑到分布式日志收集系统的定位，这个延时是可以接受的）。

5.4 在线云主机管理

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

在传统的实现方案中，监控系统通过某种手段（比如检测主机的指定端口）来对每台机器进行定时检测，或者每台机器自己定时向监控系统汇报“我还活着”。但是这种方式需要每一个业务系统的开发人员自己来处理网络通信、协议设计、调度和容灾等诸多琐碎的问题。下面来看看使用ZooKeeper实现的另一种集群机器存活性监控系统。针对这个系统，我们的需求点通常如下。

• 如何快速的统计出当前生产环境一共有多少台机器？
• 如何快速的获取到机器上/下线的情况？
• 如何实时监控集群中每台主机的运行时状态？

机器上/下线

为了实现自动化的线上运维，我们必须对机器的上/下线情况有一个全聚德监控。通常在新增机器的时候，需要首先将指定的Agent部署到这些机器上去。Agent部署启动之后，会首先向ZooKeeper的指定节点进行注册，具体的做法就是在机器列表节点下面创建一个临时子节点，例如/XAE/machine/[Hostname]（下文我们以“主机节点”代表这个节点），如下图所示。

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

随着分布式系统规模变得越来越庞大，对集群机器的监控和管理显得越来越重要。上面提到的这种借助ZooKeeper来实现的方式，不仅能够实时的检测到集群中机器的上/下线情况，而且能够实时的获取到主机的运行时信息，从而能够构建出一个大规模集群的主机图谱。