定时任务(4)：XXL-JOB

type

status

date

Jul 26, 2024 03:19 AM

slug

summary

概述

XXL-JOB简介

虽然Quartz 的功能已经能够满足我们对定时任务的诉求，但是距离生产可用、好用，还是有一定的距离，因为Quartz 只提供了任务调度的功能，不提供管理任务的管理与监控控制台，需要自己去做二次封装。当时，因为社区中找不到合适的实现这块功能的开源项目，所以我们就自己进行了简单的封装，满足我们的管理与监控的需求。

不过现在呢，开源社区中已经有了很多优秀的调度任务中间件。其中，比较有代表性的就是 XXL-JOB 。其对自己的定义如下：

XXL-JOB 是一个轻量级分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。

特性

XXL-JOB 提供了 35 点特性列表，我们将其重新整理如下：

归类不一定绝对严谨。
简单喵一眼，反正也记不住。在使用中，慢慢感受吧。

功能强大

1、简单：支持通过 Web 页面对任务进行 CRUD 操作，操作简单，一分钟上手；

2、动态：支持动态修改任务状态、启动/停止任务，以及终止运行中任务，即时生效；

15、事件触发：除了”Cron 方式”和”任务依赖方式”触发任务执行之外，支持基于事件的触发任务方式。调度中心提供触发任务单次执行的 API 服务，可根据业务事件灵活触发。

18、GLUE：提供 Web IDE，支持在线开发任务逻辑代码，动态发布，实时编译生效，省略部署上线的过程。支持 30 个版本的历史版本回溯。

19、脚本任务：支持以 GLUE 模式开发和运行脚本任务，包括 Shell、Python、NodeJS、PHP、PowerShell 等类型脚本;

20、命令行任务：原生提供通用命令行任务 Handler（Bean任务，”CommandJobHandler”）；业务方只需要提供命令行即可；

21、任务依赖：支持配置子任务依赖，当父任务执行结束且执行成功后将会主动触发一次子任务的执行, 多个子任务用逗号分隔；

23、自定义任务参数：支持在线配置调度任务入参，即时生效；

25、数据加密：调度中心和执行器之间的通讯进行数据加密，提升调度信息安全性；

30、跨平台：原生提供通用 HTTP 任务Handler（Bean 任务，”HttpJobHandler”）；业务方只需要提供 HTTP 链接即可，不限制语言、平台；

31、国际化：调度中心支持国际化设置，提供中文、英文两种可选语言，默认为中文；

高性能

13、分片广播任务：执行器集群部署时，任务路由策略选择”分片广播”情况下，一次任务调度将会广播触发集群中所有执行器执行一次任务，可根据分片参数开发分片任务；

14、动态分片：分片广播任务以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度。

24、调度线程池：调度系统多线程触发调度运行，确保调度精确执行，不被堵塞；

29、全异步：任务调度流程全异步化设计实现，如异步调度、异步运行、异步回调等，有效对密集调度进行流量削峰，理论上支持任意时长任务的运行；

33、线程池隔离：调度线程池进行隔离拆分，慢任务自动降级进入 ”Slow” 线程池，避免耗尽调度线程，提高系统稳定性；

高可用

3、调度中心 HA（中心式）：调度采用中心式设计，“调度中心”自研调度组件并支持集群部署，可保证调度中心 HA；

4、执行器 HA（分布式）：任务分布式执行，任务”执行器”支持集群部署，可保证任务执行 HA；

7、路由策略：执行器集群部署时提供丰富的路由策略，包括：第一个、最后一个、轮询、随机、一致性 HASH、最不经常使用、最近最久未使用、故障转移、忙碌转移等；

8、故障转移：任务路由策略选择”故障转移”情况下，如果执行器集群中某一台机器故障，将会自动 Failover 切换到一台正常的执行器发送调度请求。

