定时任务系统怎么设计？一次讲清任务注册、分布式调度、幂等执行与失败补偿

大家好，我是一名有 4 年工作经验的 Java 后端开发。

很多业务系统里，定时任务一开始只是几个 @Scheduled，但项目做着做着，很快就会遇到重复执行、错过执行、任务堆积和人工补跑这些问题。

这篇文章我想系统聊一聊定时任务系统到底怎么设计。

🦅个人主页

🐼

文章目录

定时任务系统怎么设计？一次讲清任务注册、分布式调度、幂等执行与失败补偿
- [一、为什么定时任务不能只靠 @Scheduled](#一、为什么定时任务不能只靠 @Scheduled)
- 二、任务系统的核心能力
- 三、最常见的实现方式
- - [3.1 轻量型](#3.1 轻量型)
  - [3.2 中间型](#3.2 中间型)
  - [3.3 平台型](#3.3 平台型)
- 四、最关键的几个设计点
- - [4.1 分布式互斥](#4.1 分布式互斥)
  - [4.2 任务幂等](#4.2 任务幂等)
  - [4.3 执行日志](#4.3 执行日志)
  - [4.4 补偿能力](#4.4 补偿能力)
- 五、数据库设计示例
- - [5.1 任务定义表](#5.1 任务定义表)
  - [5.2 任务执行日志表](#5.2 任务执行日志表)
- 六、面试中怎么回答
- 七、总结
- 八、结尾

一、为什么定时任务不能只靠 @Scheduled

@Scheduled 当然很好用，但它更适合：

简单任务
单实例
低复杂度场景

真正线上常见的问题包括：

多实例部署时重复执行
某次执行太久，下一次又来了
失败后怎么补跑
某些任务需要人工暂停 / 恢复

这说明定时任务真正要解决的是：

任务什么时候执行、由谁执行、失败怎么办、是否允许重复执行。

二、任务系统的核心能力

我更建议任务系统至少具备：

任务注册
触发时间配置
分布式互斥
执行日志
重试 / 补偿
手工触发
暂停 / 启用

如果这些能力都没有，任务系统后期会越来越难维护。

三、最常见的实现方式

3.1 轻量型

直接用 Spring @Scheduled

适合：

任务少
只有一实例

3.2 中间型

@Scheduled + 分布式锁

适合：

多实例部署
任务逻辑不算太复杂

3.3 平台型

任务中心 / XXL-JOB / Quartz / 自研调度平台

适合：

任务多
需要可视化运维
需要统一调度治理

四、最关键的几个设计点

4.1 分布式互斥

多实例部署时，最怕同一个任务被多台机器同时执行。

所以至少要有：

分布式锁

或

调度中心统一分配执行者

4.2 任务幂等

即使你做了锁，也不能完全依赖"只会执行一次"。

任务本身最好仍然是幂等的。

4.3 执行日志

至少要知道：

什么时候执行
执行成功还是失败
失败原因是什么
执行了多久

4.4 补偿能力

任务失败后，不能只靠"等下次再说"，很多关键任务需要：

重试
补跑
人工触发

五、数据库设计示例

5.1 任务定义表

sql 复制代码

CREATE TABLE job_config (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    job_code VARCHAR(64) NOT NULL,
    job_name VARCHAR(128) NOT NULL,
    cron_expr VARCHAR(64) NOT NULL,
    status VARCHAR(16) NOT NULL,
    handler_name VARCHAR(64) NOT NULL,
    UNIQUE KEY uk_job_code (job_code)
);

5.2 任务执行日志表

sql 复制代码

CREATE TABLE job_execute_log (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    job_code VARCHAR(64) NOT NULL,
    trigger_time DATETIME NOT NULL,
    start_time DATETIME DEFAULT NULL,
    end_time DATETIME DEFAULT NULL,
    execute_status VARCHAR(16) NOT NULL,
    error_msg VARCHAR(512) DEFAULT NULL
);

六、面试中怎么回答

如果面试官问你：

定时任务系统一般怎么设计？

你可以这样回答：

第一，如果任务非常少且是单实例场景，@Scheduled 足够；但如果是多实例部署或任务较多，我会优先考虑分布式锁或调度中心，不会只依赖最简单的本地定时器。

第二，任务系统最重要的几个能力是分布式互斥、任务幂等、执行日志和失败补偿。因为线上真正的问题往往不是"能不能定时执行"，而是"会不会重复执行、失败后怎么办、执行记录能不能追"。

第三，如果任务规模再大，我会考虑引入统一的任务调度平台，比如 XXL-JOB 或类似方案，这样更方便做可视化运维和任务治理。

七、总结

定时任务真正难的不是"怎么定时"，而是：

多实例下怎么不重复
失败怎么补
日志怎么查
人工怎么兜底

如果只记一句结论，我觉得可以记住这句：

定时任务系统最稳的设计通常不是只会写 @Scheduled，而是"调度、互斥、幂等、日志、补偿"一起考虑。

八、结尾

如果你觉得这篇文章对你有帮助，欢迎点赞、收藏、关注。

后面我会继续整理一些更偏实战的 Java 后端和线上治理文章，尽量少写空泛概念，多写真实项目里会踩到的坑。