调度引擎核心设计：调度器架构与任务状态机
调度引擎是整个任务调度系统的心脏。说白了，它决定了你的任务什么时候跑、跑在哪、跑完怎么办。我见过不少团队，业务逻辑写得漂漂亮亮，一到调度层面就各种踩坑——任务积压、死锁、状态丢失……嗯，今天我们就来把这层硬骨头啃透。
调度器架构：中心化 vs 去中心化
先聊第一个选择题。调度器架构怎么选？我个人习惯先看场景，再拍板。
中心化调度器
一个调度中心，管所有任务。架构简单，控制力强。我在项目中遇到过一个小团队，每天跑几百个定时任务，用中心化调度器，一台机器搞定，运维成本极低。
核心特征：
- 单点调度，全局状态一致
- 任务分配由中心节点决策
- 适合中小规模（节点数 < 50）
但要注意——中心化不是银弹。我曾经接手过一个系统，调度中心挂了，整个生产线停摆。那叫一个惨。所以如果你选中心化，必须做好高可用：主备切换、持久化队列、健康检查，一个都不能少。
去中心化调度器
每个节点都是调度器，通过共识协议协调。你想想看，几百个节点同时调度，谁抢到谁跑。这听起来很酷，但复杂度也上去了。
我的建议：如果任务量超过每天百万级，或者节点分布在多个机房，去中心化是更好的选择。但要做好分布式锁和脑裂防护。
我曾在某大厂见过一个去中心化调度系统，每个节点都维护一份任务队列，通过 Raft 协议同步。好处是单节点挂了不影响全局，坏处是——调试起来想骂人。日志满天飞，一个任务被两个节点同时执行的情况，我至少排查过三次。
| 维度 | 中心化 | 去中心化 |
|---|---|---|
| 一致性 | 强一致，单点决策 | 最终一致，需共识 |
| 扩展性 | 受限于中心节点 | 水平扩展，无瓶颈 |
| 运维复杂度 | 低，一台搞定 | 高，需维护集群 |
| 典型场景 | 中小规模定时任务 | 大规模、跨机房调度 |
调度队列设计
队列是调度器的缓冲区。设计不好，任务堵死、优先级反转、OOM……我全踩过。
队列选型
我个人习惯分三层：
- 内存队列：高性能，但掉电丢失。适合短任务、高频调度。
- 持久化队列：基于数据库或消息队列（如 Redis List、Kafka）。保证不丢任务。
- 延迟队列：用于定时调度。我常用 Redis ZSet + 轮询，简单可靠。
避坑指南：我曾经用纯内存队列做生产调度，一次机房断电，3000 多个待执行任务全部丢失。从那以后，我坚持至少做一层持久化兜底。
优先级与公平调度
任务不能一视同仁。我习惯给每个任务打一个优先级标签（P0/P1/P2），队列内部按优先级排序。但要注意——优先级反转。低优先级任务占着资源不放，高优先级任务干等。解决方案？我一般用优先级继承或临时提升。
// 伪代码：优先级队列调度
class PriorityQueue {
private Queue<Task>[] queues; // 按优先级分桶
Task poll() {
for (int i = MAX_PRIORITY; i >= 0; i--) {
if (!queues[i].isEmpty()) {
return queues[i].poll();
}
}
return null;
}
}
任务状态机
状态机是调度器的灵魂。状态乱了，整个系统就废了。我见过最离谱的案例——一个任务同时处于 Running 和 Success 状态，排查了一整天，发现是状态更新没加锁。
四态模型
标准的状态机就四个状态：Pending → Running → Success / Failed。但实际项目中，我一般会加两个中间态：
- Pending：任务已提交，等待调度
- Running：任务正在执行
- Success：执行成功
- Failed：执行失败
- Retrying：失败后重试中（我加的）
- Cancelled：手动取消（也是我加的）
状态转换规则（硬约束）：
- Pending → Running：唯一合法入口
- Running → Success / Failed：执行结束
- Failed → Retrying：重试策略触发
- Retrying → Running：重新调度
- 任何状态 → Cancelled：人工干预
你想想看，如果没有 Retrying 这个中间态，失败后直接回到 Pending，那重试次数怎么算？重试间隔怎么控制？所以，状态机设计一定要贴合实际业务。
状态持久化与幂等
状态必须持久化。我习惯用数据库记录状态变更历史，每次状态切换都写一条日志。这样即使调度器重启，也能从数据库恢复。
小技巧：状态更新用乐观锁（版本号或 CAS），避免并发覆盖。我曾经用悲观锁，结果死锁频发，改成乐观锁后世界清净了。
-- 状态更新 SQL（乐观锁）
UPDATE task SET status = 'Running', version = version + 1
WHERE id = ? AND version = ?;
核心逻辑流程图
下面这张图，是我自己画的状态机流转图。你看一眼就能明白整个调度流程。
总结几个关键点
- 架构选型：小规模用中心化，大规模用去中心化。没有银弹。
- 队列设计：内存+持久化双层兜底，优先级队列防饥饿。
- 状态机：四态是基础，加 Retrying 和 Cancelled 更实用。状态更新必须幂等、加锁。
嗯，调度器这块内容不少，但核心就这些。你先把状态机画清楚，队列设计好，架构选对，剩下的就是填坑了——不过别怕，坑踩多了，你就是专家。