9、阻塞处理策略：调度过于密集执行器来不及处理时的处理策略，策略包括：单机串行（默认）、丢弃后续调度、覆盖之前调度；

10、任务超时控制：支持自定义任务超时时间，任务运行超时将会主动中断任务；

11、任务失败重试：支持自定义任务失败重试次数，当任务失败时将会按照预设的失败重试次数主动进行重试；其中分片任务支持分片粒度的失败重试；

22、一致性：“调度中心”通过DB锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行；

监控治理

5、注册中心: 执行器会周期性自动注册任务, 调度中心将会自动发现注册的任务并触发执行。同时，也支持手动录入执行器地址；

6、弹性扩容缩容：一旦有新执行器机器上线或者下线，下次调度时将会重新分配任务；

12、任务失败告警；默认提供邮件方式失败告警，同时预留扩展接口，可方便的扩展短信、钉钉等告警方式；

16、任务进度监控：支持实时监控任务进度；

17、Rolling 实时日志：支持在线查看调度结果，并且支持以 Rolling 方式实时查看执行器输出的完整的执行日志；

26、邮件报警：任务失败时支持邮件报警，支持配置多邮件地址群发报警邮件；

27、推送 Maven 中央仓库: 将会把最新稳定版推送到 Maven 中央仓库, 方便用户接入和使用;

28、运行报表：支持实时查看运行数据，如任务数量、调度次数、执行器数量等；以及调度报表，如调度日期分布图，调度成功分布图等；

32、容器化：提供官方 Docker 镜像，并实时更新推送 Docker Hub，进一步实现产品开箱即用；

34、用户管理：支持在线管理系统用户，存在管理员、普通用户两种角色；

35、权限控制：执行器维度进行权限控制，管理员拥有全量权限，普通用户需要分配执行器权限后才允许相关操作；

架构设计

设计思想

将调度行为抽象形成“调度中心”公共平台，而平台自身并不承担业务逻辑，“调度中心”负责发起调度请求。

将任务抽象成分散的 JobHandler ，交由“执行器”统一管理，“执行器”负责接收调度请求并执行对应的 JobHandler中业务逻辑。

因此，“调度”和“任务”两部分可以相互解耦，提高系统整体稳定性和扩展性。

如果对分布式任务调度平台有一定了解的话，如果从调度系统的角度来看，可以分成两类：
中心化：调度中心和执行器分离，调度中心统一调度，通知某个执行器处理任务。
去中心化：调度中心和执行器一体化，自己调度自己执行处理任务。
如此可知 XXL-Job 属于中心化的任务调度平台。目前采用这种方案的还有：
链家的 kob
美团的 Crane（暂未开源）
去中心化的任务调度平台，目前有：
Elastic Job
唯品会的 Saturn
Quartz 基于数据库的集群方案
淘宝的 TBSchedule（暂停更新，只能使用阿里云 SchedulerX 服务）

系统组成

整个 XXL-JOB 系统，由调度中心和执行器两个角色组成，分别处于不同的进程中。

调度中心

负责管理调度信息，按照调度配置发出调度请求，自身不承担业务代码。

调度系统与任务解耦，提高了系统可用性和稳定性，同时调度系统性能不再受限于任务模块。

支持可视化、简单且动态的管理调度信息，包括任务新建，更新，删除， GLUE 开发和任务报警等，所有上述操作都会实时生效。

支持监控调度结果以及执行日志，支持执行器 Failover 。

执行器

负责接收调度请求并执行任务逻辑。任务模块专注于任务的执行等操作，开发和维护更加简单和高效。

接收“调度中心”的执行请求、终止请求和日志请求等。

💡

一般来说，XXL-JOB 执行器可以内嵌到应用服务里。例如说，一个提供 Restful API 的 Spring Boot 项目中，引入 xxl-job-core 依赖，同时也作为一个 XXL-JOB 执行器。本质上，每次 Restful API 是请求任务，而每次任务调度是定时任务。

