1. 调度系统概述

大家好，我是你们这门课的老朋友。今天咱们聊聊任务调度——这个听起来有点枯燥，但实际工作中天天都要打交道的东西。

说实话，我刚开始工作时对调度系统也没什么概念。那时候写个定时脚本，crontab 一配就觉得完事了。直到有一次线上数据没按时跑出来，老板半夜打电话问我怎么回事……嗯，从那以后我才真正开始认真研究调度系统。

什么是任务调度

任务调度，说白了就是让计算机按照我们设定的规则，自动去执行一系列任务。你想想看，一个典型的数据平台，每天可能要跑几百上千个任务——数据抽取、清洗、计算、报表生成……如果全靠人工去点，那得累死人。

任务调度要解决三个核心问题：

• 什么时候执行——定时跑还是触发跑
• 谁先谁后——任务之间有依赖关系，不能乱序
• 失败了怎么办——重试、告警、补偿机制

调度系统的演进历史

我经历过调度系统的几个阶段，每个阶段都有它的时代背景。

阶段	代表技术	特点	痛点
手工脚本时代	crontab、Windows 任务计划	简单直接，单机执行	无依赖管理，无监控，单点故障
集中调度时代	Quartz、Control-M	中心化调度，支持简单依赖	扩展性差，配置复杂
分布式调度时代	Azkaban、Oozie、Airflow	DAG 编排，分布式执行	运维成本高，学习曲线陡
云原生调度时代	DolphinScheduler、Argo Workflows	容器化，声明式，高可用	生态仍在完善中

我记得在手工脚本时代，有个项目用了 200 多个 crontab 任务。每次加新任务都要小心翼翼，生怕跟已有的任务冲突。后来有一次磁盘写满了，几十个任务同时失败，排查了整整一个下午……

常见的调度模式

调度模式主要有三种，我分别说说。

定时调度

这是最基础的模式。指定一个时间点或时间周期，到点就执行。比如每天凌晨 2 点跑数据、每小时同步一次日志。

# crontab 示例：每天凌晨 2:30 执行数据清洗
30 2 * * * /usr/local/bin/clean_data.sh

# Quartz Cron 表达式：每 5 分钟执行一次
0 0/5 * * * ?

定时调度的问题在于——它不管任务是否真的准备好了。比如上游数据还没到，下游任务到点就执行，结果跑了个寂寞。

事件驱动调度

事件驱动就不一样了。它不依赖时间，而是依赖某个"信号"。这个信号可以是文件到达、消息队列里的消息、API 回调等等。

我在项目中遇到过这样一个场景：每天有几十个数据源通过 FTP 上传文件，上传时间不确定。如果用定时调度，要么设一个很晚的时间（浪费等待时间），要么设多个时间窗口（容易漏掉）。后来改成事件驱动——文件一落地就触发处理流程，问题迎刃而解。

DAG 依赖调度

这是现代调度系统的核心模式。DAG（有向无环图）把任务之间的依赖关系画成一张图——箭头从上游指向下游，下游必须等上游全部完成后才能开始。

举个例子，一个典型的数据 pipeline：

数据采集 ──→ 数据清洗 ──→ 数据聚合 ──→ 报表生成
                │
                └──→ 异常检测 ──→ 告警推送

这个 DAG 里，数据清洗完成后，数据聚合和异常检测可以并行执行。报表生成要等数据聚合完成，告警推送要等异常检测完成。DAG 调度器会自动处理这些依赖关系，不需要人工干预。

我个人习惯用 DAG 来管理所有有依赖关系的任务。原因很简单——它把复杂的依赖关系可视化出来了，出了问题一眼就能看出是哪个环节卡住了。

三种模式不是互斥的。实际项目中经常混合使用——定时调度兜底，事件驱动做实时触发，DAG 管理复杂依赖。比如我最近做的一个数据平台：

• 核心数据 pipeline 用 DAG 编排
• 实时告警用事件驱动
• 每天凌晨的全量备份用定时调度