凌晨 0 点的 47 个定时任务撞在一起：一次整点批处理把 MySQL P99 打到 2.3s 的错峰复盘

结论先行：批处理事故里最隐蔽的一种，不是"某个任务写错了"，而是"一堆各自都没问题的任务，被塞进了同一个整点"。它们单独看每个都很快，叠在一起却把共享的磁盘 IO 打穿。这篇文章给一份我能直接抄的"错峰 + 闸门"做法。

一、现象：00:00 到 00:08，MySQL 像被人抽了筋

先交代规模。我们一套账务 + 对账系统，跑在 3 台调度节点（自研调度器，每个节点独立跑 cron）上，连同一个 MySQL 8.0.32（8C16G，innodb_buffer_pool_size=16GB）。后台挂着 47 个定时任务：对账、清结算、账单归档、报表、缓存预热、日志切割……

问题就出在这里——47 个任务里，有 30 多个的 cron 表达式都是 0 0 0 * * ? 或某个整点。于是每天凌晨 0 点，3 台机器 × 三十多个任务，几乎在同一秒集体点火。

那次事故的数据：

• 00:00–00:08 期间，数据库 io_util 从平时的 12% 一路顶到 98%；
• 慢查询从平时 3 条/分钟飙到 210 条/分钟；
• 在线接口 P99 从 14ms 抖到 2.3s，持续 6 分 40 秒；
• 其中一个"清结算"任务，平时 6 分钟跑完，那天跑了 41 分钟，原因是它和"账单归档"任务在 t_settle 表上互相锁等待；
• 更糟的是，归档那条 DELETE 大事务把 InnoDB history list length 顶到了 19 万，拖慢了后面 20 分钟的所有写入。

监控里所有 CPU、连接数曲线都"看着还行"，唯独 IO 和锁等待在尖叫——这就是"撞车"故障的典型指纹。

二、根因：整点聚集 + 多机放大，两个乘数叠在一起

把这件事拆成两个乘数，机制就清楚了：

乘数一：整点聚集。 人写 cron 有个本能——"定时任务嘛，就定在整点最干净"，于是 0 0 0、0 30 0、0 15 0 满天飞。单个任务几十秒就完了，可 30 多个任务同时抢同一块磁盘的 IO 带宽，就像早高峰所有车都挤进同一条车道——每辆车都没超速，但整条路堵死。IO 是共享瓶颈，不是 CPU，所以你会看到"CPU 不高、延迟却爆炸"。

乘数二：多机放大。 我们有 3 台调度节点，每台都独立跑同一批 cron。你以为错峰了，其实没——3 台机器在 00:00 各自点火，流量直接 ×3。这是最容易被忽略的一点：多机部署时，错峰之前必须先回答"这个任务到底该由谁跑"，否则单机错峰毫无意义。

两个乘数相乘，就是那 6 分 40 秒的 P99 抖动。

三、具体做法：确定性槽位 + 集中调度 + 重任务闸门

下面是我落地后稳定了半年的三件套，都能复现：

1. 把"整点"改成"确定性槽位"，别用随机数。 随机 sleep(0, 59s) 看着省事，但 47 个任务里随机到同一秒的概率不低（生日悖论），而且不可复现、没法排查。我改成按任务名做稳定 hash，把每个任务钉在一个确定的分钟槽上：

// 任务入口统一拦截，按名称确定性错峰
int minute = Math.abs(taskName.hashCode()) % 60;
// 重任务再整体推到业务低峰窗口 02:00 起，轻任务留在 00:00 窗口
cron = heavy ? "0 " + minute + " 2 * * ?" : "0 " + minute + " 0 * * ?";

好处：taskName 不变，槽位就不变——出问题时你能精确说出"这个任务固定占第 23 分钟"，而不是"它大概在那儿晃"。

2. 集中调度，掐掉多机放大。 把 3 台各自独立触发，改成 1 个调度中心（XXL-Job / Quartz cluster）+ executor 分片：调度中心统一决定"哪个任务、由哪台执行、几点几分"，executor 只负责执行。47 个任务的"谁该跑"从此只有一个答案，×3 的放大直接消失。

3. 重任务加"闸门"串行，别让两个大事务对撞。 对账、归档、清结算这种会扫大表、拿长锁的重任务，用一张闸门表强制串行：

CREATE TABLE t_task_gate (
  gate_name  VARCHAR(64) PRIMARY KEY,
  holder     VARCHAR(64),
  expire_at  DATETIME
) ENGINE=InnoDB;

-- 任务开始前抢闸门：只有抢到的实例才执行
INSERT INTO t_task_gate (gate_name, holder, expire_at)
VALUES ('settle', 'node-02', NOW() + INTERVAL 30 MINUTE)
ON DUPLICATE KEY UPDATE
  holder = IF(expire_at < NOW(), VALUES(holder), holder),
  expire_at = IF(expire_at < NOW(), VALUES(expire_at), expire_at);

闸门带 expire_at 兜底，防止持锁节点宕机后把任务永久锁死。

四、踩过的坑，以及几个反直觉的点

• "每个任务单独看都很快"是错觉。 47 个任务每个 20–60 秒都正常，但它们共享的是 IO 带宽这条"独木桥"。排查时我一度去调 innodb_purge_threads、加内存，全没救——瓶颈在"大家同时抢"，不在"谁抢得慢"。
• 随机错峰会自己撞。 47 个任务 random(0,59)，算下来同一分钟撞个三四次很常见。确定性 hash 槽位既错峰又可复现，是我最大的收获。
• 错峰 ≠ 削峰。 一开始我把 12 个重任务全挪到 02:00，结果 02:00 又成了新的"整点事故"。正确姿势是按"单位时间的 IO 预算"来排：先估每个重任务的 IO 量，再保证任意 10 分钟窗口内的重任务 IO 之和不超过磁盘峰值的一半。
• 多机不先收敛，单机错峰白做。 我们第一版只改了 cron，P99 还是抖——因为 3 台机器各改各的，等于错峰了 3 份、撞了 3 次。先上集中调度，错峰才真正生效。

五、结论与可复用清单

批处理撞车是"叠加型"故障，单点优化救不了它。可复用清单：

1. 盘点：把所有 cron 按"分钟槽 × 时段"画一张 0–6 点密度热力图，一眼看出哪个整点最挤；
2. 确定性错峰：用 hash(taskName) % 60 把任务钉在固定分钟槽，别用随机；
3. 集中调度：多机部署先解决"谁跑"，掐掉 ×N 放大，再谈错峰；
4. 重任务闸门：扫大表、拿长锁的任务用 t_task_gate（带 expire_at）强制串行；
5. 按 IO 预算排期：错峰不是把任务堆到另一个整点，而是保证任意窗口的重任务 IO 之和低于磁盘峰值一半；
6. 可观测：给每个任务埋"开始时间 / 耗时 / 影响哪些表"，并把 io_util、慢查询速率、history list length 作为"撞车"的早期信号。

一句话收尾：别让 47 辆车同时挤 00:00 那条车道——给每辆车一个固定车位，重车走专用匝道，再派一个调度员统一放行。