从@Scheduled到XXL-JOB：分布式任务调度平台搭建实战

1. 定时任务从单机到分布式，到底卡在了哪一步

先聊点实际的。很多团队最早接触定时任务，都是从Spring自带的@Scheduled注解开始的，写一个方法，加个注解，cron表达式一填，到点执行，完事。这个阶段确实舒服，代码里不需要额外引入任何东西，部署也简单，一个应用进程里自己就把活干了。但业务一旦开始膨胀，问题就接踵而至。

我印象很深的一次经历：当时我们有个订单超时自动关闭的任务，每天凌晨跑一次，负责扫描订单表里所有超过30分钟未支付的记录。单量小的时候，这个任务跑几十秒就结束了。后来业务增长，订单量翻了几倍，任务执行时间从几十秒拉长到二十多分钟，数据库扫描压力也上来了。更要命的是，服务端为了抗住流量做了多节点部署，每个节点都在跑同一个@Scheduled任务，到了凌晨那个点，三个实例同时扫订单表，出现大量重复关闭和并发修改，线上直接报警。

这就是单机定时任务在分布式环境下的典型困境：无法集中管理、无法避免重复执行、无法动态调整执行计划。改一次执行时间要发版重启，任务执行失败没有统一的重试和告警机制，想看历史执行记录得翻日志，任务多了以后根本没有一个全局视角。这时候就需要一个专门的调度平台来统一承接这些活，XXL-JOB就是这类开源方案里应用非常广泛的一个。

XXL-JOB是一个轻量级分布式任务调度平台，核心解决的就是任务统一管理、动态调配、分布式执行和全生命周期监控这几件事。它把"调度中心"和"执行器"拆成两个独立的角色，调度中心负责任务的注册、触发、日志管理，执行器负责真正执行业务逻辑。调度中心和执行器可以各自独立集群部署，互不影响，任务也不会因为某个执行器节点宕机而丢失。对于大多数从@Scheduled往分布式调度过渡的团队来说，XXL-JOB几乎是上手成本最低的选择，Spring Boot项目引入一个依赖、配几个参数就能跑起来。

下面我把从部署到接入、再到生产环境高可用的完整链路拆开讲一遍，重点会放在那些文档里不会详细说、但实际部署和运维时一定会踩的细节上。

2. 部署调度中心之前，先把它的角色分工搞清楚

2.1 调度中心与执行器，不是同一个东西

第一次接触XXL-JOB的人，最容易混淆的就是调度中心（Admin）和执行器（Executor）之间的边界。简单理解，调度中心是大脑，执行器是手脚。大脑负责的事包括：维护任务定义、按cron或API触发任务、记录调度日志、处理任务的路由策略、执行失败重试。它本身不写任何业务代码，也不会去操作你的业务表。手脚也就是执行器，是一个个嵌在你业务应用里的组件，它接收大脑下发的调度指令，调用你写好的业务方法，然后把执行结果回传给大脑。

整个流程大致成这样：你把一个任务注册到调度中心，调度中心到了时间点或者收到手动触发请求，会按照你配置的路由规则，从注册列表里挑出一个（或一批）执行器实例，发送HTTP请求触发对应的JobHandler。执行器收到请求后，通过内部的线程池异步执行你的业务代码，执行完成再把结果上报。调度中心全程记录每一次调度的状态、耗时、日志，你在管理界面上就能看到完整的执行链路。

2.2 为什么说它比Quartz自己封装更适合业务团队

很多人可能会问，Quartz本身已经提供了分布式集群能力，为什么还要引入XXL-JOB？我个人的理解是，Quartz是一个调度库，它解决的是"任务触达"问题，但它不解决"任务管理"问题。用Quartz做分布式调度，你需要自己写集群同步逻辑、自己管理任务存储、自己写一套Web管理界面来增删改任务。而XXL-JOB从一开始就是按平台思路设计的：调度、执行、管理、监控、告警全都有开箱即用的能力。数据库只需要初始化几张调度中心自己的表，业务团队不需要在业务库里建任何额外表。执行器集成时也不需要引入额外容器，业务服务本身扛起了执行职责。