架构图

注意，【】中填写调度中心和执行器；[] 中填写组件名。

【执行器】：[注册线程] 根据配置的【调度中心】的地址，自动注册到【调度中心】。

【调度中心】：达到任务触发条件，【调度中心】下发任务给【执行器】。

【执行器】：基于 [任务线程池] 执行任务，并把执行结果放入 [内存队列] 中、把 [执行日志] 写入 Log 日志文件中。

【执行器】：[回调线程] 消费 [内存队列] 中的调度结果，主动上报给【调度中心】。

当用户在【调度中心】查看 [Rolling 任务日志]，【调度中心】请求【执行器】，【执行器】读取 Log 日志文件并返回日志详情。

工作原理

任务执行器根据配置的调度中心的地址，自动注册到调度中心

达到任务触发条件，调度中心下发任务

执行器基于线程池执行任务，并把执行结果放入内存队列中、把执行日志写入日志文件中

执行器的回调线程消费内存队列中的执行结果，主动上报给调度中心

当用户在调度中心查看任务日志，调度中心请求任务执行器，任务执行器读取任务日志文件并返回日志详情

高可用

XXL-JOB 的高可用，需要考虑调度中心的高可用、以及执行器的高可用。

注意，虽然说 XXL-JOB 执行的是后台任务，即使挂掉，用户的感知度也比较低，但是考虑高可用是一种良好的习惯，在高性能之前请做好高可用。

调度中心的高可用

调度中心支持多节点部署，基于数据库行锁，保证触发器的名称和执行时间相同，则只且仅有一个调度中心节点去下发任务给执行器。

核心代码可见 XXL-JOB 的 JobScheduleHelper#start() 方法：

执行器的高可用

执行器支持多节点部署，通过调度中心选择其中的执行器，下发任务来执行。

当任务”路由策略”选择”故障转移（FAILOVER）”时，当调度中心每次发起调度请求时，会按照顺序对执行器发出心跳检测请求，第一个检测为存活状态的执行器将会被选定并发送调度请求。

路由策略

调度中心基于路由策略，选择一个执行器节点下发任务，从而让执行器执行任务。XXL-JOB 提供了如下路由策略保证任务调度高可用：

忙碌转移(BUSYOVER)策略：当调度中心每次发起调度请求时，会按照顺序对执行器发出空闲检测请求，第一个检测为空闲状态的执行器将会被选定并发送调度请求。具体代码，见 ExecutorRouteFailover 类。

故障转移(FAILOVER)策略：当调度中心每次发起调度请求时，会按照顺序对执行器发出心跳检测请求，第一个检测为存活状态的执行器将会被选定并发送调度请求。具体代码，见 ExecutorRouteFailover 类。

还有第一个(FIRST)、LAST(最后一个)、轮询(ROUND)、随机(RANDOM)、CONSISTENT_HASH(一致性 HASH)、最不经常使用(LEAST_FREQUENTLY_USED)、最近最久未使用(LEAST_RECENTLY_USED)、分片广播(SHARDING_BROADCAST)路由策略，胖友可以看看 com.xxl.job.admin.core.route.strategy/ 包下的代码。

阻塞处理策略

当调度过于密集时，执行器来不及处理时，则当执行器节点存在多个相同任务编号的任务未执行完成，则需要基于阻塞处理策略对任务进行取舍：

单机串行（默认）：调度请求进入单机执行器后，调度请求进入 FIFO 队列并以串行方式运行。

丢弃后续调度：调度请求进入单机执行器后，发现执行器存在运行的调度任务，本次请求将会被丢弃并标记为失败。

覆盖之前调度：调度请求进入单机执行器后，发现执行器存在运行的调度任务，将会终止运行中的调度任务并清空队列，然后运行本地调度任务。

具体可见 ExecutorBizImpl#run() 方法的代码。

故障转移 & 失败重试

