上个月周三——一个读者私信我——"你今天的文章我邮箱收到两遍——内容一模一样——是故意的还是bug？"
我当时以为是订阅推送重复——没当回事。
周一早上翻后台日志发呆了半小时——发现了一件后背发凉的事——我那篇1500字的文章——确实被定时任务推送了两次——间隔4分17秒——分别是凌晨0:00和凌晨0:04。
凌晨0:00任务触发——开始执行——生成文章——正常情况下推送+标记完成——流程结束。但问题是——那篇推送在"标记完成"这一步之前卡了——系统在排队微信接口的返回——微信API响应延迟了——等了4分钟还没等回"推送成功"的回调。
4分钟后——系统超时——重新判断"任务未完成"——重新执行——又生成了一遍——又推了一遍。第一次推送其实成功了——只是回调慢——但系统不知道——它认为"失败了"——所以重试——结果推了两次。
两次推送导致——读者收到重复内容体验极差——配额被扣了两篇的价格——打乱了我下周的内容排期。为一个"我以为没问题"的定时任务——付出了三重代价。
定时任务的隐藏挑战
大多数人对定时任务的认知是——"设置一次——它就会自动跑——不用管"。但忽略了——"自动跑"不等于"跑得对"。至少存在三类挑战——
第一类：并发重复执行——同一任务同时跑两遍。超时重试逻辑没配好、Cron表达式触发了两次、手动触发和自动触发撞车——任何一种都导致"同一篇发两次"。
第二类：任务队列堆积——一个任务卡住后面全排队。你设了3个号×每天3篇=9个定时任务——其中一个因为AI模型响应慢卡了15分钟——后面8个任务的触发窗口顺延——最终只发出来5篇。
第三类：模型切换窗口期——新旧模型交接时断档。从模型A切换到模型B——切换期间所有排队任务"悬挂"——不知道用哪个模型执行——最终全部timeout——半小时内没有一篇发出来。
防重入：无人值守的最后一道保险
后来我才搞明白——开心果AI里有一个叫"防重入机制"的设计——就是专门防止"同一个定时任务并发执行两遍"。
一句话理解防重入——一个任务同一时间只能有一个执行"实例"——如果它已经在跑了——不管触发多少次——都不会"再开一个"。不是"允许并发"——也不是"允许失败重试"——而是——"要么正在跑——要么已经跑完——不存在正在跑的同时又触发一次"。
防重入和失败重试的区别——防重入=防止同一任务同时跑多个实例(避免发两遍)——失败重试=一个任务失败后重试执行(解决没发出去)。这两个是独立的两件事——一个完整的定时任务体系两者都需要。
双层超时——防重入的协作者。任务级超时(30分钟)：一个任务单趟执行不能超过30分钟——超过就认为"卡死了"——标记失败。系统级超时(60分钟)：一轮调度总耗时不能超过60分钟——超过后面的任务直接按本轮跳过处理——等下一轮。
上线防重入+双层超时之后——同一文章重复推送从月均1-2次降到0次——任务队列堆积导致漏发从月均2-3次降到0次——"任务被执行但我不知道"彻底消失。
无人值守不是"不管了"。很多人误会无人值守的意思——设好定时我出去玩就好了。但在你不在的时候——恰恰是系统最容易被你忽视的隐形事故发生的时候——同一个任务发了两次你不知道——有一个任务因为慢卡住了后面所有任务你不知道——你不知道。
无人值守的前提是——系统在你不在的时候——不仅能执行——还能自保。防重入、双层超时、失败重试——这些机制听起来不性感——不如13家AI厂商或20+样式方案这种直接听起来厉害——但它们是"在你不在的时候帮你盯住系统不出错的那根保险丝"。
上周能安心出去爬山一整天——回来后台告诉我说"8篇全发——0事故"——我连看都没看就信了——因为我知道——就算出了什么——系统已经在我之前处理完了。
