ZK_02Zookeeper经典应用场景
2023-05-17 10:09:22 11 举报
AI智能生成
Zookeeper经典应用场景
作者其他创作
大纲/内容
应用场景
注册中心
数据发布/订阅(常用于实现配置中心)
数据发布/订阅的一个常见的场景是配置中心
发布者把数据发布到 ZooKeeper 的一个或一系列的节点上,供订阅者进行数据订阅,达到动态获取数据的目的
特点
数据量小的KV
数据内容在运行时会发生动态变化
集群机器共享,配置一致
推拉结合
推: 服务端会推给注册了监控节点的客户端 Watcher 事件通知
拉: 客户端获得通知后,然后主动到服务端拉取最新的数据
负载均衡
分布式协调/通知
将不同的分布式组件有机结合起来的关键所在
一个在多台机器上部署运行的应用而言,通常需要一个协调者(Coordinator)来控制整个系统的运行流程
例如分布式事务的处理、机器间的相互协调等
引入这样一个协调者,便于将分布式协调的职责从应用中分离出来,从而大大减少系统之间的耦合性,而且能够显著提高系统的可扩展性
ZooKeeper 中特有watcher注册与异步通知机制,能够很好的实现分布式环境下不同系统之间的通知与协调,实现对数据变更的实时处理
使用方法
不同系统都对 ZK上同一个znode进行注册,监听znode的变化
znode本身内容
znode子节点的的内容
一个系统update了znode,那么另一个系统能 够收到通知,并作出相应处理
心跳检测机制
检测系统和被检测系统之间并不直接关联起来,而是通过zk上某个节点关联,大大减少系统耦合
系统调度模式
工作汇报模式
集群管理
Zookeeper 能够很容易的实现集群管理的功能
有多台 Server 组成一个服务集群
必须要一个“总管”知道当前集群中每台机器的服务状态,一旦有机器不能提供服务,集群中其它集群必须知道
当增加集群的服务能力时,就会增加一台或多台 Server,同样也必须让“总管”知道
从而做出调整重新分配服务策略
Zookeeper 的功能 Leader Election
在 Zookeeper 上创建一个 EPHEMERAL 类型的目录节点
每个 Server 在它们创建目录节点的父目录节点上调用 getChildren(String path, boolean watch) 方法并设置 watch 为 true`
Master选举
分布式锁
主要得益于ZooKeeper为我们保证了数据的强一致性,即用户只要完全相信每时每刻,zk集群中任意节点(一个zk server)上的相同znode的数据是一定是相同的
保持独占
所有试图来获取这个锁的客户端,最终只有一个可以成功获得这把锁
把zk上的一个znode看作是一把锁,通过create znode的方式来实现
所有客户端都去创建 /distribute_lock 节点,最终成功创建的那个客户端也即拥有了这把锁
控制时序
所有视图来获取这个锁的客户端,最终都是会被安排执行,只是有个全局时序了
客户端在它下面创建临时有序节点
分布式队列
同步队列
当一个队列的成员都聚齐时,这个队列才可用,否则一直等待所有成员到达
在约定目录下创建临时目录节点,监听节点数目是否是我们要求的数目
一个job由多个task组成,只有所有任务完成后,job才运行完成
可为job创建一个/job目录
在该目录下,为每个完成的task创建一个临时znode,一旦临时节点数目达到task总数,则job运行完成
FIFO 方式进行入队和出队操作
和分布式锁服务中的控制时序场景基本原理一致,入列有编号,出列按编号
统一命名服务
分布式应用中,通常需要有一套完整的命名规则,既能够产生唯一的名称又便于人识别和记住
分布式系统中,通过使用命名服务,客户端应用能够根据指定名字来获取资源或服务的地址,提供者等信息
被命名的实体通常可以是集群中的机器,提供的服务地址,远程对象等为名字(Name)
调用ZK提供的创建节点的API,能够很容易创建一个全局唯一的path,这个path就可以作为一个名称
树形的名称结构是一个有层次的目录结构,既对人友好又不会重复
Name Service 已经是 Zookeeper 内置的功能
Dubbo中使用ZooKeeper来作为其命名服务,维护全局的服务地址列表
服务提供者在启动的时候,向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址
服务消费者启动的时候,订阅/dubbo/${serviceName}/providers目录下的提供者URL地址,
并向/dubbo/${serviceName} /consumers目录下写入自己的URL地址
并向/dubbo/${serviceName} /consumers目录下写入自己的URL地址
Dubbo还有针对服务粒度的监控,方法是订阅/dubbo/${serviceName}目录下所有提供者和消费者的信息
注意点
所有向ZK上注册的地址都是临时节点
能够保证服务提供者和消费者能够自动感应资源的变化
配置管理
配置的管理在分布式应用环境中很常见,例如同一个应用系统需要多台 PC Server 运行,但是它们运行的应用系统的某些配置项是相同的
将配置信息保存在 Zookeeper 的某个目录节点中
将所有需要修改的应用机器监控配置信息的状态
一旦配置信息发生变化,每台应用机器就会收到 Zookeeper 的通知
然后从 Zookeeper 获取新的配置信息应用到系统中
发布与订阅模型
发布者将数据发布到ZK节点上,供订阅者动态获取数据
实现配置信息的集中式管理和动态更新
例如全局的配置信息,服务式服务框架的服务地址列表
配置管理实例
默认前提是:数据量很小,但是数据更新可能会比较快的场景
应用中用到的一些配置信息放到ZK上进行集中管理
应用在启动的时候会主动来获取一次配置,同时,在节点上注册一个Watcher
以后每次配置有更新的时候,都会实时通知到订阅的客户端,从而达到获取最新配置信息的目的
分布式搜索服务中
索引的元信息和服务器集群机器的节点状态存放在ZK的一些指定节点,供各个客户端订阅使用
分布式日志收集系统
核心工作是收集分布在不同机器的日志
收集器通常是按照应用来分配收集任务单元,因此需要在ZK上创建一个以应用名作为path的节点P
应用的所有机器ip,以子节点的形式注册到节点P上
这样就能够实现机器变动的时候,能够实时通知到收集器调整任务分配
系统中有些信息需要动态获取,并且还会存在人工手动去修改这个信息的发问
0 条评论
下一页