一、任务调度系统概述

聊任务调度之前，我先问个问题：你手头有多少个定时跑的任务？

我见过不少团队，刚开始就两三个 crontab，后来业务膨胀到几百个，每天凌晨跑批、数据同步、报表生成全挤在一起。出问题了都不知道谁先谁后。嗯，这时候你就需要一套正经的调度系统了。

1.1 什么是任务调度

说白了，任务调度就是「在正确的时间，把正确的任务，交给正确的机器去执行」。它解决的不只是定时触发，还包括依赖管理、失败重试、资源分配这些事。

我个人习惯把调度系统拆成三层来看：

• 触发层：谁来决定任务该跑了？时间到了？上游完成了？还是手动点的？
• 调度层：任务该交给哪个 worker？并发数怎么控制？优先级怎么排？
• 执行层：任务真正跑起来，日志怎么收，失败怎么处理。

这三层合在一起，才是一个完整的调度系统。很多开源产品只做了其中一两层，选型的时候要擦亮眼睛。

1.2 调度系统的核心价值

你可能会想：我用 crontab + shell 脚本不也能跑吗？

能跑，但跑不稳。我经历过一次惨痛的教训：某天凌晨三点，数据管道因为上游延迟导致下游全部空跑，第二天早上业务方发现报表全是零。那次之后我彻底明白了调度系统到底在解决什么问题。

价值维度	具体说明	没有调度系统的后果
可靠性	失败自动重试、超时中断、告警通知	任务挂了没人知道，数据对不上才后知后觉
可观测性	执行记录、耗时统计、链路追踪	出问题只能 ssh 上去翻日志，效率极低
依赖管理	DAG 编排、上下游自动触发	靠脚本里 sleep 等上游，既不优雅也不可靠
资源管控	并发限流、队列隔离、优先级调度	大任务把资源吃光，小任务饿死
运维效率	可视化配置、一键启停、批量操作	每次改个 cron 表达式都要改代码重新部署

1.3 常见应用场景

调度系统不是银弹，但下面这三个场景，我建议你直接上调度系统，别自己造轮子。

场景一：ETL 数据管道

这是调度系统最经典的战场。数据从 MySQL 抽到 Hive，清洗完再落到 ClickHouse，中间可能有十几层转换。

我曾经维护过一个 200+ 任务的 ETL 链路，最头疼的就是依赖关系。A 任务跑完 B 才能跑，B 跑完 C 和 D 可以并行，但 E 要等 C 和 D 都完成。用 DAG 图来表达这种关系，一目了然。

# 一个典型的 ETL 任务定义（伪代码）
Task: sync_order_from_mysql
  schedule: "0 2 * * *"       # 每天凌晨2点
  depends_on: []
  retry: 3
  timeout: 3600s

Task: clean_order_data
  schedule: null               # 不设时间，由上游触发
  depends_on: [sync_order_from_mysql]
  retry: 2
  timeout: 1800s

Task: load_to_clickhouse
  schedule: null
  depends_on: [clean_order_data]
  retry: 1
  timeout: 600s

场景二：定时任务

这个最直观。每天凌晨生成报表、每周一发送周报、每月初清理过期数据。crontab 能搞定，但一旦超过几十个任务，管理成本就上来了。

我见过最夸张的案例：某公司 crontab 文件有 800 多行，没人敢改，因为不知道改了会不会影响别的任务。调度系统至少给你一个 UI，能搜、能看执行历史、能灰度验证。

场景三：工作流编排

这个比定时任务复杂一些。它不一定是定时触发的，可能是事件驱动。比如用户上传文件后触发数据校验，校验通过后触发入库，入库完成再触发消息通知。

工作流编排的核心是「状态机」。每个任务有 pending、running、success、failed 等状态，调度系统根据状态转移决定下一步做什么。

我个人比较喜欢用 DAG（有向无环图）来建模工作流。为什么不能有环？因为环会导致死循环。你想想看，A 触发 B，B 触发 C，C 又触发 A，这不就死锁了吗？

1.4 什么时候该上调度系统

我总结了一个简单的判断标准：

• 任务数量超过 20 个 → 考虑上调度系统
• 任务之间有依赖关系 → 必须上调度系统
• 需要多人协作维护 → 强烈建议上调度系统
• 任务失败会影响业务 → 别犹豫，直接上

反过来，如果你就三五个定时脚本，团队也只有你一个人维护，那 crontab 完全够用。别为了用技术而用技术。