ZK_02Zookeeper经典应用场景

注册中心

数据发布/订阅的一个常见的场景是配置中心

发布者把数据发布到 ZooKeeper 的一个或一系列的节点上，供订阅者进行数据订阅，达到动态获取数据的目的

数据量小的KV

数据内容在运行时会发生动态变化

集群机器共享，配置一致

特点

推: 服务端会推给注册了监控节点的客户端 Watcher 事件通知

拉: 客户端获得通知后，然后主动到服务端拉取最新的数据

推拉结合

数据发布/订阅（常用于实现配置中心）

负载均衡

将不同的分布式组件有机结合起来的关键所在

例如分布式事务的处理、机器间的相互协调等

一个在多台机器上部署运行的应用而言，通常需要一个协调者(Coordinator)来控制整个系统的运行流程

引入这样一个协调者，便于将分布式协调的职责从应用中分离出来，从而大大减少系统之间的耦合性，而且能够显著提高系统的可扩展性

ZooKeeper 中特有watcher注册与异步通知机制，能够很好的实现分布式环境下不同系统之间的通知与协调，实现对数据变更的实时处理

znode本身内容

znode子节点的的内容

一个系统update了znode，那么另一个系统能 够收到通知，并作出相应处理

不同系统都对 ZK上同一个znode进行注册，监听znode的变化

检测系统和被检测系统之间并不直接关联起来，而是通过zk上某个节点关联，大大减少系统耦合

心跳检测机制

系统调度模式

工作汇报模式

使用方法

分布式协调/通知

有多台 Server 组成一个服务集群

必须要一个“总管”知道当前集群中每台机器的服务状态，一旦有机器不能提供服务，集群中其它集群必须知道

当增加集群的服务能力时，就会增加一台或多台 Server，同样也必须让“总管”知道

从而做出调整重新分配服务策略

Zookeeper 能够很容易的实现集群管理的功能

在 Zookeeper 上创建一个 EPHEMERAL 类型的目录节点

Zookeeper 的功能 Leader Election

集群管理

Master选举

主要得益于ZooKeeper为我们保证了数据的强一致性，即用户只要完全相信每时每刻，zk集群中任意节点（一个zk server）上的相同znode的数据是一定是相同的

所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁

把zk上的一个znode看作是一把锁，通过create znode的方式来实现

所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁

保持独占

所有视图来获取这个锁的客户端，最终都是会被安排执行，只是有个全局时序了

客户端在它下面创建临时有序节点

控制时序

分布式锁

当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达

在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目

可为job创建一个/job目录

在该目录下，为每个完成的task创建一个临时znode，一旦临时节点数目达到task总数，则job运行完成

一个job由多个task组成，只有所有任务完成后，job才运行完成

同步队列

和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号

span style=\

分布式队列

分布式应用中，通常需要有一套完整的命名规则，既能够产生唯一的名称又便于人识别和记住

被命名的实体通常可以是集群中的机器，提供的服务地址，远程对象等为名字（Name）

调用ZK提供的创建节点的API，能够很容易创建一个全局唯一的path，这个path就可以作为一个名称

分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息

树形的名称结构是一个有层次的目录结构，既对人友好又不会重复

Name Service 已经是 Zookeeper 内置的功能

服务提供者在启动的时候，向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址

服务消费者启动的时候，订阅/dubbo/${serviceName}/providers目录下的提供者URL地址， 并向/dubbo/${serviceName} /consumers目录下写入自己的URL地址

Dubbo还有针对服务粒度的监控，方法是订阅/dubbo/${serviceName}目录下所有提供者和消费者的信息

Dubbo中使用ZooKeeper来作为其命名服务，维护全局的服务地址列表

能够保证服务提供者和消费者能够自动感应资源的变化

所有向ZK上注册的地址都是临时节点

注意点

统一命名服务

配置的管理在分布式应用环境中很常见，例如同一个应用系统需要多台 PC Server 运行，但是它们运行的应用系统的某些配置项是相同的

将所有需要修改的应用机器监控配置信息的状态

一旦配置信息发生变化，每台应用机器就会收到 Zookeeper 的通知

然后从 Zookeeper 获取新的配置信息应用到系统中

将配置信息保存在 Zookeeper 的某个目录节点中

发布者将数据发布到ZK节点上，供订阅者动态获取数据

实现配置信息的集中式管理和动态更新

例如全局的配置信息，服务式服务框架的服务地址列表

发布与订阅模型

默认前提是：数据量很小，但是数据更新可能会比较快的场景

应用在启动的时候会主动来获取一次配置，同时，在节点上注册一个Watcher

以后每次配置有更新的时候，都会实时通知到订阅的客户端，从而达到获取最新配置信息的目的

应用中用到的一些配置信息放到ZK上进行集中管理

索引的元信息和服务器集群机器的节点状态存放在ZK的一些指定节点，供各个客户端订阅使用

分布式搜索服务中

核心工作是收集分布在不同机器的日志

收集器通常是按照应用来分配收集任务单元，因此需要在ZK上创建一个以应用名作为path的节点P

应用的所有机器ip，以子节点的形式注册到节点P上

这样就能够实现机器变动的时候，能够实时通知到收集器调整任务分配

分布式日志收集系统

系统中有些信息需要动态获取，并且还会存在人工手动去修改这个信息的发问

配置管理实例

配置管理

应用场景

Zookeeper经典应用场景