ZooKeeper 典型运用场景一览

数据发布与订阅（装备中心）

发布与订阅模型，即所谓的装备中心，望文生义便是发布者将数据发布到ZK节点上，供订阅者动态获取数据，完结装备信息的会集式办理和动态更新。例如大局的装备信息，服务式服务结构的服务地址列表等就十分合适运用。

1. 运用中用到的一些装备信息放到ZK上进行会集办理。这类场景一般是这样：运用在发动的时分会主动来获取一次装备，一起，在节点上注册一个Watcher，这样一来，今后每次装备有更新的时分，都会实时告诉到订阅的客户端，历来抵达获取***装备信息的意图。

2. 散布式查找服务中，索引的元信息和服务器集群机器的节点状况存放在ZK的一些指定节点，供各个客户端订阅运用。

3. 散布式日志搜集体系。这个体系的中心作业是搜集散布在不同机器的日志。搜集器一般是依照运用来分配搜集使命单元，因而需求在ZK上创立一个以运用名作为path的节点P，并将这个运用的一切机器ip，以子节点的办法注册到节点P上，这样一来就能够完结机器改变的时分，能够实时告诉到搜集器调整使命分配。

4. 体系中有些信息需求动态获取，而且还会存在人工手动去修正这个信息的提问。一般是暴露出接口，例如JMX接口，来获取一些运转时的信息。引进ZK之后，就不必自己完结一套计划了，只要将这些信息存放到指定的ZK节点上即可。

留意：在上面说到的运用场景中，有个默许条件是：数据量很小，可是数据更新或许会比较快的场景。

负载均衡

这儿说的负载均衡是指软负载均衡。在散布式环境中，为了确保高可用性，一般同一个运用或同一个服务的供给方都会布置多份，抵达对等服务。而顾客就需求在这些对等的服务器中挑选一个来履行相关的事务逻辑，其间比较典型的是音讯中间件中的生产者，顾客负载均衡。

音讯中间件中发布者和订阅者的负载均衡，linkedin开源的KafkaMQ和阿里开源的 metaq都是经过ZooKeeper来做到生产者、顾客的负载均衡。这儿以metaq为例如讲下：

生产者负载均衡：metaq发送音讯的时分，生产者在发送音讯的时分有必要挑选一台broker上的一个分区来发送音讯，因而metaq在运转进程中，会把一切broker和对应的分区信息悉数注册到ZK指定节点上，默许的战略是一个顺次轮询的进程，生产者在经过ZK获取分区列表之后，会依照brokerId和partition的次序排列组织成一个有序的分区列表，发送的时分依照自始至终循环往复的办法挑选一个分区来发送音讯。

消费负载均衡： 在消费进程中，一个顾客会消费一个或多个分区中的音讯，可是一个分区只会由一个顾客来消费。MetaQ的消费战略是：

1. 每个分区针对同一个group只挂载一个顾客。

2. 假如同一个group的顾客数目大于分区数目，则多出来的顾客将不参加消费。

3. 假如同一个group的顾客数目小于分区数目，则有部分顾客需求额定承当消费使命。

在某个顾客毛病或许重启等状况下，其他顾客会感知到这一改变（经过 zookeeper watch顾客列表），然后从头进行负载均衡，确保一切的分区都有顾客进行消费。

命名服务(Naming Service)

命名服务也是散布式体系中比较常见的一类场景。在散布式体系中，经过运用命名服务，客户端运用能够依据指定姓名来获取资源或服务的地址，供给者等信息。被命名的实体一般可所以集群中的机器，供给的服务地址，长途目标等等——这些咱们都能够总称他们为姓名（Name）。其间较为常见的便是一些散布式服务结构中的服务地址列表。经过调用ZK供给的创立节点的API，能够很简略创立一个大局仅有的path，这个path就能够作为一个称号。

阿里巴巴集团开源的散布式服务结构Dubbo中运用ZooKeeper来作为其命名服务，保护大局的服务地址列表， 点击这儿检查Dubbo开源项目。在Dubbo完结中：

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

服务顾客发动的时分，订阅/dubbo/${serviceName}/providers目录下的供给者URL地址， 并向/dubbo/${serviceName} /consumers目录下写入自己的URL地址。

留意，一切向ZK上注册的地址都是暂时节点，这样就能够确保服务供给者和顾客能够主动感应资源的改变。 别的，Dubbo还有针对服务粒度的监控，办法是订阅/dubbo/${serviceName}目录下一切供给者和顾客的信息。

散布式告诉/和谐

ZooKeeper中特有watcher注册与异步告诉机制，能够很好的完结散布式环境下不同体系之间的告诉与和谐，完结对数据改变的实时处理。运用办法一般是不同体系都对ZK上同一个znode进行注册，监听znode的改变（包含znode自身内容及子节点的），其间一个体系update了znode，那么另一个体系能够收到告诉，并作出相应处理

1. 另一种心跳检测机制：检测体系和被检测体系之间并不直接相关起来，而是经过zk上某个节点相关，大大削减体系耦合。

2. 另一种体系调度形式：某体系有操控台和推送体系两部分组成，操控台的责任是操控推送体系进行相应的推送作业。办理人员在操控台作的一些操作，实际上是修正了ZK上某些节点的状况，而ZK就把这些改变告诉给他们注册Watcher的客户端，即推送体系，所以，作出相应的推送使命。

