[基础知识点扫盲]---(1)zookeeper的4种使用场景

Author：赵志乾
Date：2019-04-13
Declaration：All Right Reserved！！！

zookeeper作为分布式系统的一种基础组件，有着广泛的应用场景。今天我们一起来看一下最常用的4种场景：

·分布式锁

·元数据/配置信息管理

·分布式协调

 ·高可用

1、分布式锁

分布式系统中，各服务大多都是多实例部署，即多个服务实例操作同一数据源，为此需要引入同步机制。分布式锁是分布式系统中最常用的一类同步机制，其具体的实现方式包括：Redis分布式锁、关系数据库分布式锁、zookeeper分布式锁等等。其实，所谓的分布式锁，就是将请求经过一集中式节点进行统一拦截，从而实现同步处理。

如下图所示：服务A拥有两个部署实例A1和A2。外部有两个修改数据记录Data1的请求分别经由A1和A2进入系统，此时zookeeper分布式锁的工作机制表述如下：

请求1经A1进入系统，先向zookeeper申请修改数据Data1的锁，即在zookeeper上注册节点data1；注册成功，则表明申请成功，可以执行后续的修改流程；请求2经A2进入系统，同样向zookeeper申请修改数据Data1的锁，但由于该锁已被A1实例上的请求1所持有，所以申请失败，其紧接着对锁节点data1添加监听事件，等待请求1释放锁；请求1处理完后，释放持有的分布式锁，即删除zookeeper上的节点data1，请求2收到节点变化事件，开始尝试获取锁，即向zookeeper注册节点data1；

2、元数据/配置信息管理

分布式系统中，部分服务实例的配置信息或者元数据并不是写死的，即为了保证灵活性和动态扩展性，往往会在服务启动时，将元数据/配置信息注册到某一集中式节点，然后由其他服务进行获取。比如：dubbo的注册中心使用zookeeper来存放服务提供者和消费者的配置信息。

元数据管理原理如下：服务实例A1和A2向zookeeper注册元数据信息，实例B在启动时从zookeeper读取已注册的信息。为了实现注册节点的动态扩展，实例B会向zookeeper注册监听事件；之后实例A3向zookeeper注册，zookeeper将事件通知给实例B，此时实例B将会感知到有元数据信息发生变化。

3、分布式协调

分布式系统中，为了提高部分服务间处理流程的响应速度，往往会将同步处理转化为异步处理。此时，便需要有一角色负责各服务实例之间异步处理流程的协调。

如下图所示：用户请求完整的处理流程要经过实例A和B的共同处理，但由于B的处理过程非常耗时，为此通过消息队列将耗时的同步请求调用转化为异步请求。其处理流程说明如下：请求数据经实例A处理后，发送消息到MQ便可返回，并在zookeeper上注册节点，并监听节点数据的变化；实例B从MQ获取请求数据完成处理，并修改zookeeper上的节点数据，触发事件通知，此时实例A收到zookeeper事件通知，完成后续的处理过程，从而将请求的处理串联起来。

4、高可用

分布式系统中，部分服务为了拥有高可用性，往往会采用一主多从模式，即一个主节点负责正常流程处理，其他从节点处于随时待命状态，当主节点出现故障时，从节点中的某一个会晋升为主节点，从而保证服务的可用性。

如下图所示：实例A1为主节点，在zookeeper上注册节点，实例A2、A3为从节点，监听A1注册的节点；当A1实例出现故障时，其注册的临时节点会被清除，从而触发事件通知，A2、A3收到通知事件后，同时向zookeeper注册主节点，即进行抢主操作；注册成功实例会晋升为主节点，而另一节点则依然为从节点，并重新注册监听zookeeper事件。