分布式任务调度实战：XXL-Job分片广播与异步重试方案落地

定时任务散落在各服务里，缺少统一管理就会遇到重复执行、失败无告警、扩缩容后任务漂移等问题。XXL-Job是应用广泛的分布式任务调度中间件，通过执行器注册与调度中心解耦，支持分片广播、失败重试与任务告警。本文给出部署、接入、分片与高可用配置的完整步骤。

调度中心与执行器架构

XXL-Job由调度中心（admin）与执行器（executor）两部分组成。调度中心负责任务注册、触发与日志管理；执行器部署在业务服务内，接收调度指令并执行JobHandler。多实例执行器自动注册到调度中心，通过路由策略选择执行节点。

调度中心部署与初始化

docker run -d --name xxl-job-admin \
  -p 8080:8080 \
  -e PARAMS="--spring.datasource.url=jdbc:mysql://10.0.0.5:3306/xxl_job?useUnicode=true" \
  -v /data/xxl-job:/data/applogs \
  xuxueli/xxl-job-admin:2.4.0

数据库脚本位于官方GitHub的doc/db目录，导入后访问 http://ip:8080/xxl-job-admin 初始账号admin/123456。

Spring Boot执行器接入

xxl:
  job:
    admin:
      addresses: http://10.0.0.5:8080/xxl-job-admin
    accessToken: default_token
    executor:
      appname: order-executor
      port: 9999

@XxlJob("syncOrderJob")
public void syncOrderJob() {
    XxlJobHelper.log("sync order start");
    // 业务逻辑
    XxlJobHelper.log("sync order end");
}

执行器配置appname需与调度中心新增执行器的名称一致，端口为执行器回调端口，勿与业务端口冲突。

分片广播处理大数据量任务

海量数据同步适合分片模式，每个执行器处理自己的分片序号：

@XxlJob("shardingOrderJob")
public void shardingOrderJob() {
    ShardingUtil.ShardingVO vo = ShardingUtil.getShardingVo();
    int index = vo.getIndex();   // 当前分片号
    int total = vo.getTotal();   // 总分片数
    List<Long> ids = orderDao.selectByMod(ids, index, total);
    for (Long id : ids) { process(id); }
}

分片数等于执行器实例数，调度中心把任务同时发给所有分片，各分片只处理自己的区间，达到水平扩展。

失败重试与告警通知

任务配置里可设置失败重试次数与告警联系人，重试间隔固定。幂等是分布式任务底线：处理前先查幂等表，避免重试造成重复扣款、重复发单。

INSERT INTO job_trigger_log(task_key, status) VALUES (?, 'RUNNING') ON DUPLICATE KEY UPDATE status='RUNNING';

任务编排与依赖调度

父子任务通过子任务ID编排，父任务成功后才触发子任务，适合”先拉数据、再清洗、后写入”的多阶段流水线。延迟执行与Cron表达式同时支持，注意Cron时区统一用Asia/Shanghai。

监控与运维检查点

调度中心自带任务日志、调度报表与执行器健康状态。生产环境每天检查：执行器在线数、失败任务数、调度延迟。执行器下线后任务按失败策略执行，告警后优先确认节点进程与注册状态。分布式任务调度的核心是”一次且仅一次”语义，从幂等设计与重试策略两端同时保障。