ZooKeeper使用场景总结

一、ZooKeeper有哪些应用场景

ZooKeeper 是一个典型的发布/订阅模式的分布式数据管理与协调框架。可以用其实现数据的发布与订阅。ZooKeeper 的顺序节点、临时节点等节点类型，结合Watcher的事件通知机制。可以方便的构建分布式系统中的一些核心功能。在这里整理了一下

1. 配置中心(数据发布/订阅)
2. 服务命名
3. 集群管理
4. Master选举
5. 分布式锁
6. 分布式队列
7. 负载均衡

一、数据发布订阅(动态配置)

1.1 实现目标

数据发布/订阅系统，在分布式系统中一般充当配置中心的角色，将一些各个服务需要的配置数据，发布到Zookeeper的节点上从而达到动态更新和实时获取的目的。实现配置信息的集中管理和实时更新。

1.1 基本原理

这些通用配置一般数据量比较小、并且可能在运行时发生变化，并且要求各个机器集群保持一致和共享。基本思路如下

1. 将配置信息存放在ZooKeeper节点上
2. 分布式应用的各个服务启动后主动到对应节点获取配置信息
3. 应用对关注的节点注册一个watcher，一旦收到更新就主动去获取节点最新配置数据

1.2 配置过程

二、服务统一命名服务

在分布式系统中，命名服务是分布式系统最基本的公共服务之一。一般被命名的实体一般是集群中的实体或者提供服务的对象。最常见的就是一些分布式框架例如 RPC、RMI 中通过命名服务来映射对应的实体。通过名称获取服务地址和信息，这样既可以避免服务地址之间的硬绑定，也让服务间的调用逻辑更清晰。

2.1 基本原理

ZooKeeper的目的：生成一个全局的路径，这个路径就能代表一个实体并作为一个名字，路径上的数据就是其名字指向的实体。实体背后可能是多个机器和节点、但是统一对外提供服务。

三、集群管理

分布式系统中，都是集群的方式运行的服务于是就需要对集群进行管理。对集群进行管理，就涉及两方面，监控和**控制。**在以前基于Agent分布式管理体系中，在每个服务器上安装Agent负责监控服务器的运行并向监控中心汇报。但是这样有一些缺点，1 大规模升级困难 2无法满足应用内部状况的监控 3面对各种异构系统无法全面适配。

3.1 基本原理

1. ZooKeeper的Watcher机制可以接收控制信息
2. Zookeeper的临时节点可以监控服务的存活状态

3.3 实现过程

1. 假设一个服务集群 cluster- A 的每个机器都在一个节点下注册自己，并各自创建自己的status节点。机器负责的job同样在该机器的节点下注册，和status平级
2. server节点定期通过更新status的状态来汇报自身的状态 这样就实现了**集群的监控，**一旦机器掉线长时间未汇报状态，便可以认为服务已经停止服务。
3. 假设server-1离线，便需要动态分配其下的job，此时可以根据其他节点status汇报，将原来 server-1 的job 进行动态分配，分配到其他server。有新的server加入也是同理。这就实现了简单地集群管理

四、服务注册中心&负载均衡

4.1 基本原理

使用zookeeper充当一个服务注册表，让多个服务提供者可以形成一个集群来负载请求，而消费者变可以通过服务注册表获取具体的服务访问地址去访问具体的服务提供者。并且可以自己实现具体的负载均衡算法，来分担请求。

4.2 实现过程

1. 在Zookeeper中，对某个服务注册一个永久节点作为对外提供服务的名称。
2. 所有的服务者提供者，在服务启动时在永久节点的Provider下对自己进行注册，也就是创建一个临时节点，节点中保存自己的调用地址等信息。
3. 消费者第一次调用对应的服务时，到对应的服务下的节点中获取所有的服务提供者，并保存在本地方便后续调用。并且监听对应的服务节点，一旦服务提供者有变动就去获取最新的服务注册表。
4. 消费者根据服务注册表，可以用本地的负载均衡算法去访问对应的服务。
5. 消费者下线或者上线，消费者都能收到Zookeeper的通知，如果所有的服务提供者都下线了，服务也就下线了。

五、集群master选举

对于某些服务，在一个集群中只需要让一个服务器执行即可，例如某些耗费资源的服务，或者某些定时处理任务，这个时候就需要从集群中选举出这个来执行任务的服务器。
如果只需要从多个应用中选出一个服务，利用数据库主键的唯一性、或者分布式锁等组件都可以实现。但是这样选举出来后，如果被选举的服务死亡集群的其他服务是无法得知的，如果想要快速进行动态的选举。这时Zookeeper就刚好满足这样的需求，利用Zookeeper节点的唯一性和Watcher机制即可。

