分布式调度引擎 elastic-job3 源码分析 (三) - 作业执行

分布式调度引擎 elastic-job3 源码分析 (一) 概述

分布式调度引擎 elastic-job3 源码分析 (二) 作业模型和注册

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

分布式调度引擎elastic-job3源码分析(五)-核心服务 II(vip)

分布式调度引擎elastic-job3源码分析(六)-失效转移(vip​​​​​​)

elastic-job 作业执行是分片执行，支持错过重调度，重叠执行转错过重调度，作业运行节点下线的失效转移，服务节点/运行实例变更的重分片

作业执行逻辑

作业触发两个来源，quartz 调度触发和失效转移触发，分片分为失效转移和常规调度两部分

*作业和分片应该按两种来源分支，逻辑比较清晰

作业执行类图

ListJob/JobItemExecutor/ElasticJob elastic-job 可以看作分布式 quartz，分片作业由 quartz 调度器调起

ListJob 实现了 quartz 的 job 接口作为 quartz 与 elastic-job 作业的桥接，用 quartz 的参数机制注入 ElasticJobExecutor

这样静悄悄地桥接到 elastic-job 的领地

ElasticJobExecutor elastic-job 作业执行代码

分 5 步：

作业分片，重叠执行检查，执行作业分片，执行错过(missfired)分片，失效转移

其中，作业分片参看分片服务, 失效转移参看失效转移

a．重叠执行检查

quartz 可使用 @DisallowConcurrentExecution 配置不允许作业重叠执行，即当前作业未执行完，下一个作业不触发，elastic-job 的 quartz 作业实现 LiteJob 并没有该注解，但 elastic-job 设置执行线程池为 1，org.quartz.jobStore.misfireThreshold = 1(毫秒)，实际不重叠执行，因此， elastic-job 是自己管理重叠执行逻辑，是否重叠执行依据是作业分片执行前检查是否有分片执行(running)，如果有就设置 missfired，通过重调错过执行补偿执行

写入 missfired，后面通过错过重调度处理

*依赖 monitorExecution 配置，missfired 是调度的业务功能，怎么会依赖是否监控

*不支持 2 次及以上的错过重调度

*建议：增加一个/leader/overlap 设置是否需要重叠执行

b. 常规执行作业

JobFacade.registerJobBegin 作业分片执行前，写入 zk 分片项 running 状态，znode /{itemNum}/running

JobFacade.registerJobCompleted 作业执行结束，删除 zk 分片项 znode running，删除失效转移 znode

updateFailoverComplete 移除失效转移分片，这里要跳到分片的处理逻辑回顾一下

失效转移是触发(trigger)执行，处理失效转移分片, 名字 update，实际上操作是移除/failover 和/failovering

接着分析分片执行代码

作业执行是分片执行，每个运行实例(instance)可能分到多个分片，需要线程池并行执行作业分片，线程池实现 Reloadable 接口，支持 spi 载入和热配置

分片执行代码，使用 JobItemExecutor，elasic-job 不同的执行器逻辑，如 script，dataflow，http

c. 错过重调度

错过作业重调度(missfired)，elastic-job 来说，missfired 来源于常规执行和失效转移分片执行并行中发生

elastic-job 使用 quartz 机制，TriggerListener 的 triggerMisfired 处理触发错失，设置 znode /misfired 节点，使用 elastic-job 的错过重调度机制补偿执行

正常作业执行后，重执行错过的作业，与正常执行逻辑一致

Misfired 分片与当前分片的交集

看一下分片逻辑

两个场景，失效转移触发的作业，常规触发的作业

*分片应加上错过重调度的考虑，目前分片只考虑正常分片和 failover

Ø 依赖核心服务：

- 分片服务 作业分配，获取分片信息

- 调度服务

- 失效转移