任务系统设计——定时、延迟、补偿是一个体系

在很多后端工程师的认知里，“任务系统”往往等同于一个注解：

@Scheduled

但真实工程中，任务系统从来不是一个 API，而是一整套保障系统可靠运行的执行体系。
它的核心目标只有一句话：

主链路保证“当下成功”，任务系统保证“迟到但不缺席”。

如果你只会写接口，不会设计任务体系，那么系统一旦失败，很可能“悄悄死掉”。

一、什么是任务系统？

任务系统的本质是：

把不适合在主流程中完成的事情，交给一个“可控、可恢复、可观测”的执行机制。

真实系统中，大量业务都不适合同步执行：

所以我们需要一个体系，专门负责这些“稍后做、失败补、重复控”的事情。

二、任务系统的三大核心类型

1. 定时任务（Scheduled）

定义：在固定时间周期执行。

典型场景：

• 每天凌晨生成报表

• 每周清理日志

• 每晚数据对账

技术实现：

• Spring@Scheduled

• Quartz

• XXL-Job

• ElasticJob

核心问题

单机环境很好，
集群环境会重复执行→ 必须配合分布式锁或调度中心。

2. 延迟任务（Delay）

定义：在未来某个时间点执行。

典型场景：

• 下单 30 分钟未支付 → 自动取消

• 注册 5 分钟后 → 发送欢迎邮件

• 工单 10 分钟未回复 → 自动关闭

技术实现方式：

方式 A：MQ 延迟队列

• RabbitMQ TTL + 死信队列

• RocketMQ 延迟等级

方式 B：Redis ZSet

• score = 时间戳

• 定时扫描到期任务

延迟任务的本质：

把“时间”变成一条队列规则。

3. 补偿任务（Compensation）

这是最容易被忽视，却最关键的一环。

定义：当主流程失败时的兜底机制。

典型场景：

• 发券失败 → 重发

• 邮件发送异常 → 恢复后补发

• 支付成功但库存未扣 → 数据修复

核心思想：

主链路不能卡死，失败允许“后补”。

补偿机制是系统“自愈能力”的体现。

三、为什么说三者是一个体系？

因为真实系统中，它们往往不是独立存在，而是组合拳。

一个典型链路：

用户下单 ↓ 发券失败 ↓ 写入任务表 ↓ 延迟 5 分钟重试 ↓ 仍失败 → 补偿任务 ↓ 人工/自动修复

可以看到：

• 定时 = 周期执行

• 延迟 = 指定时间执行

• 补偿 = 失败后执行

它们共同构成一条可靠执行链路。

四、MQ 与任务系统的关系

很多人会 MQ，却不理解任务系统，于是混为一谈。

本质区别

一句话总结：

MQ 负责“把消息送出去”，
任务系统负责“保证这件事最终一定能完成”。

MQ 在任务系统中的位置

MQ 常用于：

• 延迟执行

• 补偿重试

• 异步解耦

• 削峰填谷

但 MQ 本身不关心：

• 成功率

• 重复执行

• 状态记录

• 人工补偿

• 集群冲突

所以：

MQ 是传送带，
任务系统是物流体系。

五、一个成熟任务系统的工程结构

1. 任务表（数据库）

典型字段设计：

任务表的作用：

让系统“记住失败”。

2. 调度器（Scheduler）

负责“什么时候执行”。

常见框架：

• Quartz

• XXL-Job

• ElasticJob

3. 执行器（Worker）

真正干活的节点：

• MQ Consumer

• 后台 Worker 服务

4. 保障机制（核心中的核心）

没有这些机制，任务系统等于“定时炸弹”。

六、为什么这是高级后端分水岭？

线上事故，80% 出在任务体系：

中级工程师写功能，
高级工程师设计“功能失败时系统还能活”。

七、学习这一体系真正要抓住什么？

不是 API，而是四种思维方式：

1. 失败必须可恢复

2. 执行必须可控

3. 任务必须可观测

4. 主链路不能被拖死

当你开始从这四个角度思考问题，你已经在向系统设计者迈进。

八、总结口诀（工程记忆版）

可以这样记：

定时负责周期，
延迟负责未来，
补偿负责后悔，
MQ负责运输，
保障负责不翻车。

任务系统的意义，不是让程序多跑几个任务，
而是让系统在失败时依然能够自己站起来。