[大数据]系列二：Zookeeper的典型应用场景

1. 数据发布/订阅

数据发布/订阅系统也就是我们常说的配置中心，也就是发布者将数据发布到zookeeper的一个或一系列节点上，供订阅者进行订阅，进而达到动态获取数据的目的。实现配置信息的集中式管理和数据的动态更新。

数据发布/订阅系统一般来说有服务端推送和客户端拉（通常是通过开辟一个线程进行定时轮询拉取）这两种模式：

zookeeper采用的是推拉结合的方式：客户端注册自己感兴趣的节点，一旦节点数据变更，服务端就会向对应的客户端发送watcher通知，收到通知后主动向服务端获取最新的数据。

比如进行数据库配置的管理。

2. 负载均衡

所谓的负载均衡就是对多个计算机、网络连接、cpu等进行合理分配，以达到优化资源使用、最大化吞吐率等目的。我们需要在这些集群中选取一个读武器来执行相关的业务逻辑，这个比较核心的就是dns服务。

2.1 域名配置

为了解决规模变大，域名解析难以管理的问题，这时候zookeeper解决了这个问题。

可以看出我们可以先创建ddns节点，然后在每个下面在创建对应的应用以及域名节点，然后往里面写入对应的ip地址。

2.2 域名解析

和传统的域名解析不同，zookeeper上的域名解析需要每个应用自己负责。每个应用会注册自己感兴趣的节点以及Watcher监听来及时收到域名变更通知。

2.3 域名变更

如果遇到对应的ip变更，这时候需要进行域名变更操作，只需要指定对应的节点进行更新操作，zookeeper就可以向订阅的客户端发送事件通知

3. 命名服务

命名服务也是常见的场景之一。在分布式系统中，被命名的实体可能是集群中的机器、提供的服务地址以及远程对象，比如一些RPC框架中的服务列表地址，客户端可以通过命名服务根据指定名字来获取资源的实体、服务地址和提供者的信息等。在分布式环境中，上层应用仅仅需要一个全局唯一的名字，也就是分布式全局唯一ID的分配机制。

一个我们熟悉的就是UUID，包含一个32位字符和4个短线组成的字符串。但是长度过长而且表意不明。

?

• 所有的客户端都会根据自己的任务类型，在指定类型任务下通过调用create（）接口来创建顺序节点

• 节点创建完毕进行拼接就会形成一个完整的节点名

4. 分布式协调/通知

分布式应用之间比如分布式事务的处理，机器之间的相互协调，比如watcher机制。

zookeeper可以根据其临时节点的特性来实现心跳检测。每个机器向zookeeper注册临时节点，如果该节点存在，则说明对应的机器还存活。

5. 两大特性

1. 数据节点变更，可以通过watcher机制知道发生了变更

2. 对在zookeeper上创建的临时节点，一旦客户端和服务器之间的绘画失效，那该临时节点也就会被自动清除

6. master选举

比如一个集群准备选举一个master，则集群中的每个机器都会向zookeeper中创建节点，创建成功的节点则成为master，没有成功的节点，则在下面进行注册，一旦master挂了，就会进行通知（强一致性，只会有一个唯一的事务id）

7. zookeeper实现锁的创建

可以创建对应的共享锁和排他锁。基本原理就是创建对应的临时节点，一旦创建成功，其他的节点就不能再进行创建了，如果客户端宕机或者客户端执行完业务逻辑删除节点就会释放锁，然后watcher机制都会让其他的锁进行竞争。

共享锁

也称之为读锁，如果对某个对象加上了共享锁，那么只能对该对象进行读操作。

?

创建锁步骤如下：

• 创建完节点后，获取/sharedLock节点下的所有子节点，并对该节点注册子节点变更的Watcher监听

• 确定自己的节点序号在所有子节点的顺序

• 对于读请求：如果没有比自己序号小的节点，或者比自己序号小的节点都是读请求，那么表明自己已成功获取共享锁，同时开始执行读取逻辑

• 对于写请求：自己不是最小的序号就需要等待

• 接收到watcher通知后重复上述步骤

上述的步骤会产生所谓的羊群效应，也就是大多数在收到通知后还是没有获得锁，那么这样是没有意义的，因此我们需要更新，也就是对比自己小的节点的定义进行更新：

• 对于读请求：比自己小的就是最后一个写请求的watcher监听器

• 对于写监器：就是比自己序号小的最后一个节点