Zookeeper的典型应用场景(转)

在寒假前，完成了Zookeeper系列的前5篇文章，主要是分布式的相关理论，包括CAP，BASE理论，分布式数据一致性算法：2PC，3PC，Paxos算法，Zookeeper的相关基本特性，ZAB协议。今天，完成Zookeeper系列的最后一篇也是最为重要的内容：Zookeeper的典型应用场景的介绍，咱们只有知道zk怎么用，用在哪，咱们才能真正掌握Zookeeper这个优秀的分布式协调框架。

    首先，咱们要知道，Zookeeper是一个具备高可用、高性能和具备分布式数据一致性的分布式数据管理及协调框架，是基于对ZAB算法的实现，基于这样的特性，使ZK成为解决分布式一致性问题的利器，同时Zookeeper提供了丰富的节点类型和Watcher监听机制，经过这两个特色，能够很是方便的构建一系列分布式系统中都会涉及的核心功能： 如：数据发布/订阅，负载均衡，命名服务，分布式协调/通知，集群管理，Master选举，分布式锁，分布式队列等。这一篇，将针对这些分布式应用场景来作介绍，并介绍Zookeeper在如今的大型分布式系统中的做为核心组件的实际应用。

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

数据发布/订阅系统，即配置中心。须要发布者将数据发布到Zookeeper的节点上，供订阅者进行数据订阅，进而达到动态获取数据的目的，实现配置信息的集中式管理和数据的动态更新（能够把咱们知道RPC的注册中心当作是此场景的应用）。

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

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

注意：对于像Dubbo这样的RPC框架来讲，zk将做为其注册中心，客户端第一次经过向zk集群得到服务的地址，而后会存储在本地，下一次进行调用时就不会再次去zk集群中查询，而是直接使用本地存储的地址，只有当服务地址变动时，才会通知客户端再次获取。

在平时的开发中，常常会碰到这样的需求：系统中须要使用一些通用的配置信息，例如：机器列表信息，数据库的配置信息（好比：要实现数据库的切换的应用场景），运行时的开关配置等。这些全局配置信息一般有3个特性：数据量一般比较小；数据内容在运行时会发生动态变化；集群中各机器共享、配置一致。假设，咱们的集群规模很大，且配置信息常常变动，因此经过存储本地配置文件或内存变量的形式实现都很困难，因此咱们使用zk来作一个全局配置信息的管理。

负载均衡

负载均衡是一种至关常见的计算机网络技术，用来对多个计算机、网络链接、CPU、磁盘驱动或其余资源进行分配负载，以达到优化资源使用、最大化吞吐率、最小化响应时间和避免过载的目的。一般负载均衡能够分为硬件（F5）和软件(Nginx)负载均衡两类。Zookeeper也能够做为实现软负载均衡的一种方式。

分布式系统为了保证可用性，一般经过副本的方式来对数据和服务进行部署，而对于客户端吧来讲，只须要在这样对等的服务提供方式中选择一个来执行相关的业务逻辑，怎么选，这就是负载均衡的应用。

好比，典型的须要负载均衡的DNS（Domain Name System）服务,咱们能够用zookeeper实现动态的DNS方案，能够参考《从Paxos到Zookeeper》这本书对于用zk实现动态DNS的方案P167。

zk实现负载均衡就是经过watcher机制和临时节点判断哪些节点宕机来得到可用的节点实现的：

ZooKeeper会维护一个树形的数据结构，相似于Windows资源管理器目录，其中EPHEMERAL类型的节点会随着建立它的客户端断开而被删除，利用这个特性很容易实现软负载均衡。

基本原理是，每一个应用的Server启动时建立一个EPHEMERAL节点，应用客户端经过读取节点列表得到可用服务器列表，并订阅节点事件，有Server宕机断开时触发事件，客户端监测到后把该Server从可用列表中删除。

消息中间件中发布者和订阅者的负载均衡，linkedin开源的KafkaMQ和阿里开源的MetaQ都是经过zookeeper来作到生产者、消费者的负载均衡。

命名服务