从维护角度看，XXL-JOB的调度中心提供一个非常直观的Web控制台，任务启停、手动执行一次、查看每一条调度日志、查看执行结果报表，都能在界面上完成，不需要写SQL去后台翻任务状态。岗位交接、日常运维、给非开发同事开通查看权限做任务核对，都很方便，这一点对业务团队来说价值很大。

3. 从零搭建调度中心，这步做完先别急着写代码

3.1 初始化数据库，两张表的命名容易让人犯迷糊

去GitHub把源码下载下来，项目里有doc/db/tables_xxl_job.sql这个SQL脚本，先在MySQL里执行一遍。这里提醒一下，XXL-JOB的调度中心配置库和执行器自己的业务库没有半毛钱关系，执行器不依赖这个库里的任何数据。这个库里存的都是调度中心的元数据，包括任务信息、调度日志、执行器注册信息、用户权限等。

我见过不少第一次部署的人会在这里犯嘀咕，说"我执行器接入了，怎么业务库里多了这么多表"。不会有这个事的，调度中心的表只在调度中心对应的库里生成。如果你拿到源码自己改过，记得确认SQL版本和你要部署的Admin版本匹配。2.x和3.x的表结构有差异，用错了版本启动阶段就会报表不存在或者字段缺失的错。

SQL执行完之后，用IDEA打开调度中心的源码工程xxl-job-admin，修改application.properties配置数据库连接信息。有几个参数值得注意：

• spring.datasource.url：数据库连接地址，注意加上useUnicode=true&characterEncoding=UTF-8&useSSL=false&serverTimezone=Asia/Shanghai，否则会出现中文字符乱码和时区导致的调度时间偏移问题。
• spring.datasource.username / password：数据库账号，建议单独建一个账号，权限只给这个库，不要用root在生产环境直接连。
• xxl.job.accessToken：调度中心与执行器通信的令牌，默认是空的。生产环境一定要设置一个复杂字符串，所有执行器端的配置要和这里保持一致，否则执行器注册不上来。

配置改完，直接启动XxlJobAdminApplication这个主类。默认端口是8080，管理界面登录地址是http://localhost:8080/xxl-job-admin，默认账号密码是admin / 123456。登录进去以后，左侧菜单能看到执行器管理、任务管理、调度日志、用户管理等模块，这就说明调度中心起来了。

3.2 端口、部署路径和反向代理的那点事

调度中心默认端口8080，如果你本机已经有别的服务占了，直接改server.port就行。需要特别注意的是，XXL-JOB的管理界面默认是有Context Path的，配置在server.servlet.context-path，默认值就是/xxl-job-admin。如果你要自己接Nginx做反向代理，必须把这个路径保留好，不能为了方便直接用location /去代理到根路径，否则页面里的静态资源、接口请求全部会404。

我推荐的生产环境部署方式是：调度中心单独拆出来跑，不要和业务应用混在一个Tomcat里。资源占用上XXL-JOB的Admin非常轻，给它1核2G的容器就足够支撑几千个任务的调度了，关键是要保证网络稳定。如果是跨机房部署，需要确保调度中心能访问到所有执行器实例的网络端口，执行器默认暴露的是9999端口，这个后面接入时会用到。

4. 执行器接入Spring Boot，几个参数一个都不能错

4.1 POM依赖和YAML配置，照着抄也得知道每个字段干什么

调度中心起来之后，接下来就是让业务应用作为一个执行器接入进来。以我常用的Spring Boot项目为例，第一步先引入依赖：

xml复制<dependency>
    <groupId>com.xuxueli</groupId>
    <artifactId>xxl-job-core</artifactId>
    <version>2.4.0</version>
