C/C++教程

分布式调度引擎 elastic-job3 源码分析 (四) 核心服务 I

本文主要是介绍分布式调度引擎 elastic-job3 源码分析 (四) 核心服务 I,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

1. 背景

调度引擎是关键的基础设施,不但是定时执行任务,更是大规模分布式任务引擎,分布式并行处理平台,管理计算节点集群,提供高吞吐的可伸缩的数据处理能力。

公司日益增长的业务,对调度引擎高吞吐,高并发的要求也快速增长,需构建一个无中心,管理大集群,健壮分片容错的任务调度任务平台,支撑业务发展。

同时,分布式调度引擎也是 datax,可观测-性能指标组件(sentinel dashboard)分布式改造的核心技术

2. 参考

芋道源码作业调度中间件 Elastic-Job 源码解析合集_芋道源码-CSDN博客

elastic-job - 文集 - 简书

3. 术语

无中心/有中心分布式 有中心分布式设置中心节点负责集群协调和元数据保存等工作,例如 xxl-job 的 admin/executor, dolphin-scheduler master-worker 都是有中心分布式设计;真正无中心设计很少,大部分是节点平等,都可以通过选举成为主节点,也就是,任何一个节点都可以成为中心

脑裂 无中心分布式设计,当网络出现问题,节点分割成多个集群,集群间因不能通讯而不能达到状态一致,通常解决方案是集群节点数奇数,节点数少于总数的集群中一半停止工作

分片/容错 分片是调度平台很重要的特性,调度处理大规模数据,需要分片执行,分片执行带来新的问题,分片失败,平台回收分片,转移到其他节点执行

5 详细分析

服务可分为功能服务和核心服务,其中核心服务支撑功能服务的服务,功能任务有任务注册,任务执行,失效转移等,是调度平台的”业务”功能

5.6 核心服务

5.6.1 znode 结构

znode 设计是 zookeeper 分布式协调的灵魂,zk 的临时 znode,持久 znode,watch 机制

本文分析的核心,服务如何使用 znode,znode 间组合使用

5.6.2 注册中心和 znode 存储服务

注册中心属于生态一部分,但注册中心主要用在 znode 存储服务,合起来一起看

JobNodeStorage/CoordinatorRegistryCenter 两个类名字有点名不副实,CoordinatorRegistryCenter 才是 znode 节点存取;JobNodeStorage 更多是 znode”应用”:

executeInLeader 主节点选举

addDataListener 注册 znode 监听

executeInTransaction znode 操作事务 TransactionExecutionCallback

AbstracJobListener znode 事件监听器基类

LeaderExecutionCallback 主节点选举后回调

TransactionExecutionCallback znode 事务操作

5.6.3 监听服务

总体来说,监听服务分两大类,quartz 和分布式(zk)

本文只关注 zk 部分,elastic-job 自身也只实现 zk 部分,quartz 部分留接口给用户,其他的核心服务都依赖监听服务,捕获 znode 事件,执行相应服务逻辑,因此监听服务非常关键服务,是其他服务分析的入口

ListenerManager 监听管理器的集中管理

AbstractListenerManager/ AbstractJobListener 其他服务继承,实现服务的监听管理接入的监听器实现

RegistryCenterConnectionStateListener 连接状态的监听器,连接断开暂停作业,重连后,重新初始化作业,清除分片,重启作业

Ø 谁使用:几乎所有核心服务

Ø 依赖服务:

- znode 存储服务/注册中心 znode 节点存取,监听器注册

5.6.4 分片服务(sharding)

分片是分布式任务不可或缺的特性,任务分片并行执行,极大提高处理能力,分片伴随弹性计算,节点发现,容错等能力,是分布式调度的体现

elastic-job 实现了静态分片和分片容错,当作业满足分片条件时,设置需要分片标记,等到作业执行时,判断有该标记后执行作业分配

分片监听

elastic-job 的分片是先设置需要分片标记,等到需要的时候再实际分片,哪里设置分片?

ListenServersChangedJobListener 监听 server znode 和 instance znode,对于一个作业,server 可有对应多个 instance,因此 server 的上下线,同时接收到 server 和 instance 事件

server 节点是持久 znode,所以服务事件只有上线和 server enabled/disabled 变更

ShardingTotalCountChangedJobListener 监听作业配置分片数变更

另外,诊断服务也定时设置分片标记

分片

下面分析分片,分片就是分配任务到各个在线运行实例节点

分片入口方法 ShardingService.shardingIfNecessary,回顾一下作业执行,

分片在 getShardingContexgts 完成

优先处理失效分片,如果没有,调用 ShardingService.shardingIfNecessary 正常作业分片,最终分片封装到 ShardingContexts

接下来分片代码

分片在主节点完成

LeaderService#isLeaderUntilBlock/blockUntilShardingCompleted 若非主节点等待分片完成

waitingOtherShardingItemCompleted 等待当前执行中的分片完成,依赖 monitor execution 配置

*分片运行依赖 monitorExecution 配置,也就是等不等待完成主要是看监控不监控,感觉主次没搞好;这里也反应了分片要严格按照配置要求,像失效转移分片改变需要另行处理

jobNodeStorage.fillEphemeralJobNode(ShardingNode.PROCESSING, "") 标记分片处理中,

写入/leading/sharding/processing

*processing znode 只有在非主节点等待分片完成是用到,由于 necessary 必定存在,只为监控使用

resetShardingInfo

重写分片 znode,去掉/sharding/{itemNum}/instance 分片分配,剪掉之前可能多出的分片 znode

JobShardingStrategy spi 载入,有多种策略,属于基础(infra)包,细节就不分析

最后事务写入分片分配使用 PersistShardingInfoTransactionExecutionCallback

分片分配给那个作业运行实例

清理 znode,需要分片标记和分片处理中标记

Ø 谁使用:

- 作业执行 作业分片,获取分片信息

- 诊断服务 设置分片标记,处理分布式环境下,离线作业运行实例未处理分片

Ø 依赖服务:

- znode 存储服务/注册中心 znode 节点存取,监听器注册

- 选主服务 分片需主节点执行

这篇关于分布式调度引擎 elastic-job3 源码分析 (四) 核心服务 I的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!