如果XXL-JOB执行器在执行某任务中被重启了，重启后该任务能够被自动弥补调度吗

博客园 - 青石路

如果写Redis序列化与读Redis序列化不一致，你觉得会发生什么记一次多JDK版本问题的排查，一坑套一坑，差点没爬上来 Claude Code安装，接入阿里云百炼模型，蹭蹭免费额度异源数据同步 → 记一次 DataX 已同步数据量优化明明连接的是Redis的DB0，为什么能查到DB3的数据？ TINYINT(1) 类型的字段，明明数据存的是 2，为什么查出来是 true 用了MySQL的INSERT ON DUPLICATE KEY UPDATE，怎么还报唯一索引冲突错误那些年不该放到事务中的操作，你实现过哪些关于布尔类型的变量不要加 is 前缀，被网友们吐槽了，特来完善下都说了布尔类型的变量不要加 is 前缀，非要加，这不是坑我了嘛安全漏洞修复导致SpringBoot2.7与Springfox不兼容，问题排查与处理记一次SQL隐式转换导致精度丢失问题的排查 → 不规范就踩坑经由同个文件多次压缩的文件MD5都不一样问题排查，感慨AI的强大！记一次cannot access its superinterface问题的的排查 → 强如Spring也一样写Bug SpringBoot支持Kafka多源配置的同时还要支持启停配置化，是真的会玩 Spring Boot读取外部配置文件失败，原因绝对出乎你意料不依赖 Spring，你会如何自实现 RabbitMQ 消息的消费（一）异源数据同步 → DataX 同步启动后如何手动终止？异源数据同步 → 如何获取 DataX 已同步数据量？记一次 RabbitMQ 消费者莫名消失问题的排查不升级 POI 版本，如何生成符合新版标准的Excel 2007文件以MySQL为例，来看看maven-shade-plugin如何解决多版本驱动共存的问题？ maven 插件之 maven-shade-plugin，解决同包同名 class 共存问题的神器

青石路 · 2024-12-23 · via 博客园 - 青石路

开心一刻

上午，走路不小心踩了钉子，去打了破伤风
下午，又特么踩到了钉子，我问医生
我：还需要打针吗
医生：你有那钱还是看看眼睛吧

宋小宝_红帽大笑

基础回顾

项目基于 xxl-job 2.1.0 实现的分布式调度，所以我还是基于此来模拟实现我们的项目；关于 XXL-JOB，本文不做额外介绍，大家可以去看官网

https://www.xuxueli.com/xxl-job/

或者我之前的博客

分布式任务调度平台 → XXL-JOB 初探
 分布式任务调度平台 → XXL-JOB 实战
 当 xxl-job 遇上 docker → 它晕了，我也乱了！
当 xxl-job 遇上 docker → 它晕了，但我不能乱！

XXL-JOB 分两块：调度中心 和 执行器

xxl-job架构图

其中 调度中心 就是 xxl-job-admin，已经是一个完善的模块，直接部署使用即可；而 执行器 ，也就是任务执行器，需要跟我们的业务代码绑定，完成我们的业务逻辑，我们一个一个来部署

调度中心

xxl-job-admin 有自己的表，官方提供了初始化 SQL：tables_xxl-job.sql

CREATE 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 把库、表创建好

admin库表

官方提供了 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 就部署成功了

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

我们启动执行器，不出意外的话，执行器会启动成功

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;
    }
}

任务执行的过程中（即业务处理中，还未处理完成），我们重启下执行器

job还未执行完重启执行器

模拟的是任务执行的时候，执行器 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 终止运行中的任务
示例代码：spring-boot-xxl-job-executor

此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。原文来自 — 版权归原作者所有。

推荐订阅源

博客园 - 青石路

开心一刻

基础回顾

线上问题

期望自动弥补

总结