</dependency>

版本号务必要和调度中心保持一致，比如调度中心是2.4.0，执行器端也尽量用2.4.0，跨版本注册时可能会因为接口协议不兼容导致注册失败或者调度异常。

引入依赖后在application.yml里加上配置：

yaml复制xxl:
  job:
    admin:
      addresses: http://localhost:8080/xxl-job-admin
    accessToken: your_token_string
    executor:
      appname: order-service-executor
      address:
      ip:
      port: 9999
      logpath: ./logs/xxl-job/jobhandler
      logretentiondays: 30

逐个说下这几个配置对应什么。admin.addresses是调度中心的完整地址，如果有多个调度中心节点做集群，用逗号分隔多个地址就行。accessToken和调度中心里配置的保持一致。executor.appname是执行器的名字，这个很关键，后面在调度中心的执行器管理里注册时用的就是这个名字，它会作为执行器的唯一业务标识。

executor.port是执行器暴露给调度中心调用的端口，默认9999，如果应用部署在容器里，记得把宿主机的这个端口映射到容器内，同时确保调度中心所在机器能通过网络访问到这个端口。这一步出错非常隐蔽，调度中心上能看到执行器注册成功，但实际调度时超时失败，排查了半天最后发现是安全组把9999端口拦了。

executor.logpath是执行器跑任务时本地日志的存放路径，调度中心界面上查看的"执行日志"其实就是远程拉取这个目录下的日志文件内容。如果这个路径配错了，界面上执行日志会显示为空或者加载失败，但任务本身是正常跑了的，特别注意这一点。

executor.logretentiondays是日志保留天数，XXL-JOB会自动清理超过这个天数的本地日志文件。生产环境可以根据日志盘空间来配置，一般30天足够排查问题了，没必要永久保留。

4.2 启动类里声明Bean，别忘了让容器扫描到它

配置文件写好还不够，还要在Spring Boot的启动类或者某个@Configuration类里创建一个XxlJobSpringExecutor的Bean。官方的示例是在启动类里加，但如果你项目里对包扫描有定制化路径，扫不到这个配置类的话，执行器组件是起不来的，症状就是调度中心执行器管理里一直看不到你的应用上线。

为了避免这种问题，我习惯单独建一个XxlJobConfig配置类放在启动类同级的包下，确保能被扫描到。示例代码里通常长这样：

java复制@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.port}")
    private int port;

    @Bean
    public XxlJobSpringExecutor xxlJobExecutor() {
        XxlJobSpringExecutor executor = new XxlJobSpringExecutor();
        executor.setAdminAddresses(adminAddresses);
        executor.setAppname(appname);
        executor.setPort(port);
        executor.setAccessToken(accessToken);
        return executor;
    }
}

这里我重点说一下setAppname这个动作。它对应的是调度中心执行器管理里那个AppName。你业务的唯一标识就靠这个字段映射，假设你的服务有10个节点，所有节点的appname都配成同一个，调度中心只显示一条执行器记录，但地址列表里会有10个实例地址。路由策略按配置去选择执行器节点时，就是在这10个实例里做选择。

启动应用后，回到调度中心的执行器管理页面，点击"机器管理"查看在线机器地址，如果能看到你本机的IP加9999端口，说明执行器已经成功注册到头上了。如果一直看不到，从这几个方向排查：accessToken不一致、9999端口没监听、admin.addresses填的地址在业务应用所在网络访问不通。

5. 任务管理页面里，最容易被忽略的配置项其实是这些

5.1 创建任务时的字段选择，比想象中要讲究

调度中心里左侧点任务管理，新增任务，这一页面的配置项非常多。很多人在这一步比较随意，任务能跑就行，实际后面排查问题时才发现字段含义没搞懂，带来的成本比想象中大。

先看基础配置。任务描述建议写清楚这个任务是干什么的，比如"每5分钟扫描待支付订单并发送超时提醒"。职责描述清晰，后续运维排查会省很多事。