一次完整任务流程包括”调度（调度中心） + 执行（执行器）”两个阶段。

“故障转移”发生在调度阶段，在执行器集群部署时，如果某一台执行器发生故障，该策略支持自动进行 Failover 切换到一台正常的执行器机器并且完成调度请求流程。

“失败重试”发生在”调度 + 执行”两个阶段，支持通过自定义任务失败重试次数，当任务失败时，将会按照预设的失败重试次数主动进行重试。

任务超时时间

支持设置任务超时时间，任务运行超时的情况下，将会主动中断任务。

需要注意的是，任务超时中断时与任务终止机制类似，也是通过 “interrupt” 中断任务，因此业务代码需要将 InterruptedException 外抛，否则功能不可用。

搭建调度中心

clone源码

XXL-JOB 暂未提供直接直接启动的 jar 包，所以需要自己编译源码。

clone地址：‣，完成后，耐心等待下载完依赖，整体项目结构如下图：

xxl-job-core 模块：XXL-JOB 核心。后续我们在编写执行器时，会引入该模块。

xxl-job-admin 模块：调度中心。

xxl-job-executor-samples 模块：提供了在 Spring、Spring Boot、JFinal、Nutz 等框架下的使用示例。

这里，我们需要编译的主要是 xxl-job-admin 模块，即调度中心。

初始化XXL-JOB 表结构

在 doc/db/tables_xxl_job.sql 地址，是 XXL-JOB 表结构的初始化脚本。我们需要在数据库中执行该脚本，完成初始化 XXL-JOB 表结构。如下图所示：

xxl_job_lock：任务调度锁表；

xxl_job_group：执行器信息表，维护任务执行器信息；

xxl_job_info：调度扩展信息表：用于保存 XXL-JOB 调度任务的扩展信息，如任务分组、任务名、机器地址、执行器、执行入参和报警邮件等等；

xxl_job_log：调度日志表：用于保存 XXL-JOB 任务调度的历史信息，如调度结果、执行结果、调度入参、调度机器和执行器等等；

xxl_job_log_report：调度日志报表：用户存储 XXL-JOB 任务调度日志的报表，调度中心报表功能页面会用到；

xxl_job_logglue：任务GLUE日志：用于保存 GLUE 更新历史，用于支持 GLUE 的版本回溯功能；

xxl_job_registry：执行器注册表，维护在线的执行器和调度中心机器地址信息；

xxl_job_user：系统用户表；

修改配置文件

打开 xxl-job-admin 模块，修改 src/main/resources/application.properties 配置文件。如下：

可以看到 XXL-JOB 使用了 Spring Boot ，说下必须要改的项：

server.port ：XXL-JOB 调度中心的服务器地址。可以根据自己的需要，修改该端口。

spring.datasource ：XXL-JOB 调度中心的数据源地址，必须修改成自己准备提供给 XXL-JOB 的数据库地址。

spring.mail ：报警邮箱，生产环境下必须配置，不然定时任务执行报错都不知道，简直要命。一般建议有时间的胖友，修改下 XXL-JOB 的源码，把钉钉告警接入。

xxl.job.accessToken ：调度中心通讯令牌，建议填写。虽然说，内网一般很安全，但是以防万一，并且又没啥成本，直接给整上。

注意：在配置spring.datasource.type=org.apache.tomcat.jdbc.pool.DataSource时需要引入以下Maven依赖

修改日志配置文件

打开 xxl-job-admin 模块，修改 src/main/resources/logback.xml 配置文件。如下：

默认情况下，日志输出的地址是 /data/applogs/xxl-job/xxl-job-admin.log 。可以根据自己的需要，进行调整。

IDEA启动调度中心

在开始编译源码之前，我们先直接使用 XxlJobAdminApplication 类，运行启动调度中心。

当看到如下日志，代表启动成功：

