Distributed System: ZooKeeper系列之二 （功能）

上期在文章 http://blog.csdn.net/firehotest/article/details/60312648 简要解释了ZooKeeper的来源及其ZAB的应用。是在PAXOS的状态机模型下，更加注重更改的任务顺序与用户的请求顺序一致的“先来后到”。

这期文章，参考Linux 爱好者公众号的文章《ZooKeeper原理及其在Hadoop和HBase中的应用》而归纳整理的。

基于ZooKeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。

下面分别简要解释这些功能的含义：

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


数据发布与订阅，即所谓的配置中心，顾名思义就是发布者将数据发布到ZooKeeper节点（集群当中的一个特定的节点）上，供订阅者（集群当中的其它节点）进行数据订阅，进而达到动态获取数据的目的，实现配置信息的集中式管理和动态更新。


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


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


对于这样的全局配置信息就可以发布到ZooKeeper上，让客户端（集群的机器）去订阅该消息。


发布/订阅系统一般有两种设计模式，分别是推（Push）和拉（Pull）模式。


推：服务端主动将数据更新发送给所有订阅的客户端。
拉：客户端主动发起请求来获取最新数据，通常客户端都采用定时轮询拉取的方式。


ZooKeeper采用的是推拉相结合的方式。如下：


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

命名服务(Naming Service)


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

命名服务的实质是为所有的资源创建一个全局唯一的ID，与URI的意义相同。（URI包含URL和ISBN）。


ZooKeeper的命名服务即生成全局唯一的ID。这个ID在服务器的ID体现在myid这个文件。

ZooKeeper配置很简单，每个节点的配置文件(zoo.cfg)都是一样的，只有myid文件不一样。myid的值必须是zoo.cfg中server.{数值}的{数值}部分。

（图片来源转载文章）

ZooKeeper的分布式协调/通知


ZooKeeper的协调通知机制是通过Watcher注册与异步通知机制.不同的客户端都能对ZK上同一个ZNode进行注册，监听ZNode的变化（包括ZNode本身内容及子节点的），如果ZNode发生了变化，那么所有订阅的客户端都能够接收到相应的Watcher通知，并做出相应的处理。


ZK的分布式协调/通知，是一种通用的分布式系统机器间的通信方式。

ZooKeeper如何实现心跳检测和任务进度汇报

ZooKeeper实现心跳检测和任务进度汇报都通过其特有的ZNode来实现。因为ZNode可以有临时节点一说。所以，每个进程可以在同一个节点下创建临时节点，临时节点的存在时长与Session是相同的。如果一个进程（Session）结束了，（不管是正常结束或者Timeout），临时节点就不见了。

利用这个机制可以实现心跳检测。如果临时节点消失了，代表对应的Session消失了。

而任务汇总方法则如下：

在ZK上选择一个节点，每个任务客户端都在这个节点下面创建临时子节点，这样便可以实现两个功能：

1） 通过判断临时节点是否存在来确定任务机器是否存活。

2） 各个任务机器会实时地将自己的任务执行进度写到这个临时节点上去，以便中心系统能够实时地获取到任务的执行进度。