命名服务是分步实现系统中较为常见的一类场景，分布式系统中，被命名的实体一般能够是集群中的机器、提供的服务地址或远程对象等，经过命名服务，客户端能够根据指定名字来获取资源的实体、服务地址和提供者的信息，最多见的就是RPC 框架的服务地址列表的命名。Zookeeper也可帮助应用系统经过资源引用的方式来实现对资源的定位和使用，广义上的命名服务的资源定位都不是真正意义上的实体资源，在分布式环境中，上层应用仅仅须要一个全局惟一的名字。Zookeeper能够实现一套分布式全局惟一ID的分配机制。（用UUID的方式的问题在于生成的字符串过长，浪费存储空间且字符串无规律不利于开发调试）
经过调用Zookeeper节点建立的API接口就能够建立一个顺序节点，而且在API返回值中会返回这个节点的完整名字，利用此特性，能够生成全局ID，其步骤以下

　　1. 客户端根据任务类型，在指定类型的任务下经过调用接口建立一个顺序节点，如"job-"。

　　2. 建立完成后，会返回一个完整的节点名，如"job-00000001"。

　　3. 客户端拼接type类型和返回值后，就能够做为全局惟一ID了，如"type2-job-00000001"。

阿里巴巴集团开源的分布式服务框架Dubbo中使用ZooKeeper来做为其命名服务，维护全局的服务地址列表。在Dubbo实现中：

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

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

注意，全部向ZK上注册的地址都是临时节点，这样就可以保证服务提供者和消费者可以自动感应资源的变化。另外，Dubbo还有针对服务粒度的监控，方法是订阅/dubbo/${serviceName}目录下全部提供者和消费者的信息。

分布式协调/通知.

Zookeeper中特有的Watcher注册于异步通知机制，可以很好地实现分布式环境下不一样机器，甚至不一样系统之间的协调与通知，从而实现对数据变动的实时处理。一般的作法是不一样的客户端都对Zookeeper上的同一个数据节点进行Watcher注册，监听数据节点的变化（包括节点自己和子节点），若数据节点发生变化，那么全部订阅的客户端都可以接收到相应的Watcher通知，并做出相应处理。
在绝大多数分布式系统中，系统机器间的通讯无外乎心跳检测、工做进度汇报和系统调度。这三种类型的机器通讯方式均可以使用zookeeper来实现：

　　① 心跳检测，不一样机器间须要检测到彼此是否在正常运行，可使用Zookeeper实现机器间的心跳检测，基于其临时节点特性（临时节点的生存周期是客户端会话，客户端若立即后，其临时节点天然再也不存在），可让不一样机器都在Zookeeper的一个指定节点下建立临时子节点，不一样的机器之间能够根据这个临时子节点来判断对应的客户端机器是否存活。经过Zookeeper能够大大减小系统耦合。

　　② 工做进度汇报，一般任务被分发到不一样机器后，须要实时地将本身的任务执行进度汇报给分发系统，能够在Zookeeper上选择一个节点，每一个任务客户端都在这个节点下面建立临时子节点，这样不只能够判断机器是否存活，同时各个机器能够将本身的任务执行进度写到该临时节点中去，以便中心系统可以实时获取任务的执行进度。

　　③ 系统调度，Zookeeper可以实现以下系统调度模式：分布式系统由控制台和一些客户端系统两部分构成，控制台的职责就是须要将一些指令信息发送给全部的客户端，以控制他们进行相应的业务逻辑，后台管理人员在控制台上作一些操做，实际上就是修改Zookeeper上某些节点的数据，Zookeeper能够把数据变动以时间通知的形式发送给订阅客户端。

集群管理

Zookeeper的两大特性（节点特性和watcher机制）：

　　· 客户端若是对Zookeeper的数据节点注册Watcher监听，那么当该数据及诶单内容或是其子节点列表发生变动时，Zookeeper服务器就会向订阅的客户端发送变动通知。

　　· 对在Zookeeper上建立的临时节点，一旦客户端与服务器之间的会话失效，那么临时节点也会被自动删除。