启动成功后，浏览器输入 http://127.0.0.1:8088/xxl-job-admin 地址，并使用默认 "admin/123456" 进行登录。如果登录成功，说明我们已经配置正确啦。

编译源码

看到如下日志后，说明编译成功：

打包完成后，在 xxl-job-admin/target/xxl-job-admin-2.4.2-SNAPSHOT.jar 地址下，就是我们要启动的 XXL-JOB 调度中心的 jar 包。

命令行启动调度中心

前提：先关闭 IDEA 中启动的XxlJobAdminApplication类。

当看到如下日志，代表启动成功：

启动成功后，浏览器输入 http://127.0.0.1:8088/xxl-job-admin 地址，并使用默认 "admin/123456" 进行登录。如果登录成功，说明我们已经配置正确啦。

记得修改用户密码。

搭建执行器

本地搭建

引入Maven依赖

配置文件

XxlJobConfiguration

在 #xxlJobExecutor() 方法，创建了 Spring 容器下的 XXL-JOB 执行器 Bean 对象。要注意，方法上添加了的 @Bean 注解，配置了启动和销毁方法。

DemoJob

继承 XXL-JOB IJobHandler 抽象类，通过实现 #execute(String param) 方法，从而实现定时任务的逻辑。

在方法上，添加 @JobHandler 注解，设置 JobHandler 的名字。后续，我们在调度中心的控制台中，新增任务时，需要使用到这个名字。

#execute(String param) 方法的返回结果，为 ReturnT 类型。当返回值符合 “ReturnT.code == ReturnT.SUCCESS_CODE” 时表示任务执行成功，否则表示任务执行失败，而且可以通过 “ReturnT.msg” 回调错误信息给调度中心；从而，在任务逻辑中可以方便的控制任务执行结果。

#execute(String param) 方法的方法参数，为调度中心的控制台中，新增任务时，配置的“任务参数”。一般情况下，不会使用到。

测试

启动 Application.java 类，可以看到如下日志

新增执行器

浏览器打开 http://127.0.0.1:8088/xxl-job-admin/jobgroup 地址，即「执行器管理」菜单。如下图：

点击「新增执行器」按钮，弹出「新增执行器」界面。如下图：

填写完 xxl-job-executor执行器的信息，点击「保存」按钮，进行保存。耐心等待一会，执行器会自动注册上来。

执行器列表中显示在线的执行器列表，可通过 "OnLine 机器" 查看对应执行器的集群机器。

相同执行器，有且仅需配置一次即可。

新建任务

浏览器打开 http://127.0.0.1:8088/xxl-job-admin/jobinfo 地址，即「任务管理」菜单。如下图：

点击最右边的「新增」按钮，弹出「新增」界面。如下图：

填写完 "demoJob" 任务的信息，点击「保存」按钮，进行保存。如下图所示，默认状态为STOP

点击 "demoJob" 任务的「操作」按钮，选择「启动」，确认后，该 "demoJob" 任务的状态就变成了 RUNNING 。如下图：

此时，打开执行器的 IDE 界面，可以看到 DemoJob 已经在每分钟执行一次了。日志如下：

并且，我们在调度中心的界面上，点击 "demoJob" 任务的「操作」按钮，选择「查询日志」，可以看到相应的调度日志。如下图：

总结

方案对比

对以上提到的集中定时任务的框架做个对比：

