如果XXL-JOB执行器在执行某任务中被重启了，重启后该任务能够被自动弥补调度吗
开心一刻
上午，走路不小心踩了钉子，去打了破伤风
下午，又特么踩到了钉子，我问医生
我：还需要打针吗
医生：你有那钱还是看看眼睛吧
基础回顾
项目基于
xxl-job 2.1.0
实现的分布式调度，所以我还是基于此来模拟实现我们的项目；关于
XXL-JOB
，本文不做额外介绍，大家可以去看官网
或者我之前的博客
分布式任务调度平台 → XXL-JOB 初探
分布式任务调度平台 → XXL-JOB 实战
当 xxl-job 遇上 docker → 它晕了，我也乱了！
当 xxl-job 遇上 docker → 它晕了，但我不能乱！
XXL-JOB
分两块：
调度中心
和
执行器
其中
调度中心
就是
xxl-job-admin
，已经是一个完善的模块，直接部署使用即可；而
执行器
，也就是任务执行器，需要跟我们的业务代码绑定，完成我们的业务逻辑，我们一个一个来部署
调度中心
xxl-job-admin 有自己的表，官方提供了初始化 SQL：
tables_xxl-job.sqlCREATE database if NOT EXISTS `xxl_job` default character set utf8 collate utf8_general_ci; use `xxl_job`; CREATE TABLE `xxl_job_info` ( `id` int(11) NOT NULL AUTO_INCREMENT, `job_group` int(11) NOT NULL COMMENT '执行器主键ID', `job_cron` varchar(128) NOT NULL COMMENT '任务执行CRON', `job_desc` varchar(255) NOT NULL, `add_time` datetime DEFAULT NULL, `update_time` datetime DEFAULT NULL, `author` varchar(64) DEFAULT NULL COMMENT '作者', `alarm_email` varchar(255) DEFAULT NULL COMMENT '报警邮件', `executor_route_strategy` varchar(50) DEFAULT NULL COMMENT '执行器路由策略', `executor_handler` varchar(255) DEFAULT NULL COMMENT '执行器任务handler', `executor_param` varchar(512) DEFAULT NULL COMMENT '执行器任务参数', `executor_block_strategy` varchar(50) DEFAULT NULL COMMENT '阻塞处理策略', `executor_timeout` int(11) NOT NULL DEFAULT '0' COMMENT '任务执行超时时间，单位秒', `executor_fail_retry_count` int(11) NOT NULL DEFAULT '0' COMMENT '失败重试次数', `glue_type` varchar(50) NOT NULL COMMENT 'GLUE类型', `glue_source` mediumtext COMMENT 'GLUE源代码', `glue_remark` varchar(128) DEFAULT NULL COMMENT 'GLUE备注', `glue_updatetime` datetime DEFAULT NULL COMMENT 'GLUE更新时间', `child_jobid` varchar(255) DEFAULT NULL COMMENT '子任务ID，多个逗号分隔', `trigger_status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '调度状态：0-停止，1-运行', `trigger_last_time` bigint(13) NOT NULL DEFAULT '0' COMMENT '上次调度时间', `trigger_next_time` bigint(13) NOT NULL DEFAULT '0' COMMENT '下次调度时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `xxl_job_log` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `job_group` int(11) NOT NULL COMMENT '执行器主键ID', `job_id` int(11) NOT NULL COMMENT '任务，主键ID', `executor_address` varchar(255) DEFAULT NULL COMMENT '执行器地址，本次执行的地址', `executor_handler` varchar(255) DEFAULT NULL COMMENT '执行器任务handler', `executor_param` varchar(512) DEFAULT NULL COMMENT '执行器任务参数', `executor_sharding_param` varchar(20) DEFAULT NULL COMMENT '执行器任务分片参数，格式如 1/2', `executor_fail_retry_count` int(11) NOT NULL DEFAULT '0' COMMENT '失败重试次数', `trigger_time` datetime DEFAULT NULL COMMENT '调度-时间', `trigger_code` int(11) NOT NULL COMMENT '调度-结果', `trigger_msg` text COMMENT '调度-日志', `handle_time` datetime DEFAULT NULL COMMENT '执行-时间', `handle_code` int(11) NOT NULL COMMENT '执行-状态', `handle_msg` text COMMENT '执行-日志', `alarm_status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '告警状态：0-默认、1-无需告警、2-告警成功、3-告警失败', PRIMARY KEY (`id`), KEY `I_trigger_time` (`trigger_time`), KEY `I_handle_code` (`handle_code`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `xxl_job_logglue` ( `id` int(11) NOT NULL AUTO_INCREMENT, `job_id` int(11) NOT NULL COMMENT '任务，主键ID', `glue_type` varchar(50) DEFAULT NULL COMMENT 'GLUE类型', `glue_source` mediumtext COMMENT 'GLUE源代码', `glue_remark` varchar(128) NOT NULL COMMENT 'GLUE备注', `add_time` timestamp NULL DEFAULT NULL, `update_time` timestamp NULL DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `xxl_job_registry` ( `id` int(11) NOT NULL AUTO_INCREMENT, `registry_group` varchar(255) NOT NULL, `registry_key` varchar(255) NOT NULL, `registry_value` varchar(255) NOT NULL, `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `i_g_k_v` (`registry_group`,`registry_key`,`registry_value`), KEY `i_u` (`update_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `xxl_job_group` ( `id` int(11) NOT NULL AUTO_INCREMENT, `app_name` varchar(64) NOT NULL COMMENT '执行器AppName', `title` varchar(12) NOT NULL COMMENT '执行器名称', `order` tinyint(4) NOT NULL DEFAULT '0' COMMENT '排序', `address_type` tinyint(4) NOT NULL DEFAULT '0' COMMENT '执行器地址类型：0=自动注册、1=手动录入', `address_list` varchar(512) DEFAULT NULL COMMENT '执行器地址列表，多地址逗号分隔', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `xxl_job_user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '账号', `password` varchar(50) NOT NULL COMMENT '密码', `role` tinyint(4) NOT NULL COMMENT '角色：0-普通用户、1-管理员', `permission` varchar(255) DEFAULT NULL COMMENT '权限：执行器ID列表，多个逗号分割', PRIMARY KEY (`id`), UNIQUE KEY `i_username` (`username`) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `xxl_job_lock` ( `lock_name` varchar(50) NOT NULL COMMENT '锁名称', PRIMARY KEY (`lock_name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; INSERT INTO `xxl_job_group`(`id`, `app_name`, `title`, `order`, `address_type`, `address_list`) VALUES (1, 'xxl-job-executor-sample', '示例执行器', 1, 0, NULL); INSERT INTO `xxl_job_info`(`id`, `job_group`, `job_cron`, `job_desc`, `add_time`, `update_time`, `author`, `alarm_email`, `executor_route_strategy`, `executor_handler`, `executor_param`, `executor_block_strategy`, `executor_timeout`, `executor_fail_retry_count`, `glue_type`, `glue_source`, `glue_remark`, `glue_updatetime`, `child_jobid`) VALUES (1, 1, '0 0 0 * * ? *', '测试任务1', '2018-11-03 22:21:31', '2018-11-03 22:21:31', 'XXL', '', 'FIRST', 'demoJobHandler', '', 'SERIAL_EXECUTION', 0, 0, 'BEAN', '', 'GLUE代码初始化', '2018-11-03 22:21:31', ''); INSERT INTO `xxl_job_user`(`id`, `username`, `password`, `role`, `permission`) VALUES (1, 'admin', 'e10adc3949ba59abbe56e057f20f883e', 1, NULL); INSERT INTO `xxl_job_lock` ( `lock_name`) VALUES ( 'schedule_lock'); commit;
我们先通过此 SQL 把库、表创建好
官方提供了 Docker 镜像，我们直接用 Docker 来部署
docker run -d -e PARAMS="--spring.datasource.url=jdbc:mysql://192.168.2.118:3312/xxl_job?Unicode=true&characterEncoding=UTF-8&autoReconnect=true&serverTimezone=Asia/Shanghai
--spring.datasource.username=root
--spring.datasource.password=123456
--xxl.job.accessToken=qsl.token"
-p 8080:8080
--name xxl-job-admin --restart=always xuxueli/xxl-job-admin:2.1.0
不出意外的话，xxl-job-admin 就部署成功了
执行器
为了方便演示，直接在本地 IDEA 中启动；我们基于
Spring Boot
搭建，pom.xml 很简单<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.qsl</groupId> <artifactId>spring-boot-xxl-job-executor</artifactId> <version>1.0-SNAPSHOT</version> <properties> <maven.compiler.source>8</maven.compiler.source> <maven.compiler.target>8</maven.compiler.target> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <exclusions> <exclusion> <artifactId>spring-boot-starter-logging</artifactId> <groupId>org.springframework.boot</groupId> </exclusion> </exclusions> </dependency> <dependency> <groupId>com.xuxueli</groupId> <artifactId>xxl-job-core</artifactId> <version>2.1.0</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> </dependency> </dependencies> </project>
配置文件：application.yml
xxl: job: executor: appName: qsl-job-executor admin-addresses: http://192.168.2.118:8080/xxl-job-admin access-token: qsl.token
xxl-job spring executor：XxlJobSpringExecutor
/** * @author 青石路 */ @Configuration public class XxlJobConfig { private final Logger logger = LoggerFactory.getLogger(XxlJobConfig.class); @Bean(initMethod = "start",destroyMethod = "destroy") public XxlJobSpringExecutor xxlJobExecutor(XxlJobProperties xxlJob) { logger.info(">>>>>>>>>>> xxl-job config init."); XxlJobSpringExecutor xxlJobSpringExecutor = new XxlJobSpringExecutor(); xxlJobSpringExecutor.setAdminAddresses(xxlJob.getAdminAddresses()); xxlJobSpringExecutor.setAppName(xxlJob.getAppName()); xxlJobSpringExecutor.setIp(xxlJob.getIp()); xxlJobSpringExecutor.setPort(xxlJob.getPort()); xxlJobSpringExecutor.setAccessToken(xxlJob.getAccessToken()); xxlJobSpringExecutor.setLogPath(xxlJob.getLogPath()); xxlJobSpringExecutor.setLogRetentionDays(xxlJob.getLogRetentionDays()); return xxlJobSpringExecutor; } }
最后剩一个 JobHandler：QslJobHandler
/** * @author 青石路 */ @Component @JobHandler("qslJobHandler") public class QslJobHandler extends IJobHandler { private static final Logger LOG = LoggerFactory.getLogger(QslJobHandler.class); @Override public ReturnT<String> execute(String param) throws Exception { LOG.info("param = {}", param); // TODO 业务处理 return ReturnT.SUCCESS; } }
代码完整地址：
spring-boot-xxl-job-executor我们启动执行器，不出意外的话，执行器会启动成功
调度中心
和
执行器
都启动成功后，还需要在调度中心注册执行器和添加任务，页面操作即可
注册执行器
这里的
AppName
不能随意填写，需要与 application.yml 中xxl: job: executor: appName: qsl-job-executor
配置的值保持一致，即填写：
qsl-job-executor名称
和
排序
可以随意填，推荐填的有业务含义，特别是名称，最好见名知意注册方式
采用
手动录入
的方式，因为调度中心是采用 Docker 部署的，而执行器是通过本地 IDEA 启动的，自动注册会导致调度中心与执行器之间网络不通机器地址
填本地 IDEA 所在机器的 IP，端口是
9999
，而非
8080
，所以完整地址是：
192.168.2.13:9999
；多个地址间用英文逗号隔开即可最后点击
保存
即可
添加任务
如上的任务参数，我都是按我们项目的生产参数来配置的，每个参数的详细说明，大家可以去看 XXL-JOB 官方的
任务详解
至此就算全部配置完成，我们执行下任务试试
执行结果如下
IDEA 控制台输出如下
一切似乎都是那么正常
线上问题
我们的生产环境是基于
k8s
部署的，当执行器的内存使用率占用分配内存的 90% 时，会触发 k8s 的重启机制；因为不好模拟生产环境，所以我们需要调整下
QslJobHandler
来模拟线上问题
/**
* @author 青石路
*/
@Component
@JobHandler("qslJobHandler")
public class QslJobHandler extends IJobHandler {
private static final Logger LOG = LoggerFactory.getLogger(QslJobHandler.class);
@Override
public ReturnT<String> execute(String param) throws Exception {
LOG.info("param = {}", param);
LOG.info("QslJobHandler 业务处理开始");
// TODO 业务处理
TimeUnit.SECONDS.sleep(30);
LOG.info("QslJobHandler 业务处理完成");
return ReturnT.SUCCESS;
}
}
任务执行的过程中（即业务处理中，还未处理完成），我们重启下执行器
模拟的是任务执行的时候，执行器
OOM
导致内存使用率超过 90%，触发 k8s 的重启机制，导致执行器重启；那么有什么问题呢，我们来看下调度日志
这个数据，你们都能看懂吧，因为任务在执行过程中，执行器重启导致没有给调度中心进行响应，所以调度中心一直在苦苦等待执行器的回信，殊不知执行器已喝孟婆汤完成了转生
那这对我们的业务有什么影响吗，肯定有影响，因为我们配置的 cron（
0 50 5 * * ?
）是每天只执行一次，这次没执行成功，今天就不会被调度执行了，然后我们就喜提一个
生产事故
从根因上来讲，罪魁祸首是 OOM，但一轮排查下来，发现这个吊毛隐藏的挺深，加上又是偶发一次，一时半会还真查不出来 OOM 的原因；所以我们得想办法对这种偶发问题进行弥补，如果是上班时间，我们可以根据重启告警进行人工弥补调度，但如果不是上班时间呢，甚至是半夜呢，所以我们应该通过程序去自动弥补调度，人工弥补调度只是最后的兜底；这个时候如果调度中心能够监测出哪些任务需要弥补调度并自动进行弥补，那就美滋滋了！
期望自动弥补
调度中心如何监测呢，是不是可以通过
任务超时时间
来实现？如果指定时间内，执行器没有返回任务执行结果，调度中心就认为任务执行失败了，重新发送一次调度请求，然后结合
失败重试次数
来避免无限重试；而 XXL-JOB 正好提供了这两个配置，其说明如下
针对
失败重试
，官方还有这样一段说明
这两段说明结合起来看，不知道你们有没有什么想法，我心中倒是涌起了一股不祥的预感
我前面说的美好预想都是基于
任务超时时间
是在
调度中心
实现的，或者说
调度中心
和
执行器
都有实现，只有这样，调度中心才能实现监测；但
主动中断任务
、
调度 + 执行
这些字眼，让我觉得
调度中心
不会实现
任务超时时间
，
执行器
才会实现它
至于 XXL-JOB 具体是如何实现的，我们一测便知
然后重复之前执行器的重启过程（调度请求到了执行器后，立马重启执行器），我们再来看看执行结果
结果显示任务并未终止，调度中心也没有按我们预期的那样就行重试，我的不祥预感成真了！
任务超时时间
只在
执行器
端做了实现，精确的控制任务执行时长，并及时的进行超时中断调度重试次数
在 调度 与 执行 阶段都可以生效，前提是触发了重试机制，重试的方式是再次触发调度
当我们去手动
终止任务
，调度中心过几秒后会进行重试
点击调度备注的查看，可以看到任务触发类型是：失败重试触发
所以结论是
XXL-JOB 有任务执行超时后的重试功能，但前提是执行器不能重启
这也得出了标题的答案：
执行中的任务在执行器重启后不会自动弥补调度
总结
上述的结论都是基于 XXL-JOB 2.1.0，不一定适配其他版本
XXL-JOB 有任务执行超时后的重试功能，但前提是执行器不能重启；执行中的任务在执行器重启后不会自动弥补调度
也许 XXL-JOB 在 2.1.0 之后的某个版本已经满足标题的需求，或者在未来的版本中会支持，但不会是 2.1.0
针对标题中的问题，只能先加重启监控进行人工弥补，同时去找 OOM 的原因并进行修复
关于
任务超时控制
，官方特意强调了一些注意点
另外，也推荐大家去查看下
4.9 终止运行中的任务