机器在线率有较高要求的场景，可以快速对集群中机器变化做出响应。这样的场景中，每每有一个监控系统，实时检测集群机器是否存活。过去的作法一般是：监控系统经过某种手段（好比ping）定时检测每一个机器，或者每一个机器本身定时向监控系统汇报“我还活着”。这种作法可行，可是存在两个比较明显的问题：

1.   集群中机器有变更的时候，牵连修改的东西比较多。

2.   有必定的延时。

利用ZooKeeper有两个特性，就能够实时另外一种集群机器存活性监控系统。能够实现集群机器存活监控系统，若监控系统在/clusterServers节点上注册一个Watcher监听，那么但凡进行动态添加机器的操做，就会在/clusterServers节点下建立一个临时节点：/clusterServers/[Hostname]，这样，监控系统就可以实时监测机器的变更状况。
下面经过分布式日志收集系统的典型应用来学习Zookeeper如何实现集群管理。

　　分布式日志收集系统的核心工做就是收集分布在不一样机器上的系统日志，在典型的日志系统架构设计中，整个日志系统会把全部须要收集的日志机器分为多个组别，每一个组别对应一个收集器，这个收集器其实就是一个后台机器，用于收集日志，对于大规模的分布式日志收集系统场景，一般须要解决两个问题：

　　· 变化的日志源机器

　　· 变化的收集器机器

　　不管是日志源机器仍是收集器机器的变动，最终均可以归结为如何快速、合理、动态地为每一个收集器分配对应的日志源机器。

① 注册收集器机器，在Zookeeper上建立一个节点做为收集器的根节点，例如/logs/collector的收集器节点，每一个收集器机器启动时都会在收集器节点下建立本身的节点，如/logs/collector/[Hostname]

② 任务分发，全部收集器机器都建立完对应节点后，系统根据收集器节点下子节点的个数，将全部日志源机器分红对应的若干组，而后将分组后的机器列表分别写到这些收集器机器建立的子节点，如/logs/collector/host1（持久节点）上去。这样，收集器机器就可以根据本身对应的收集器节点上获取日志源机器列表，进而开始进行日志收集工做。

③ 状态汇报，完成任务分发后，机器随时会宕机，因此须要有一个收集器的状态汇报机制，每一个收集器机器上建立完节点后，还须要再对应子节点上建立一个状态子节点，如/logs/collector/host/status（临时节点），每一个收集器机器都须要按期向该结点写入本身的状态信息，这可看作是心跳检测机制，一般收集器机器都会写入日志收集状态信息，日志系统经过判断状态子节点最后的更新时间来肯定收集器机器是否存活。

④ 动态分配，若收集器机器宕机，则须要动态进行收集任务的分配，收集系统运行过程当中关注/logs/collector节点下全部子节点的变动，一旦有机器中止汇报或有新机器加入，就开始进行任务的从新分配，此时一般由两种作法：

　 · 全局动态分配，当收集器机器宕机或有新的机器加入，系统根据新的收集器机器列表，当即对全部的日志源机器从新进行一次分组，而后将其分配给剩下的收集器机器。

　　· 局部动态分配，每一个收集器机器在汇报本身日志收集状态的同时，也会把本身的负载汇报上去，若是一个机器宕机了，那么日志系统就会把以前分配给这个机器的任务从新分配到那些负载较低的机器，一样，若是有新机器加入，会从那些负载高的机器上转移一部分任务给新机器。

Master选举

　　在分布式系统中，Master每每用来协调集群中其余系统单元，具备对分布式系统状态变动的决定权，如在读写分离的应用场景中，客户端的写请求每每是由Master来处理，或者其经常处理一些复杂的逻辑并将处理结果同步给其余系统单元。利用Zookeeper的一致性，可以很好地保证在分布式高并发状况下节点的建立必定可以保证全局惟一性，即Zookeeper将会保证客户端没法重复建立一个已经存在的数据节点（由其分布式数据的一致性保证）。