3. 另一种作业报告形式：一些相似于使命分发体系，子使命发动后，到zk来注册一个暂时节点，而且守时将自己的进展进行报告（将进展写回这个暂时节点），这样使命办理者就能够实时知道使命进展。

总归，运用zookeeper来进行散布式告诉和和谐能够大大下降体系之间的耦合

集群办理与Master推举

1. 集群机器监控：这一般用于那种对集群中机器状况，机器在线率有较高要求的场景，能够快速对集群中机器改变作出呼应。这样的场景中，往往有一个监控体系，实时检测集群机器是否存活。曩昔的做法一般是：监控体系经过某种手法（比方ping）守时检测每个机器，或许每个机器自己守时向监控体系报告“我还活着”。 这种做法可行，可是存在两个比较显着的问题：

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

2. 有必定的延时。

运用ZooKeeper有两个特性，就能够完结另一种集群机器存活性监控体系：

1. 客户端在节点 x 上注册一个Watcher，那么假如 x?的子节点改变了，会告诉该客户端。

2. 创立EPHEMERAL类型的节点，一旦客户端和服务器的会话完毕或过期，那么该节点就会消失。

例如，监控体系在 /clusterServers 节点上注册一个Watcher，今后每动态加机器，那么就往 /clusterServers 下创立一个 EPHEMERAL类型的节点：/clusterServers/{hostname}. 这样，监控体系就能够实时知道机器的增减状况，至于后续处理便是监控体系的事务了。

2. Master推举则是zookeeper中最为经典的运用场景了。

在散布式环境中，相同的事务运用散布在不同的机器上，有些事务逻辑（例如一些耗时的核算，网络I/O处理），往往只需求让整个集群中的某一台机器进行履行，其他机器能够同享这个成果，这样能够大大削减重复劳动，进步功能，所以这个master推举便是这种场景下的碰到的首要问题。

运用ZooKeeper的强共同性，能够确保在散布式高并发状况下节点创立的大局仅有性，即：一起有多个客户端恳求创立 /currentMaster 节点，终究必定只要一个客户端恳求能够创立成功。运用这个特性，就能很容易的在散布式环境中进行集群选取了。

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

上文中说到，一切客户端创立恳求，终究只要一个能够创立成功。在这儿略微改变下，便是答应一切恳求都能够创立成功，可是得有个创立次序，所以一切的恳求终究在ZK上创立成果的一种或许状况是这样： /currentMaster/{sessionId}-1 ,/currentMaster/{sessionId}-2,/currentMaster/{sessionId}-3 ….. 每次选取序列号最小的那个机器作为Master，假如这个机器挂了，因为他创立的节点会立刻小时，那么之后最小的那个机器便是Master了。

1. 在查找体系中，假如集群中每个机器都生成一份全量索引，不只耗时，而且不能确保彼此之间索引数据共同。因而让集群中的Master来进行全量索引的生成，然后同步到集群中其它机器。别的，Master推举的容灾办法是，能够随时进行手动指定master，便是说运用在zk在无法获取master信息时，能够经过比方http办法，向一个当地获取master。

2. 在Hbase中，也是运用ZooKeeper来完结动态HMaster的推举。在Hbase完结中，会在ZK上存储一些ROOT表的地址和HMaster的地址，HRegionServer也会把自己以暂时节点（Ephemeral）的办法注册到Zookeeper中，使得HMaster能够随时感知到各个HRegionServer的存活状况，一起，一旦HMaster出现问题，会从头推举出一个HMaster来运转，然后避免了HMaster的单点问题

散布式锁

散布式锁，这个首要得益于ZooKeeper为咱们确保了数据的强共同性。锁服务能够分为两类，一个是 坚持独占，另一个是 操控时序。

1. 所谓坚持独占，便是一切企图来获取这个锁的客户端，终究只要一个能够成功取得这把锁。一般的做法是把zk上的一个znode看作是一把锁，经过create znode的办法来完结。一切客户端都去创立 /distribute_lock 节点，终究成功创立的那个客户端也即具有了这把锁。

2. 操控时序，便是一切视图来获取这个锁的客户端，终究都是会被组织履行，仅仅有个大局时序了。做法和上面根本相似，仅仅这儿 /distribute_lock 现已预先存在，客户端在它下面创立暂时有序节点（这个能够经过节点的特点操控：CreateMode.EPHEMERAL_SEQUENTIAL来指定）。Zk的父节点（/distribute_lock）保持一份sequence,确保子节点创立的时序性，然后也形成了每个客户端的大局时序。

散布式行列

行列方面，简略地讲有两种，一种是惯例的先进先出行列，另一种是要比及行列成员聚齐之后的才共同按序履行。关于***种先进先出行列，和散布式锁服务中的操控时序场景根本原理共同，这儿不再赘述。 第二种行列其实是在FIFO行列的基础上作了一个增强。一般能够在 /queue 这个znode下预先树立一个/queue/num 节点，而且赋值为n（或许直接给/queue赋值n），表明行列巨细，之后每次有行列成员参加后，就判别下是否现已抵达行列巨细，决议是否能够开端履行了。这种用法的典型场景是，散布式环境中，一个大使命Task A，需求在很多子使命完结（或条件安排妥当）状况下才干进行。这个时分，但凡其间一个子使命完结（安排妥当），那么就去 /taskList 下树立自己的暂时时序节点（CreateMode.EPHEMERAL_SEQUENTIAL），当 /taskList 发现自己下面的子节点满意指定个数，就能够进行下一步按序进行处理了。