调度类型有三种：Cron、固定速度、固定延迟。Cron就是标准的cron表达式，用得多。固定速度是每隔多少秒执行一次，不关心上次任务是否结束，可能存在任务重叠。固定延迟是上次执行完后再隔多少秒执行下一次，天然避免重叠。业务上如果你的任务不允许重叠执行，且执行时长不确定，选固定延迟比Cron表达式更实用。Cron要做"每N秒执行一次"很难写，例如每90秒，cron表达式处理起来非常别扭，而固定速度或固定延迟一个参数就搞定了。

Cron表达式这里我提醒一下，XXL-JOB支持到秒级别，和Spring的@Scheduled语义一致，是6位或7位表达式的格式，和Linux的5位crontab不是一回事。比如0 0 1 * * ?表示每天凌晨1点触发，但在Linux的crontab里可能直接写0 1 * * *，把这两个搞混是大坑。我第一次用XXL-JOB时就把?和*弄混了，结果任务完全没按预期时间跑。

路由策略是任务调度在多个执行器节点之间的分配方式，生产上最常用的几个会在后面详细讲，这里先提一下：第一个、最后一个、轮询、随机、一致性HASH、最不经常使用、最近最久未使用、故障转移、忙碌转移、分片广播。如果你是第一次部署，建议先选轮询，因为轮询语义最直观，多个节点轮流干活，日志也容易核对。分片广播适合做大数据量分批处理的场景，后面我会单独讲。

5.2 调度时间、阻塞处理与失败重试的配合逻辑

阻塞处理策略有单机串行、丢弃后续调度、覆盖之前调度，这个字段决定任务执行中如果再次被触发，应该怎么办。它和调度类型配合起来才完整。Cron触发的任务跑得慢，上一次还没结束下一次就到点了，这时单机串行会让新一次任务排队等上一次跑完，保证不丢任务；丢弃后续调度则是说上次还没跑完，这次触发直接丢弃不执行，适合实时性要求不高、重跑没意义的场景；覆盖之前调度适合那种"结果以最新一次为准"的场景，任务内自行打断旧任务。

失败重试次数默认是0，如果你希望任务偶发失败能自动重跑，可以设成2或者3。这里的重试是整次任务重新调度，在相同或者按照路由策略选出的下一个执行器上再跑一次。结合我自己的经验，并非所有任务都适合自动重试。如果业务逻辑本身不是幂等的，重试可能带来重复数据。比如转账触发任务重试后可能重复扣款，这类任务失败时必须人工介入核对。在这个问题上不要偷懒，一定要想清楚你的业务能不能接受重试。

任务超时时间单位是秒。如果你的任务可能跑很久，比如一个几百万数据的分片处理任务，超时时间设置太短会被强制中断。XXL-JOB单次任务执行超时控制依赖于任务线程的响应，如果你的任务里自己又开启了子线程执行，超时可能无法精确触发中断。所以判断超时要结合自己的业务逻辑来看，不能完全当作进程级kill来依赖。我生产环境的实践是：能拆小分批的任务尽量拆小分批，单次控制在几分钟内跑完，这样既方便通过超时兜底，调度资源也更均衡。

6. 手动执行和GLUE模式，日常开发和救急的两把利器

6.1 手动执行一次，是调试任务最省事的路径

任务创建好以后，在任务管理列表的操作列里有个"执行一次"按钮，这是调试阶段最有用的功能。不需要等到cron时间点，点了立刻触发一次调度。配合调度日志里的"查看日志"，你可以在线看到完整执行日志，比本地Debug还要直观。

