三层解耦：一套轻量定时 / 调度 / 批处理任务设计思想

戴维德

修改于 2026-09-03 14:07:55

232

概述

这三件事的演进速度、关注点、失败模式都不同。但很多团队习惯用一套框架（或一段 @Scheduled + 手写 SQL）把它们全塞进去，结果是：想改触发频率要动业务代码，想加依赖编排要改定时配置，想做"漏跑告警"却发现框架根本不承认"业务没跑成功"这件事。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

定时任务

批量计算

合肥同盟

腾讯云架构师技术同盟

三层解耦：一套轻量定时 / 调度 / 批处理任务设计思想
- 第 0 章 · 背景与设计动因
  - 0.1 定时任务长期被混淆的三件事
  - 0.2 现有方案的尴尬
  - 0.3 本设计的目的（一句话）
- 第 1 章 · 为什么不直接用 XXL-JOB 这类框架
  - 1.1 重量问题：只为"CRON 准时触发"引入 admin 过重
  - 1.2 语义缺口：它们保证"触发"，不保证"业务跑成功"
  - 1.3 双写隐患：任务定义散落在两处
  - 1.4 资源与编排缺失：任务维度单一
  - 1.5 结论
- 第 2 章 · 设计总览：三层解耦模型
  - 2.1 架构分层
  - 2.2 职责边界
  - 2.3 一次完整触发的链路
  - 2.4 设计原则小结
- 第 3 章 · 定时层：把"定时器"做薄
  - 3.1 放弃 XXL-JOB admin
  - 3.2 CronTriggerEngine 设计
  - 3.3 只发信号
  - 3.4 漏触发补检
- 第 4 章 · 调度层（核心）：业务级的"错过"哲学
  - 4.1 任务组与 DAG 模型
  - 4.2 核心差异化设计：cron 解析 + 反查的"应执行窗口"检测
  - 4.3 集群资源池：节点数 × CPU → 线程槽位
  - 4.4 DispatchStrategy 策略模式
  - 4.5 单节点手动发起不绕过 DAG 依赖
  - 4.6 重跑策略与状态机
- 第 5 章 · 批处理层：不重复造轮子
  - 5.1 复用 Spring Batch 5.x 的理由
  - 5.2 与调度内核的契约
  - 5.3 重跑 / 续跑 / 分批
  - 5.4 通用 Listener + 策略
- 第 6 章 · 对比分析
  - 6.1 定时框架对比
  - 6.2 调度框架对比
  - 6.3 批处理框架对比
  - 6.4 总对比（核心维度）
- 第 7 章 · 本设计的差异化优势总结
- 第 8 章 · 取舍与适用边界
- 第 9 章 · 结语

三层解耦：一套轻量定时 / 调度 / 批处理任务设计思想

三层解耦：一套轻量定时 / 调度 / 批处理任务设计思想

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