0%

XXL-JOB-ADMIN 原理分析

在 xxl-job-admin 中 XxlJobScheduler 是一个重要的类,初始化了所有的会用到的组件:

  • JobScheduleHelper 任务调度组件
  • JobTriggerPoolHelper 任务执行的线程池组件
  • JobRegistryHelper 维护执行器 executor 信息的组件
  • JobLogReportHelper 日志访问组件
  • JobCompleteHelper 回调处理组件
  • JobFailMonitorHelper 失败监听组件,负责告警等

几个组件都是单独的线程或者线程来进行核心逻辑的处理,所以在一开始会被初始化,在后台持续工作。

同时 XxlJobScheduler 还持有了一个 address -> executorClientMap,之后在执行任务时候是通过具体的地址取得 Client 对象(一个 Http 代理)来通知执行器执行。

组件的功能

JobRegistryHelper

这一部分职责比较简单,主要负责其他 Admin 和 Executor 的注册和移除。内部有两部分:

  • registryOrRemoveThreadPool 收到的注册或者移除请求都交给线程池异步处理。
  • registryMonitorThread 定期清理超过 3 个心跳周期(3*30s)没有请求 register 的其他 Admin、Executor,同时更新对应的 XxlJobGroup 记录。

JobTriggerPoolHelper & XxlJobTrigger

在 XXL-JOB 中任务被触发主要有这几种方式:

  • 手动点击触发
  • job-admin 自动触发
  • 父任务完成触发子任务
  • 失败重试触发

无论是哪种方式都使用 JobTriggerPoolHelper#trigger 来完成任务执行。这就顺藤摸瓜看一下 JobTriggerPoolHelper 的实现。
这个类中维护了两个线程池:

  • fastTriggerPool 默认任务会被提交到这里执行
  • slowTriggerPool 慢速任务会被提交到这里执行

这一举措是为了避免慢速任务抢占过多的线程资源,耽搁那些本身执行就很快的任务。两个池子的核心池大小是 10,最大线程数是可以配置的,给的缓存队列大小是 1000。那么 XXL-JOB 按照什么依据切换任务执行的线程池呢?默认任务执行超过 10 次每次耗时超过 500ms 的话,之后会被转入 slowTriggerPool

确定完使用的线程池之后,会由 XxlJobTrigger#trigger 执行:

  1. 通过 jobId 查询保存的 jobInfo,这主要是我们新增任务时录入的配置。
  2. 一些任务参数、执行器地址、广播配置等,对 jobInfo 进行覆盖处理。这因为上层触发可能是由于手动执行、Failover 等可能,部分参数需要具体控制。
  3. 将任务提交给 XxlJobTrigger#processTrigger 进行处理,如果是分片广播的模式,会指定不同的分片参数循环调用。

来看 XxlJobTrigger#processTrigger

  1. 初始化并插入任务日志。
  2. 通过配置的路由策略初始化执行器的地址,如果采用空闲判断之类的方式,这一步就会访问配置的执行器。
  3. 执行任务 XxlJobTrigger#runExecutor。从之前了解的 XxlJobScheduler 中获取对应执行器的代理发出 Http 请求。
  4. 更新任务日志,主要内容是调度信息和执行器信息。

XxlJobTrigger 发送任务请求之后,剩下的任务执行,就看 Executor 的了。

JobCompleteHelper & XxlJobCompleter

这两个对象旨在处理回调行为(Executor 在完成了任务之后会把结果返回,和任务触发不是一个同步过程)。

  • XxlJobCompleter 主要用来更新任务处理结果信息,同时在成功的时候利用 JobTriggerPoolHelper#trigger 对子任务进行触发。
  • JobCompleteHelper 里面包含了一个监视线程和一组回调处理的线程池:
    • callbackThreadPool 则使用 XxlJobCompleter 处理统一的完成逻辑。
    • monitorThread 单一线程,进行间歇扫描。行为逻辑很简单,扫描了一直处于 处理中 状态的任务(XxlJobTrigger 留下了任务日志记录),且如果同时执行器不在线/心跳丢失(JobRegistryHelper 持久化),则将任务更新至 失败

JobFailMonitorHelper

通过上面 JobCompleteHelper 对正常回调和超时的任务更新完终态。如果有失败的任务,需要告警或者重试,这些动作都由 JobFailMonitorHelper 来完成。原理也是一样,通过一个线程去间歇扫描 XxlJobLog

JobLogReportHelper

这一组件主要对 XxlJobLog 进行数据统计,我们在登录控制台时候看到的表格视图等信息就是来源于这。

XXL-JOB-ADMIN 主要的逻辑就基本解读完了,可以从这几个异步任务的行为了解它大部分的业务。另一方面关于 Executor 的行为则较为简单,暂时没有进行总结。


(全文基于 2.3.0 版本)

谢谢支持!