分布式定时任务系统设计：调度、防重与补偿的完整方案

crontab 跑不动的三个信号

单机 crontab 在业务长大后必然崩溃，触发信号有三个：任务执行时间开始超过调度周期（上一轮没跑完下一轮又启动）、多机部署后同一任务重复执行（每台机器都有 crontab）、任务失败没人知道（静默失败累积成数据事故）。分布式调度系统（XXL-Job、Elastic-Job、TCT 类）解决的就是这三件事：调度中心统一触发、执行器集群分片、失败告警与重试。一、架构分层：调度中心与执行器分离

1. 调度中心（中心化）：维护任务元数据（cron 表达式、执行器路由策略、超时时间、失败策略），到点触发——只做调度不做业务，保持无状态可 HA（DB 锁或 Raft 选主防双调度）；
2. 执行器（业务侧）：注册到调度中心，接收调度执行业务逻辑——自动注册发现、心跳摘除故障节点；
3. 通信与幂等：调度消息至少一次送达，执行器必须幂等（任务实例 ID 去重）——「调度中心认为成功」与「任务真正执行」之间的缝隙靠幂等填上。

二、防重设计：三层防线

1. 调度层防重：调度中心对同一任务同一触发周期只调度一次——DB 行锁或唯一约束（任务 ID + 触发时间戳）兜底，即使调度中心主从切换也不双发；
2. 执行层防重：执行器收到调度请求先查「任务实例表」（唯一键：任务 ID + 批次时间），已存在直接返回成功——网络重试导致的重复调度在这一层被消化；
3. 业务层防重：任务内部写操作按业务键幂等（参照幂等设计三板斧）——前两层都失效（如手工触发两次）时业务数据仍然正确。

三、分片与路由：大数据量任务的水平扩展

百万级数据量的批处理任务（如账单生成），单机执行要几小时——用分片广播：调度中心一次触发，所有执行器都收到，每个执行器按「分片总数 + 分片序号」处理自己的那一片（id % shardTotal == shardIndex）。要点：分片键分布要均匀（哈希取模前先验证数据分布）；执行器扩缩容时分片数变化，任务要支持按新分片数重跑（幂等保证重跑安全）。

四、失败处理：重试、告警与补偿

1. 重试策略：失败自动重试 N 次（间隔递增），重试期间任务状态对用户可见——注意重试也要幂等；
2. 超时与杀死：任务执行超时主动终止（防线程泄漏），被杀任务标记失败进重试或人工队列；
3. 告警分级：核心任务（账务、结算）失败立即电话告警；一般任务钉钉/企微群通知——告警必须附带「任务名 + 失败原因 + 影响范围 + 重试状态」四要素；
4. 人工补偿通路：所有任务支持按时间区间手动重跑——故障恢复后的数据补齐是运维刚需，没有这个通路每次故障都要写一次性脚本。

五、可观测性

任务视图三件套：今天该跑的任务跑完没有（调度成功率）、每个任务耗时趋势（变慢预警）、失败任务的积压队列。定时任务系统的故障模式是「静默」——观测做不好，问题都是业务方先发现。

定时任务系统的成熟标志：任何一台执行器宕机任务照常跑、任何一次调度失败 10 分钟内有人知道、任何一天的数据漏跑能一键补齐。这三句话做到，批处理链路就是生产级的。