首先建立/master_election/2016-11-12节点，客户端集群天天会定时往该节点下建立临时节点，如/master_election/2016-11-12/binding，这个过程当中，只有一个客户端可以成功建立，此时其变成master，其余节点都会在节点/master_election/2016-11-12上注册一个子节点变动的Watcher，用于监控当前的Master机器是否存活，一旦发现当前Master挂了，其他客户端将会从新进行Master选举。

另外，这种场景演化一下，就是动态Master选举。这就要用到?EPHEMERAL_SEQUENTIAL类型节点的特性了。

上文中提到，全部客户端建立请求，最终只有一个可以建立成功。在这里稍微变化下，就是容许全部请求都可以建立成功，可是得有个建立顺序，因而全部的请求最终在ZK上建立结果的一种可能状况是这样：/currentMaster/{sessionId}-1 ,?/currentMaster/{sessionId}-2,?/currentMaster/{sessionId}-3 ….. 每次选取序列号最小的那个机器做为Master，若是这个机器挂了，因为他建立的节点会立刻小时，那么以后最小的那个机器就是Master了。

其在实际中应用有：
· 在搜索系统中，若是集群中每一个机器都生成一份全量索引，不只耗时，并且不能保证彼此之间索引数据一致。所以让集群中的Master来进行全量索引的生成，而后同步到集群中其它机器。另外，Master选举的容灾措施是，能够随时进行手动指定master，就是说应用在zk在没法获取master信息时，能够经过好比http方式，向一个地方获取master。

在Hbase中，也是使用ZooKeeper来实现动态HMaster的选举。在Hbase实现中，会在ZK上存储一些ROOT表的地址和 HMaster的地址，HRegionServer也会把本身以临时节点（Ephemeral）的方式注册到Zookeeper中，使得HMaster能够随时感知到各个HRegionServer的存活状态，同时，一旦HMaster出现问题，会从新选举出一个HMaster来运行，从而避免了 HMaster的单点问题。

分布式锁

分布式锁用于控制分布式系统之间同步访问共享资源的一种方式，能够保证不一样系统访问一个或一组资源时的一致性，主要分为排它锁和共享锁。排它锁又称为写锁或独占锁，若事务T1对数据对象O1加上了排它锁，那么在整个加锁期间，只容许事务T1对O1进行读取和更新操做，其余任何事务都不能再对这个数据对象进行任何类型的操做，直到T1释放了排它锁。

① 获取锁，在须要获取排它锁时，全部客户端经过调用接口，在/exclusive_lock节点下建立临时子节点/exclusive_lock/lock。Zookeeper能够保证只有一个客户端可以建立成功，没有成功的客户端须要注册/exclusive_lock节点监听。

② 释放锁，当获取锁的客户端宕机或者正常完成业务逻辑都会致使临时节点的删除，此时，全部在/exclusive_lock节点上注册监听的客户端都会收到通知，能够从新发起分布式锁获取。

　共享锁又称为读锁，若事务T1对数据对象O1加上共享锁，那么当前事务只能对O1进行读取操做，其余事务也只能对这个数据对象加共享锁，直到该数据对象上的全部共享锁都被释放。（控制时序）

　　① 获取锁，在须要获取共享锁时，全部客户端都会到/shared_lock下面建立一个临时顺序节点，若是是读请求，那么就建立例如/shared_lock/host1-R-00000001的节点，若是是写请求，那么就建立例如/shared_lock/host2-W-00000002的节点。

　　② 判断读写顺序，不一样事务能够同时对一个数据对象进行读写操做，而更新操做必须在当前没有任何事务进行读写状况下进行，经过Zookeeper来肯定分布式读写顺序，大体分为四步。

　　　　1. 建立完节点后，获取/shared_lock节点下全部子节点，并对该节点变动注册监听。

　　　　2. 肯定本身的节点序号在全部子节点中的顺序。

　　　　3. 对于读请求：若没有比本身序号小的子节点或全部比本身序号小的子节点都是读请求，那么代表本身已经成功获取到共享锁，同时开始执行读取逻辑，如有写请求，则须要等待。对于写请求：若本身不是序号最小的子节点，那么须要等待。

　　　　4. 接收到Watcher通知后，重复步骤1。