我调试一个处理器时通常的做法是：页面点执行一次，去调度日志里看日志输出，如果抛异常了，把异常堆栈拉出来改代码，改完再点一次。整个过程不需要写单元测试也不用发版，尤其是在执行器已经部署到测试环境的情况下，这种线上调试的体验非常爽。这里提醒一下，手动执行一次与手动触发一次是有区别的。"执行一次"是这次调度走完整调度流程，会去匹配执行器并按路由策略挑节点。如果执行器全部下线了，界面上会提示调度失败，任务不会凭空在调度中心进程里被消费掉。

6.2 GLUE模式到底适合什么场景

GLUE（胶水）模式是XXL-JOB很有特色的一个功能，官方说法是可以实现任务在线编辑、动态发布、实时生效。用大白话说，就是你不必把JobHandler写死在业务应用里编译部署，而是把一段代码直接贴在调度中心的任务配置页面上，调度时由执行器动态加载这段代码执行。

GLUE模式有两种：GLUE(Java)和GLUE(Shell)，还有GLUE(Python)、GLUE(Node.js)等扩展模式。其中GLUE(Java)最实用，因为执行器端本身就是Java应用，动态加载一段Java源代码并运行不需要额外依赖。默认源码模板会给你生成一个继承IJobHandler的类，你在execute方法里写自己的逻辑就行。

我个人的经验是，GLUE模式最适合两类场景。一类是临时性任务，比如数据订正、脏数据清理、临时统计，这些任务可能就今天这一次下个季度才有一次，没必要为它发一个版本，线上用GLUE写好点执行一次就行。另一类是运维类任务，比如批量刷新缓存、给指定用户补发消息，这类任务经常需要带参数动态执行，GLUE模式下在任务里读取传入参数即可，非常灵活。

但GLUE模式不能滥用。它动态加载的特性决定了在调度中心的数据库里维护着一份代码副本，如果公司要求所有代码走Git仓库受版本管理并有完整发布审批流程，GLUE模式存续的代码不在代码仓库里，会产生流程上的合规漏洞。权限管理也会变得重要，因为任何能登录调度中心并修改任务的人，都有能力在GLUE(Java)里写一段恶意代码、然后在任意一台执行器实例上执行。生产环境建议把调度中心的管理权限收敛给一小部分核心开发，同时定期审计GLUE模式的任务。

GLUE(Java)模式跑起来时，调度中心会把代码下发到执行器，但任务的运行日志依然会记录在调度中心，方便统一查询。还有一个细节，修改GLUE代码后不需要重启应用，但要确保执行器有足够的临时目录空间去保存编译生成的临时class文件。遇到GLUE更新后执行报类找不到或者方法找不到，通常是执行器端和调度中心版本号不一致导致的，先把两边的版本对齐再试。

7. 分布式场景里的路由和分片，这才是XXL-JOB的精华

7.1 路由策略的选型，没有万金油只有合适的场景

前面提到任务可以配置路由策略，这里展开说几个在生产环境里真正派得上用场的。第一个，其实没什么特别，就是每次都选任务注册的机器列表里的第一台。适合那种只有一台机器允许执行某种任务的情况，比如只连了某个内网数据的机器。

轮询，每一次调度按顺序轮流分配到不同机器上。适合任务执行耗时相对均衡、节点处理能力一致的场景，比如每台机器上跑一批数据校准任务。一致性HASH，同一个任务参数会始终路由到同一台机器，适合需要把某个业务维度的数据固定在同一台执行器上处理的场景，比如任务参数里按用户ID分片，一致性哈希能让同一个用户的数据始终被同一个执行器处理，避免多台机器同时改同一个用户的数据造成锁竞争。

故障转移，调度中心在触发时会先尝试第一个执行器地址，如果调用失败或执行超时，自动切换到下一个执行器地址，直到成功或全部失败。这个策略适合对实时性有要求，但业务执行器允许换机器执行的场景。注意它和失败重试的配合逻辑，这里不过多展开。

忙碌转移，先检查执行器是否忙碌（正在跑任务），如果忙碌就切到下一台。适合任务执行时间较长、不希望多台机器同时跑同一个任务的场景。如果所有机器都忙碌，这次调度就标记为失败，不会排队慢慢等。

