# Zookeeper应用场景

* 数据发布订阅
* 负载均衡
* 命名服务
* 分布式协调
* 集群管理
* 统一配置文件管理
* 分布式队列
* 分布式锁
* master节点选举

## 数据发布订阅

发布与订阅，类似于消息队列MQ（amq，rmq..）,dubbo发布者把数据存储在znode上，订阅者会读取这个数据。

[Zookeeper的数据发布与订阅模式](https://blog.csdn.net/ZuoAnYinXiang/article/details/50937892)

## 统一命名服务

分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务。类似于域名与ip之间对应关系，域名容易记住。通过名称来获取资源或服务的地址，提供者等信息按照层次结构组织服务/应用名称可将服务名称以及地址信息写到Zookeeper上，客户端通过Zookeeper获取可用服务列表类。

## 统一配置文件管理

分布式环境下，配置文件管理和同步是一个常见问题。一个集群中，所有节点的配置信息是一致的，比如Hadoop。对配置文件修改后，希望能够快速同步到各个节点上配置管理可交由Zookeeper实现。可将配置信息写入Zookeeper的一个znode上。各个节点监听这个znode。一旦znode中的数据被修改，zookeeper将通知各个节点。

> 统一配置管理，即只需要部署一台服务器，则可以把相同的配置文件同步更新到其他所有服务器，此操作爱云计算中用的特别多，如redis统一配置。
>
> 如下微服务中，部署了多台服务，并且都使用了redis，使用zookeeper，当修改了redis的配置，则可以只修改一台电脑，然后通过这一台电脑再分发到其他的电脑。
>
> ![](https://2663285815-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LfnT31deyW842ExZVDh%2F-LfnTAqGO4YVUXXW5O6w%2F-LfnTJmvGMy_dycvvjyS%2F1.png?generation=1558862984146251\&alt=media)

## 集群管理

分布式环境中，实时掌握每个节点的状态是必要的。可根据节点实时状态作出一些调整。Zookeeper可将节点信息写入Zookeeper的一个znode上。监听这个znode可获取它的实时状态变化。典型应用比如Hbase中Master状态监控与选举。

## 分布式通知/协调

分布式环境中，经常存在一个服务需要知道它所管理的子服务的状态。例如，NameNode须知道各DataNode的状态，JobTracker须知道各TaskTracker的状态。心跳检测机制和信息推送也是可通过Zookeeper实现。

## 分布式锁

Zookeeper是强一致的。多个客户端同时在Zookeeper上创建相同znode，只有一个创建成功。Zookeeper实现锁的独占性。多个客户端同时在Zookeeper上创建相同znode ，创建成功的那个客户端得到锁，其他客户端等待。Zookeeper 控制锁的时序。各个客户端在某个znode下创建临时znode （类型为CreateMode. EPHEMERAL \_SEQUENTIAL），这样，该znode可掌握全局访问时序。

> 提供分布式锁，分布式环境中不同进程之间争夺资源，类似于多线程中的锁。

## 分布式队列

两种队列。当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达，这种是同步队列。队列按照 FIFO 方式进行入队和出队操作，例如实现生产者和消费者模型。（可通过分布式锁实现）

同步队列。一个job由多个task组成，只有所有任务完成后，job才运行完成。可为job创建一个/job目录，然后在该目录下，为每个完成的task创建一个临时znode，一旦临时节点数目达到task总数，则job运行完成。

## master节点选举

master节点选举，节点挂了以后，从节点就会接手工作，并且保证这个节点是唯一 ，这也是所谓首脑模式，从而保证我们 集群是高可用。