　　③ 释放锁，其释放锁的流程与独占锁一致。

上述共享锁的实现方案，能够知足通常分布式集群竞争锁的需求，可是若是机器规模扩大会出现一些问题，下面着重分析判断读写顺序的步骤3。
　　针对如上图所示的状况进行分析

　　1. host1首先进行读操做，完成后将节点/shared_lock/host1-R-00000001删除。

　　2. 余下4台机器均收到这个节点移除的通知，而后从新从/shared_lock节点上获取一份新的子节点列表。

　　3. 每台机器判断本身的读写顺序，其中host2检测到本身序号最小，因而进行写操做，余下的机器则继续等待。

　　4. 继续...

　　能够看到，host1客户端在移除本身的共享锁后，Zookeeper发送了子节点更变Watcher通知给全部机器，然而除了给host2产生影响外，对其余机器没有任何做用。大量的Watcher通知和子节点列表获取两个操做会重复运行，这样会形成系能鞥影响和网络开销，更为严重的是，若是同一时间有多个节点对应的客户端完成事务或事务中断引发节点小时，Zookeeper服务器就会在短期内向其余全部客户端发送大量的事件通知，这就是所谓的羊群效应。

　能够有以下改动来避免羊群效应。

　　1. 客户端调用create接口常见相似于/shared_lock/[Hostname]-请求类型-序号的临时顺序节点。

　　2. 客户端调用getChildren接口获取全部已经建立的子节点列表（不注册任何Watcher）。

　　3. 若是没法获取共享锁，就调用exist接口来对比本身小的节点注册Watcher。对于读请求：向比本身序号小的最后一个写请求节点注册Watcher监听。对于写请求：向比本身序号小的最后一个节点注册Watcher监听。

　　4. 等待Watcher通知，继续进入步骤2。

　　此方案改动主要在于：每一个锁竞争者，只须要关注/shared_lock节点下序号比本身小的那个节点是否存在便可。

分布式队列

分布式队列能够简单分为先入先出队列模型和等待队列元素汇集后统一安排处理执行的Barrier模型。

① FIFO先入先出，先进入队列的请求操做先完成后，才会开始处理后面的请求。FIFO队列就相似于全写的共享模型，全部客户端都会到/queue_fifo这个节点下建立一个临时节点，如/queue_fifo/host1-00000001。

建立完节点后，按照以下步骤执行。

　　1. 经过调用getChildren接口来获取/queue_fifo节点的全部子节点，即获取队列中全部的元素。

　　2. 肯定本身的节点序号在全部子节点中的顺序。

　　3. 若是本身的序号不是最小，那么须要等待，同时向比本身序号小的最后一个节点注册Watcher监听。

　　4. 接收到Watcher通知后，重复步骤1。

② Barrier分布式屏障，最终的合并计算须要基于不少并行计算的子结果来进行，开始时，/queue_barrier节点已经默认存在，而且将结点数据内容赋值为数字n来表明Barrier值，以后，全部客户端都会到/queue_barrier节点下建立一个临时节点，例如/queue_barrier/host1。
　建立完节点后，按照以下步骤执行。

　　1. 经过调用getData接口获取/queue_barrier节点的数据内容，如10。

　　2. 经过调用getChildren接口获取/queue_barrier节点下的全部子节点，同时注册对子节点变动的Watcher监听。

　　3. 统计子节点的个数。

　　4. 若是子节点个数还不足10个，那么须要等待。

　　5. 接受到Wacher通知后，重复步骤3

上边咱们介绍了Zookeeper的典型的应用场景。zookeeper已经被普遍应用于愈来愈多的大型分布式系统中了，其中包括：Dubbo的注册中心，HDFS的namenode和YARN框架的ResourceManager的HA（用zookeeper解决单点问题实现HA），HBase，Kafka等大数据和分布式系统框架中。咱们能够学习这些内容时，注意一下Zookeeper的具体的应用实现。

————————————————
版权声明：本文为CSDN博主「冷面寒枪biu」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处连接及本声明。
原文连接：https://blog.csdn.net/u013679744/article/details/79371022