特性	quartz	elastic-job-lite	xxl-job	LTS
依赖	MySQL、jdk	jdk、zookeeper	mysql、jdk	jdk、zookeeper、maven
高可用	多节点部署，通过竞争数据库锁来保证只有一个节点执行任务	通过zookeeper的注册与发现，可以动态的添加服务器	基于竞争数据库锁保证只有一个节点执行任务，支持水平扩容。可以手动增加定时任务，启动和暂停任务，有监控	集群部署,可以动态的添加服务器。可以手动增加定时任务，启动和暂停任务。有监控
任务分片	×	√	√	√
管理界面	×	√	√	√
难易程度	简单	简单	简单	略复杂
高级功能	-	弹性扩容，多种作业模式，失效转移，运行状态收集，多线程处理数据，幂等性，容错处理，spring命名空间支持	弹性扩容，分片广播，故障转移，Rolling实时日志，GLUE（支持在线编辑代码，免发布）,任务进度监控，任务依赖，数据加密，邮件报警，运行报表，国际化	支持spring，spring boot，业务日志记录器，SPI扩展支持，故障转移，节点监控，多样化任务执行结果支持，FailStore容错，动态扩容。
版本更新	半年没更新	2年没更新	最近有更新	1年没更新

目前的状况，如果真的不知道怎么选择，可以先尝试下 XXL-JOB 。

中心化 VS 去中心化

下面，让我们一起来简单聊聊分布式调度中间件的实现方式的分类。一个分布式的调度中间件，会存在两种角色：

调度器：负责调度任务，下发给执行器。

执行器：负责接收任务，执行具体任务。

那么，如果从调度系统的角度来看，可以分成两类：

中心化：调度中心和执行器分离，调度中心统一调度，通知某个执行器处理任务。

去中心化：调度中心和执行器一体化，自己调度自己执行处理任务。

如此可知 XXL-Job 属于中心化的任务调度平台。目前采用这种方案的还有：

链家的 kob

美团的 Crane（暂未开源）

去中心化的任务调度平台，目前有：

Elastic Job
唯品会的 Saturn
Quartz 基于数据库的集群方案
淘宝的 TBSchedule（暂停更新，只能使用阿里云 SchedulerX 服务）

任务竞争 VS 任务预分配

那么，如果从任务分配的角度来看，可以分成两类：

任务竞争：调度器会通过竞争任务，下发任务给执行器。

任务预分配：调度器预先分配任务给不同的执行器，无需进行竞争。

如此可知 XXL-Job 属于任务竞争的任务调度平台。目前采用这种方案的还有：

链家的 kob

美团的 Crane（暂未开源）

Quartz 基于数据库的集群方案

任务预分配的任务调度平台，目前有：

Elastic Job

唯品会的 Saturn

淘宝的 TBSchedule（暂停更新，只能使用阿里云 SchedulerX 服务）

一般来说，基于任务预分配的任务调度平台，都会选择使用 Zookeeper 来协调分配任务到不同的节点上。同时，任务调度平台必须是去中心化的方案，每个节点即是调度器又是执行器。这样，任务在预分配在每个节点之后，后续就自己调度给自己执行。

相比较而言，随着节点越来越多，基于任务竞争的方案会因为任务竞争，导致存在性能下滑的问题。而基于任务预分配的方案，则不会存在这个问题。并且，基于任务预分配的方案，性能会优于基于任务竞争的方案。

这里在推荐一篇 Elastic Job 开发者张亮的文章《详解当当网的分布式作业框架 elastic-job》，灰常给力！

Quartz 是个优秀的调度内核

绝大多数情况下，我们不会直接使用 Quartz 作为我们的调度中间件的选择。但是，基本所有的分布式调度中间件，都将 Quartz 作为调度内核，因为 Quartz 在单纯任务调度本身提供了很强的功能。

不过呢，随着一个分布式调度中间件的逐步完善，又会逐步考虑抛弃 Quartz 作为调度内核，转而自研。例如说 XXL-JOB 在 2.1.0 RELEASE 的版本中，就已经更换成自研的调度模块。其替换的理由如下：

XXL-JOB 最终选择自研调度组件（早期调度组件基于 Quartz）；
一方面，是为了精简系统降低冗余依赖。
另一方面，是为了提供系统的可控度与稳定性。

在 Elastic-Job 3.X 的开发计划中，也有一项计划，就是自研调度组件，替换掉 Quartz 。

参考

Azkaban、Xxl-Job 与 Airflow 对比分析

概述