实际选型上没有万能策略，这里列出我常用的一组判断方式：

• 任务是纯后台计算、无状态、执行时间短：轮询或随机，节点均匀分摊。
• 任务需要固定某个节点执行、能接受单点风险：第一个或最后一个。
• 任务按参数分片、每个参数独立处理：一致性HASH，业务上保持亲和性。
• 任务处理量大、单机跑太久：分片广播，所有机器各分一块。
• 关键链路任务、执行器节点经常发布重启：故障转移，提升单次调度成功率。
• 任务执行时间长且CPU密集：忙碌转移，避免节点重负载。

7.2 分片广播的实战套路

分片广播可能是XXL-JOB在所有分布式任务调度框架里最让人喜欢的一个设计了。它在一次调度里同时触发所有执行器节点，每个节点收到同一个任务的执行请求，但能在运行时取得当前分片信息，代码里根据分片参数只处理自己要处理的那一部分数据。

举个例子，现在有100万条用户数据需要重新计算积分。三台执行器节点，路由策略选分片广播。三台机器同时收到调度指令，第一台拿到分片参数0/3，第二台拿到1/3，第三台拿到2/3。代码里的逻辑就是userId % 3取余，余数等于自己分片编号的数据才处理。这样100万的数据被三等分，三台机器并行处理，整个任务耗时理论上缩短到单机的三分之一，是XxlJob最经典的用法之一。

Handler代码骨架如下：

java复制@XxlJob("scoreRefreshJobHandler")
public void scoreRefreshJobHandler() throws Exception {
    ShardingUtil.ShardingVO shardingVO = ShardingUtil.getShardingVo();
    int shardIndex = shardingVO.getIndex(); // 当前分片索引，0开始
    int shardTotal = shardingVO.getTotal(); // 总分片数
    // 从数据库查出来需要处理的数据列表，按ID取模分配给当前分片
    List<Long> userIds = queryAllUserIds();
    for (Long userId : userIds) {
        if (userId % shardTotal == shardIndex) {
            refreshScore(userId);
        }
    }
}

这里有几个分片广播容易踩的坑。第一，分片数是动态的，如果执行器有节点扩容或者缩容，总分片数会随着在线机器数量变化，数据分配的边界就变了。正在跑的长任务如果要跨分钟执行，这个变化可能导致同一批数据被不同节点重复处理，或者部分数据漏处理。对这种场景，我建议要么任务本身做成幂等，要么在任务执行前先保证执行器节点数量稳定，发布时先扩容、任务跑完再缩容。

第二，分片广播会触发所有在线节点，如果任务本身只适合单机跑，千万别选分片广播。有时团队里其他同事不太了解XXL-JOB的机制，新建任务时看着"分片广播"听起来很厉害就选了，实际任务逻辑里完全没做分片处理，结果是每台机器都全量跑了一遍，产线数据重复处理事故就是这么来的。

8. 跑起来之后，那些文档里找不到的异常与排查路径

8.1 调度日志显示成功但业务没执行，十有八九是循环依赖

有次在测试环境，我建了一个每隔5分钟跑一次的任务，任务管理页面看调度日志，每次调度都成功，执行器地址也显示出来了，但业务表里的数据纹丝不动。最初以为是GLUE代码写错了，结果手动点执行一次，看详细日志卡了很久，最后报出了一个循环依赖的异常。

这个现象在业务代码注入上比较典型。执行器的JobHandler实例本质上也是Spring容器里的一个Bean，你在里面的@Resource注入如果和正常Spring Bean之间形成了循环依赖，在Spring Boot 2.6之后默认禁止循环依赖的环境下，Bean初始化阶段就会直接报错。但因为XXL-JOB的JobHandler大部分是懒加载、配合字节码增强或代理对象创建时才会触发注入，所以错误不会在应用启动时暴露，而是在第一次调度时才炸出来，表现上就是"调度成功但业务方法内部其实抛了异常"。

