1 、前言

本篇文章主要记录项目中遇到的 xxl-job 的实战，希望能通过这篇文章告诉读者们什么是 xxl-job 以及怎么使用 xxl-job 并分享一个实战案例。

那么下面先说明什么是 xxl-job 以及为什么要使用它。

xxl-job 是什么？

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

设计思想 是将调度行为抽象形成 调度中心 平台，平台本身不承担业务逻辑，而是负责发起 调度请求 后，由 执行器 接收调度请求并执行 任务 ，这里的 任务 抽象为 分散的 JobHandler 。通过这种方式即可实现 调度 与 任务 相互解耦，从而提高系统整体的稳定性和拓展性。

为了更好理解，这里放一张官网的架构图：

任务调度是什么？

在开发项目时大家是否也遇到过类似的场景问题：

• 系统需要定时在每天0点进行数据备份。
• 系统需要在活动开始前几小时预热执行一些前置业务。
• 系统需要定时对 MQ 消息表的发送装填，对发送失败的 MQ 消息进行补偿重新发送。

这些场景问题都可以通过 任务调度 来解决，任务调度指的是系统在约定的指定时间自动去执行指定的任务的过程。

单体系统 中有许多实现 任务调度 的方式，如多线程方式、Timer 类、Spring Tasks 等等。这里比较常用的是 Spring Tasks（通过 @EnableScheduling + @Scheduled 的注解可以自定义定时任务，有兴趣的可以去了解一下）

为什么需要分布式任务调度平台？

分布式下，每个服务都可以搭建为集群，这样的好处是可以将任务切片分给每一个服务从而实现并行执行，提高任务调度的处理效率。那么为什么 分布式系统 不能使用 单体系统 的任务调度实现方式呢。

在集群服务下，如果还是使用每台机器按照单体系统的任务调度实现方式实现的话，会出现下面这四个问题：

1. 怎么做到对任务的控制（如何避免任务重复执行）。
2. 如果某台机器宕机了，会不会存在任务丢失。
3. 如果要增加服务实例，怎么做到弹性扩容。
4. 如何做到对任务调度的执行情况统一监测。

通过上面的问题可以了解到分布式系统下需要一个满足高可用、容错管理、负载均衡等功能的任务调度平台来实现任务调度。分布式系统下，也有许多可以实现任务调度的第三方的分布式任务调度系统，如 xxl-job、Quartz、elastic-job 等等常用的分布式任务调度系统。

本篇文章将介绍 xxl-job 分布式任务调度系统。

2 、如何使用 xxl-job

作为开源软件的 xxl-job，可以在 github [1] 或 gitee [2] 上查看和下载 xxl-job 的源码。

下面将介绍我使用 xxl-job 的流程（如果有操作不当的，可以查看官方的中文文档 分布式任务调度平台XXL-JOB (xuxueli.com) [3]）

dokcer 下安装 xxl-job

1、docker 下拉取 xxl-job 的镜像（这里使用 2.3.1 版本）

docker pull xuxueli/xxl-job-admin:2.3.1

2、创建映射容器的文件目录

mkdir -p -m 777 /mydata/xxl-job/data/applogs

3、在 /mydata/xxl-job 的目录下创建 application.properties 文件

由于 application.properties 的代码过长，这里就不展示了，需要的可以去 gitee 上获取，具体路径如图：

这里需要注意数据库位置的填写：

如果还需要更改端口的可以更改这里：

这里还需要注意告警邮箱和访问口令（后续Spring Boot配置用到）：

4、将 tables_xxl-job.sql 文件导入上面步骤3指定的数据库（自己填写的那个数据库）

同样由于文件代码过长，这里展示 gitee 上获取的路径图：

5、执行 docker 命令

注意这里的 -p 8088:8088 是因为我更改了前面 application.porperties 文件的端口号为 8088，所以这里我执行的 docker 命令为 -p 8088:8088，如果没有更改的这里一定要改为 -p 8080:8080。

docker run  -p 8088:8088 \
-d --name=xxl-job-admin --restart=always \
-v /mydata/xxl-job/application.properties:/application.properties \
-v /mydata/xxl-job/data/applogs:/data/applogs \
-e PARAMS='--spring.config.location=/application.properties' xuxueli/xxl-job-admin:2.3.1

执行后通过 docker ps 查看是否成功运行，如果失败可以通过 docker logs xxl-job-admin 查看具体错误日志。

6、通过 http://192.168.101.25:8088/xxl-job-admin/ 访问（这里ip和端口是自己的）

账号：admin 密码：123456

到这里就算是完成了 xxl-job 在 docker 的搭建。

3 、Spring Boot 项目集成 xxl-job

xxl-job 由 调度中心 和 执行器 组成，上面已经完成了在 docker 上部署调度中心了，接下来介绍怎么配置部署执行器项目 。