5.1 实现过程

1. 例如一个集群A 有三个服务 s1 s2 s3 对于某个任务，只需要一个服务器来进行处理，这时需要从三台服务中选出一台来进行处理。
2. s1 s2 s3 同时尝试注册一个临时节点 /singleJob，这时只有一台服务能创建成功 假设为s1，此时它就负责执行该任务，其他节点则监控该节点。一旦该节点消失，说明s1可能无法提供服务了，此时s2 s3再尝试重新创建该节点 这就重新选举出来了一台提供服务的机器了。并且一旦提供服务的机器死亡，就可以立即选举出新的机器提供服务。
3. 这也是Zookeeper实现分布式排它锁的一种方式

六、分布式锁

在并发同步控制中，锁是非常常见的用来控制同步资源访问的一种手段。在单一服务内资源线程间的访问控制，可以利用JDK自带的一些锁实现。但是在分布式系统的服务之间的同步资源，就需要用到分布式锁了。

6.1 用Zookeeper实现排它锁

排它锁(Exclusive Lock) 也称为独占锁、写锁 X锁 。如果事物被施加排它锁，那么它将无法再被施加其他锁直至锁被释放，只允许占有锁的程序进行操作。

1. 定义锁定义一个临时节点作为锁 /exclusive_lock/lock
2. 获取锁 客户端尝试创建临时节点 /exclusive_lock/lock 如果此时节点不存在或者多个节点同时竞争，那么成功创建节点的服务相当于获得锁。其他创建失败的客户端，则添加watcher 关注锁，一旦锁释放则重新竞争。
3. 释放锁两种情况下会释放锁一个是业务执行完自动删除节点，另一种则是服务宕机节点被删除。

6.2 用Zookeeper实现共享锁

共享锁(shared lock) 简称S锁，又称为读锁。施加了读锁的资源无法再施加写锁，但是可以重复施加读锁。直到所有的锁被释放，才可以重新施加写锁。

1. 定义锁同样是通过一个节点来表示锁，例如 /shared_lock/[hostname]-读/写-序号
2. 申请锁获取共享锁时，到锁对应的节点下创建一个临时节点，如果施加读锁 则格式为 /shared_lock/host1-R-001 如果是写锁则 /shared_lock/host1-W-001
3. 获得锁
   1. 如果施加的读锁，并且所有比自己序号小的节点都是读锁那么自动获得读锁，否则则监听每次节点变化，直到存在的写锁执行完成释放掉。
   2. 如果施加的写锁，如果自己是序号最小的节点则获得锁。则需要等待需要监听所有子节点的变化，直到自己序号称为最小则获得锁
4. 羊群效应如果某个资源施加锁的资源过多，释放一个节点时，所有其他节点都会收到watcher并且读取节点列表，这就产生了大量的多余的通知事件 称为羊群效应。
5. **改进锁监听 **
   1. 施加读锁的客户端只监听比自己小的最近的一个写锁的节点即可
   2. 施加写锁的客户端只监听比自己小的最近的一个节点即可。
6. 总结对于共享锁的实现，Zookeeper的方案也包含了写锁，这样设计的非常巧妙，如果写锁和读锁分开两个Znode节点控制，那么加锁的过程将非常复杂，且可能无法保证一致性。

七、分布式队列实现

利用Zookeeper可以实现两类分布式队列，一种是常规的FIFO先入先出队列，另一种是元素聚集到一定数量同意安排执行的Barrier模型

7.1 实现FIFO

与共享锁的机制类似，但是不分节点类型

1. 队列作为一个公共节点 /queue_fifo
2. 入队操作 就是客户单在这个节点下创建一个临时顺序节点
3. 确定自己在所有子节点的顺序，如果自己序号不是最小，则向离自己最接近的比自己小的节点注册Watcher监听
4. 出队操作 收到Watcher监听后，判断自己是否是最小的如果是就出队执行，并删除临时节点。

7.2 Barrier分布式屏障

1. 和FIFO类似，创建一个节点代表队列 /queue_barrier
2. 将Barrier值 10 设置到节点 /queue_barrier 中
3. 队列的消费者 监听 /queue_barrier 子节点变更，和内容变更
4. 每次收到通知，判断子节点数量是否满足 Barrier值 10
5. 如果满足 Barrier值 则获取所有子节点出队列处理。