排查这种问题时，不要只看调度结果，一定要点进调度日志里看完整堆栈。调度日志会把任务执行过程中抛出的异常完整记录下来，如果日志里只显示了调度成功的信息，再点开具体的"执行日志"标签页看JobHandler内部输出，多花几秒钟就能少走不少弯路。

8.2 执行器注册了但找不到JobHandler，注解的名称没对上

还有一种情况极其常见：执行器注册成功，任务也能触发，但日志直接报TaskHandler not found或者job handler xx not found。这个报错十有八九是JobHandler的名称不一致导致的。

在业务代码里声明一个JobHandler是这样写的：

java复制@Component
public class OrderJobHandler {

    @XxlJob("orderStatisticsJob")
    public void orderStatisticsJob() throws Exception {
        // 业务逻辑
    }
}

上面字符串orderStatisticsJob相当于给这个方法起了一个调度编号，调度中心创建任务时填的"JobHandler"字段必须和这个字符串一模一样，多个空格都不行。很多人在执行器端创建了Handler，忘了回到调度中心任务配置里填对应的Handler名，或者名字里多了个空格、大小写不一致，调度就会失败。另外确认一下@XxlJob注解的类确实被Spring管理，也就是类上加过@Component之类的注解。如果类没被容器管理，JobHandler也不会注册到执行器的handlerMap里，同样会报找不到。

8.3 调度中心界面偶尔进不去，先检查数据库连接池

XXL-JOB调度中心本身是一个Spring Boot应用，它的Web页面所有菜单的数据都要查MySQL。如果调度中心的数据库连接池配置得太小，或者连接被MySQL端主动断开后没有自动重连机制，界面会出现"挂起、请求一直转圈"的现象。重启调度中心进程能恢复，但过一段时间又复现。

这种问题在长时间不访问的管理界面上特别容易复现，尤其是在云数据库默认的wait_timeout比较短时。最直接的解决办法是，给数据库连接池URL加上连接有效性检查和重连参数，在配置里增加：

properties复制spring.datasource.hikari.connection-timeout=30000
spring.datasource.hikari.maximum-pool-size=50
spring.datasource.hikari.minimum-idle=10
spring.datasource.hikari.validation-timeout=5000
spring.datasource.hikari.connection-test-query=SELECT 1

使用HikariCP自带的连接测试机制，配合SELECT 1探活，能有效避免连接失效后调度中心卡死。调度中心本身不涉及很高并发的Web请求，池子配到50已经非常宽裕，别一次性给到几百，白白浪费数据库连接数。如果是自建MySQL，也可以把数据库侧的wait_timeout调大一些，双管齐下。

9. 生产环境的高可用部署，这部分不提前做早晚吃亏

9.1 调度中心集群化，一个节点挂了不影响线上调度

XXL-JOB的调度中心是支持集群部署的。部署多套调度中心实例，共用同一个MySQL数据库，前端通过Nginx负载均衡指向它们。任何一台调度中心宕机，其他节点的调度任务依然可以正常触发，因为任务元数据和调度日志都存在MySQL里，多实例之间没有本地的单机状态依赖。

我生产环境的常用形态是：两台调度中心实例，各自独立容器部署，Nginx做TCP或HTTP负载均衡，MySQL单独用高可用方案。数据库是调度中心的唯一状态源，它如果挂了，调度中心本身也难以工作，所以数据库的高可用比调度中心的实例数更重要。有条件的话，MySQL从节点、自动切换这些机制一定配置好。XXL-JOB本身不强依赖于某张表的行锁粒度，它底层用了数据库的行级锁保证调度任务不会重复触发，平滑切换从库要确认对InnoDB行锁无损。