• 在 Spring Boot 项目中导入 maven 依赖

<dependency>
    <groupId>com.xuxueli</groupId>
    <artifactId>xxl-job-core</artifactId>
    <version>2.3.1</version>
</dependency>

• 在 Spring Boot 项目中配置 application.yml 文件

xxl:
  job:
    admin:
      addresses: http://192.168.101.25:8088/xxl-job-admin
    executor:
      appname: media-process-service
      address:
      ip:
      port: 9999
      logpath: /data/applogs/xxl-job/jobhandler
      logretentiondays: 30
    accessToken: default_token

• 这里的 xxl.job.admin.addresses 用于指定调度中心的地址。
• 这里的 xxl.job.accessToken 用于指定访问口令（也就是前面搭建 xxl-job 中步骤3指定的）。
• 这里的 xxl.job.executor.appname 用于指定执行器的名称（需要与后续配置执行器的名称一致）。
• 这里的 xxl.job.executor.port 用于指定执行器的端口（执行器实际上是一个内嵌的 Server，默认端口为9999，配置多个同一服务实例时需要指定不同的执行器端口，否则会端口冲突）。
• 其他属性只需要照着配置即可（想要了解属性的具体含义可以查看中文文档中的2.4配置部署执行器项目章节）。

1、编写配置类

/**
 * XXL-JOB配置类
 *
 * @author 单程车票
 */
@Slf4j
@Configuration
public class XxlJobConfig {
    @Value("${xxl.job.admin.addresses}")
    private String adminAddresses;

    @Value("${xxl.job.accessToken}")
    private String accessToken;

    @Value("${xxl.job.executor.appname}")
    private String appname;

    @Value("${xxl.job.executor.address}")
    private String address;

    @Value("${xxl.job.executor.ip}")
    private String ip;

    @Value("${xxl.job.executor.port}")
    private int port;

    @Value("${xxl.job.executor.logpath}")
    private String logPath;

    @Value("${xxl.job.executor.logretentiondays}")
    private int logRetentionDays;

    @Bean
    public XxlJobSpringExecutor xxlJobExecutor() {
        log.info(">>>>>>>>>>> xxl-job config init.");
        XxlJobSpringExecutor xxlJobSpringExecutor = new XxlJobSpringExecutor();
        xxlJobSpringExecutor.setAdminAddresses(adminAddresses);
        xxlJobSpringExecutor.setAppname(appname);
        xxlJobSpringExecutor.setAddress(address);
        xxlJobSpringExecutor.setIp(ip);
        xxlJobSpringExecutor.setPort(port);
        xxlJobSpringExecutor.setAccessToken(accessToken);
        xxlJobSpringExecutor.setLogPath(logPath);
        xxlJobSpringExecutor.setLogRetentionDays(logRetentionDays);
        return xxlJobSpringExecutor;
    }
}

2、调度中心中新增执行器

执行器的配置属性：

• AppName: 每个执行器集群的唯一标示 AppName，执行器会周期性以 AppName 为对象进行自动注册。可通过该配置自动发现注册成功的执行器，供任务调度时使用。

• 名称: 执行器的名称（可以使用中文更好地体现该执行器是用来干嘛的）。

• 注册方式： 调度中心获取执行器地址的方式（一般为了方便可以选用自动注册即可）。
  自动注册： 执行器自动进行执行器注册，调度中心通过底层注册表可以动态发现执行器机器地址。
  手动录入： 人工手动录入执行器的地址信息，多地址逗号分隔，供调度中心使用。

• 机器地址： "注册方式"为"手动录入"时有效，支持人工维护执行器的地址信息。

3、配置自定义任务

配置自定义任务有许多种模式，如 Bean模式（基于方法）、Bean模式（基于类）、GLUE模式等等。这里介绍通过 Bean模式（基于方法） 是如何自定义任务的（对于其余的模式可以参考官方文档）。

Bean模式（基于方法）也就是每个任务对应一个方法，通过添加 @XxLJob(value=“自定义JobHandler名称”, init = “JobHandler初始化方法”, destroy = “JobHandler销毁方法”) 注解即可完成定义。

/**
 * 任务处理类
 *  * @author 单程车票
 */
@Component
public class TestJob {
    /**
     * 测试任务
     */
    @XxlJob("testHandler")
    public void testHandler() {
        XxlJobHelper.handleSuccess("本次测试任务调度成功");
    }
}

• 通过注解也可以指定 初始化方法和销毁方法 ，如果不填写可以直接写一个 自定义的JobHandler名称 用于后面在调度中心中配置任务时对应任务的 JobHandler 属性值。

• 可以通过 XxlJobHelper.log 来打印日志，通过调度中心可以查看执行日志的情况。

