vip

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

Ø 依赖核心服务：

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

- 调度服务

- 失效转移