把定时任务从单机搬到集群调度（XXL-JOB）

业务系统里的定时任务，早期大多靠一台机器上的 crontab，或者 Spring 的 @Scheduled 跑着。机器扩到十台以后就不太行了：同一个任务每台机器都触发一次，昨天哪次跑失败了没人说得清，改一次 Cron 还要重新发版上线。XXL-JOB 把这件事拆成两个角色，调度中心决定什么时候触发、派给哪台机器，执行器只负责执行被派过来的那段业务代码。

XXL-JOB 是一个用 Java 写的分布式任务调度平台，分为调度中心与执行器两层，在 Web 界面配置 Cron 触发规则，执行器收到调度后运行对应的业务代码。

仓库从 2015 年 11 月建起，目前 Star 数 30608、Fork 11496、开放 Issue 66 个，最近一次提交在 2026 年 10 月，最新发布版本 3.5.0。代码 99.9% 是 Java，采用 GPL-3.0 许可证，地址是 https://github.com/xuxueli/xxl-job 。README 里记录的接入场景包括电商、O2O 和大数据作业。

装它需要什么

• Java 运行环境。仓库代码 99.9% 是 Java，根目录有 pom.xml 作为构建脚本，仓库里没有说明 JDK 的最低版本要求。
• 一个数据库，调度中心用它存任务和调度日志。Issue 讨论里出现的库是 MariaDB 10.0.20。
• 调度中心启动后对外提供 Web 管理界面。官方 Docker 镜像在 3.4.1 版本新增了 EXPOSE 8080 指令暴露应用端口。
• 业务工程侧需要引入 xxl-job-core，并配置所属调度中心的地址。
• 3.5.0 起 AccessToken 改成执行器维度隔离设置，旧的全局 AccessToken 已废弃。

跑起来

1. 克隆仓库：git clone https://github.com/xuxueli/xxl-job。
2. 准备数据库并初始化调度中心的表结构。仓库里没有说明初始化脚本的具体路径，官方文档里有部署章节。
3. 启动调度中心 xxl-job-admin，用浏览器打开 Web 管理界面。3.3.2 版本提供了 Docker Compose 配置，可以一键启动调度中心集群。
4. 业务工程引入 xxl-job-core，配置执行器名称、调度中心地址和 AccessToken。执行器启动后会周期性自动注册到调度中心，调度中心自动发现这些执行器。
5. 在 Web 界面新建任务，填 Cron 表达式，选运行模式、路由策略和阻塞处理策略。
6. 任务触发一次之后，进调度日志看这条记录的结果。

建任务时可配的东西不少。触发方式除 Cron 之外还有固定间隔、固定延时、API 触发和人工触发；执行器集群部署时路由策略可选轮询、随机、一致性 HASH、故障转移、忙碌转移等；调度太密集执行器来不及处理时，阻塞处理策略可选单机串行（默认）、丢弃后续调度或覆盖之前调度；任务失败可以配失败重试次数和邮件告警。GLUE 模式提供 Web IDE，可以在线写 Shell、Python、NodeJS、PHP、PowerShell 脚本，动态发布并实时编译，支持 30 个历史版本回溯。分片广播任务会把一次调度广播给集群里所有执行器，按分片参数并行处理，执行器扩容时分片数量跟着增加。

输出是什么

结果落在调度中心的 Web 界面上。任务列表给出每个任务的最近一次调度结果；调度日志能查每次触发的时间、执行器地址、耗时和失败原因；Rolling 实时日志展示执行器输出的完整执行过程；运行报表页给出任务数量、调度次数、执行器数量，以及调度日期分布图、调度成功分布图。

判断这次跑成功的标准很直接：调度日志里那条记录状态是成功，执行器日志有对应输出。任务失败时按配置发邮件告警，支持配置多地址群发。

先说它做不到什么

Issue 区里有两条踩坑记录值得先知道。一条是 docker 部署的执行器注册到调度中心时上报的是容器自己的 IP，调度中心因此访问不到执行器；另一条是任务表数据积累多了之后出现慢 SQL。两条在 issue 里都标为已解决，但它们说明部署形态和表数据量需要提前规划，别等线上再补。

• 调度中心和执行器存在版本耦合。3.5.0 把 AccessToken 调整为执行器维度，OpenAPI 通讯协议部分随之发生适配变化，调度中心与执行器必须一并升级到 v3.5.0，只升一边会不通。
• 任务参数最长支持 2048 字符，这是 3.4.1 调整后的上限。超出这个长度的数据要另找传参通道。
• 许可证是 GPL-3.0。把它集成进自有产品再对外分发之前，需要先评估许可证带来的合规影响。
• 用 PowerShell 类型的 GLUE 任务，执行器所在机器需要装 PowerShell 7.0 及以上版本，否则没有 pwsh 命令可用。

适合已经跑在 Java 技术栈上、任务量开始超出单机 crontab 承载范围的团队，也适合需要把任务执行状态、日志和告警收拢到一个界面上统一看的人。任务只跑在本机、对调度精度和可观测性没有要求的场景，用系统自带的定时器就够，不必引入这一套。

焚评：这个项目的量化评分

本项目的选题来自 焚.com（一个按公开公式给 GitHub 项目打分的站）。焚评当前总分 10.0 分（满分 10）。下表是各维度的得分：

评分口径、权重与计算方式见焚.com 的评分方法页；数据随 GitHub 指标刷新，具体数值以焚.com 当前页面为准。本文正文为诀.com 独立撰写，评分数据由焚.com 授权引用。