• 可以通过 XxlJobHelper.handleFail 或 XxlJobHelper.handleSuccess 手动设置任务调度的结果（不设置时默认结果为成功状态，除非任务执行时出现异常）。

4、调度中心中新增任务

这里主要注意 Cron 表达式的时间配置以及 JobHandler 的值需要与自定义任务方法的注解上的 value 属性值一致即可。

关于高级配置这里放一张中文文档的详细说明（也可以直接去看文档）：

需要搭建集群或过期策略等高级玩法时可以进行配置。

到这里就完成了 SpringBoot 集成 xxl-job 实现分布式任务调度的全过程了，接下来会通过一个实战案例来具体看看 xxl-job 的用处。

4、xxl-job 实战

下面通过一个最近自己在跟着做的学习项目中使用到 xxl-job 的场景案例来具体了解一下如何利用 xxl-job 来实现任务调度。

1、实战背景

当前项目需要对上传到分布式文件系统 minio 中的视频文件进行统一格式的视频转码操作，由于本身视频转码操作会带了很大的时间消耗以及 CPU 的开销，所以考虑集群服务下使用 xxl-job 的方式以任务调度的方式定时处理视频转码操作。

这样可以带来两个好处：① 以任务调度的方式，可以使得视频转码操作不会阻塞主线程，避免影响主要业务的吞吐量；② 以集群服务分片接收任务的方式，可以将任务均分给每个机器使得任务调度可以并行执行，提高总任务处理时间以及降低单台机器 CPU 的开销；

xxl-job 执行流程图

2、怎么将任务均分给每台服务器？

由于任务执行时间过长，需要搭建集群服务来做到并行任务调度，从而减小 CPU 的开销，那么怎么均分任务呢？

利用 xxl-job 在集群部署时，配置路由策略中选择 分片广播 的方式，可以使一次任务调度会广播触发集群中所有的执行器执行一次任务，并且可以向系统传递分片参数。

利用这一特性可以根据 当前执行器的分片序号和分片总数 来获取对应的任务记录。

先来看看 Bean 模式下怎么获取分片序号和分片总数：

// 分片序号（当前执行器序号）
int shardIndex = XxlJobHelper.getShardIndex();
// 分片总数（执行器总数）
int shardTotal = XxlJobHelper.getShardTotal();

有了这两个属性，当执行器扫描数据库获取记录时，可以根据 取模 的方式获取属于当前执行器的任务，可以这样编写 sql 获取任务记录：

select * from media_process m
where m.id % #{shareTotal} = #{shareIndex}  
  and (m.status = '1' or m.status = '3')
  and m.fail_count < 3
limit #{count}

扫描任务表，根据任务 id 对分片总数 取模 来实现对所有分片的均分任务，通过判断是否是当前分片序号，并且当前任务状态为 1（未处理）或 3（处理失败）并且当前任务失败次数小于3次时可以取得当前任务。每次扫描只取出 count 个任务数（批量处理）。

因此通过 xxl-job 的分片广播 ＋ 取模 的方式即可实现对集群服务均分任务的操作。

3、怎么确保任务不会被重复消费？

由于视频转码本身处理时间就会比较长，所以更不允许服务重复执行，虽然上面通过分片广播＋取模的方式提高了任务不会被重复执行的机率，但是依旧存在如下情况：

如下图，有三台集群机器和六个任务，刚开始分配好了每台机器两个任务，执行器0正准备执行任务3 时，刚好执行器2宕机了，此时执行器1刚好执行一次任务，因为分片总数减小，导致执行器1重新分配到需要执行的任务正好也是任务3 ，那么此时就会出现执行器0和执行器1都在执行任务3 的情况

那么这种情况就需要实现幂等性了，幂等性有很多种实现方法，有兴趣了解的可以参考：开发中常遇到的接口幂等性问题及实现 [4]

这里使用乐观锁的方式实现幂等性，具体 sql 如下：

update media_process m
set m.status = '2'
where (m.status = '1' or m.status = '3')
  and m.fail_count < 3
  and m.id = #{id}

这里只需要依靠任务的状态即可实现（未处理1；处理中2；处理失败3；处理成功4），可以看到这里类似于 CAS 的方式通过比较和设置的方式只有在状态为未处理或处理失败时才能设置为处理中 。这样在并发场景下，即使多个执行器同时处理该任务，也只有一个任务可以设置成功进入处理任务阶段。

为了真正达到幂等性，还需要设置一下 xxl-job 的调度过期策略和阻塞处理策略来保证真正的幂等性。分别设置为 忽略 （调度过期后，忽略过期的任务，从当前时间开始重新计算下次触发时间） 和 丢弃后续调度 （调度请求进入单机执行器后，发现执行器存在运行的调度任务，本次请求将会被丢弃并标记为失败）。