调度中心集群模式下，务必注意各实例的accessToken配置一致，同时Nginx的负载均衡策略无特殊要求，轮询即可。如果你的调度中心实例不只一台，executor端配置的admin.addresses里要把所有调度中心的地址都配上，或者配置Nginx后的统一入口，这两者等价。

任务量很大的时候，调度中心集群的每台实例自己依然会起线程去轮询数据库里的待触发任务，所以不会有同一任务被两台机器同时触发的问题，因为XXL-JOB内部用数据库锁保障了任务调度的幂等性，集群部署的核心收益是单点故障的消除。

9.2 执行器集群与优雅上下线

执行器端的高可用依赖的是业务应用本身的集群能力。你的服务有多少个存活节点，执行器注册列表里就有多少个实例。正常发布时，Spring Boot应用在关闭前会触发执行器的注销逻辑，将当前节点的注册信息从调度中心移除，后面的调度不会再路由到这个节点上。但如果你的服务是被kill -9强杀，或者容器直接OOM被驱逐，注销逻辑来不及执行，调度中心注册列表里可能会短暂残留这个节点。XXL-JOB执行器注册信息默认有30秒的过期时间，如果执行器长时间没有和调度中心保持心跳，会自动摘除。所以宕机后节点列表短暂显示在线，但一般不会导致任务持续失败，最多错过几次调度，等心跳超时摘除后就会自动把流量转给正常节点。

业务应用发布上线的过程里，如果你想主动保证执行器先下线、任务都跑完再关进程，可以在发布脚本里提供一个健康检查端口，在关停前先调用执行器自身的某个API下线接口。不过实际场景里，只要不是频繁地把所有节点同时重启，短暂的部分节点摘除对整体调度影响有限。

9.3 监控告警不要只看调度日志，要看业务闭环

XXL-JOB自带的任务失败告警依赖邮件，调度中心配置好邮箱SMTP后，任务失败会自动发告警邮件。如果你的团队不常用邮件，或者消息分散在各IM工具里，可以基于调度中心开放的执行日志接口做二次开发，拉取失败的调度记录，转发到企业微信、钉钉等IM机器人。

但我更想说的一点是，调度侧的成功不等于业务侧的成功。假设任务本身逻辑走通了、没抛异常，但漏处理了一批数据，调度日志里显示是成功的，这种隐患很难靠调度告警发现。如果你负责的任务处理的是核心链路的数据，建议在业务方法里主动打点记录每个批次的处理量，做一个业务维度的监控大盘，或者定期执行一个校验任务检查前一个任务产出的数据是否完整。

维护分布式调度系统，时间长了你会形成一个习惯：每次上线一个新任务，除了在页面配置里确认cron、路由策略、阻塞策略之外，多写几行日志记录任务输入参数和最终处理量，收尾后看一眼调度日志确认这次调度确实按要求触达了期望的节点。这套小习惯看起来不起眼，却是线上跑得稳的真正护城河。

10. 最后分享一点基于实战的选型建议

如果你所在的团队还没有统一的定时任务平台，业务还停留在@Scheduled满天飞的阶段，当前最迫切的任务不是马上把所有任务迁移到XXL-JOB上，而是梳理一份现有定时任务清单，明确每个任务的执行频率、数据量级、依赖资源和失败影响面。有了这份清单，才能判断哪些任务适合直接迁到XXL-JOB、调度频率怎么定最合理、哪些任务应该先重构拆小再纳入调度管理。

XXL-JOB本身并不是银弹，它有非常强的任务管理和分布式执行能力，但真正让它发挥价值的前提是任务本身的逻辑清晰、幂等设计到位、资源依赖可控。这些基础不打牢，换任何平台都救不了混乱的定时任务架构。我见过有人在XXL-JOB上配置了大量一次性GLUE任务处理临时数据，爽完几个月后回头查这批逻辑完全找不到入口，最终留下一个数据口径说不清的烂摊子。工具永远只是工具，怎么组织好任务边界与业务依赖，才是干活的人最需要花心思的地方。