定时任务上生产才会袒露的六个问题

给系统加定时任务，第一反应是找个 cron 库，写个表达式，跑起来。
能跑通。然后在某个凌晨，你会发现任务执行了两次，或者一次都没执行，或者上一次还没跑完下一次就开始了。
下面是几个跑到生产上才会袒露的问题。
一、多实例部署，任务会被执行 N 次

本地和单机上完全正常，一上负载均衡、服务扩到三个实例，每个实例里的 cron 都在跑，同一个任务同一时刻执行三次。
如果这个任务是「给用户发提醒邮件」，用户就收到三封。如果是「结算昨天的账单」，那就是事故。
常见的几种解法：
做法适合代价只在一台呆板上开定时任务小规模、任务不重要那台挂了任务就停了分布式锁（Redis / etcd）大多数场景要处理锁过期和续期数据库唯一键抢占已有数据库、不想引中心件并发高时有竞争开销专门的调度中心任务多、需要可视化引入额外系统的运维成本分布式锁是性价比最高的，但有个细节容易漏：锁的过期时间必须大于任务的最长执行时间，否则任务还没跑完锁就没了，另一个实例又抢到了。 而任务耗时往往是不可预测的，所以更稳的做法是加续期。
二、任务重叠

配置成每分钟执行一次，但某次执行花了三分钟。
多数 cron 库的默认活动是到点就起新的，不管上一次跑没跑完。于是三个实例在同时操作同一批数据。
这个问题和上面的多实例是两回事，单机也会发生。解决方式是给任务加一个「正在运行」的状态标记，新的一轮先检查，在跑就跳过（或者排队，看业务语义）。
跳过还是排队要想清楚：清理类任务跳过没事，结算类任务跳过就漏账了。
三、时区和夏令时

cron 表达式里的时间，是按哪个时区解释的？
库的默认活动通常是跟随服务器本地时区。容器里 TZ 没设的话多半是 UTC，于是你配的「每天凌晨 2 点」现实在北京时间上午 10 点执行。
这个错误的潜伏之处在于：它不报错，任务也确实在跑，只是时间不对。而且本地开发机时区是对的，只有线上不对。
中国区不用考虑夏令时，但如果业务涉及海外，「每天 2:30」这个时间点在切换夏令时那天可能不存在，或者存在两次。
四、服务重启期间错过的任务

进程在 2:00 整重启，恰好跨过了任务时间点，这次执行就丢了。cron 库不会补。
需要不需要补执行，取决于业务：

• 缓存预热、健康检查这类：漏一次无所谓，下次再跑
  
• 日闭幕算、数据归档这类：必须补，而且要能查出漏了哪些
  

要能补，就得把任务的执行记录落库——预期执行时间、现实执行时间、结果。启动时扫一遍有没有该执行但没记录的。这一层往往是自己写的，标准 cron 库不提供。
五、异常会静默吃掉整个调度器

这条最容易埋雷。
部分 cron 库的实现里，任务函数里抛出的异常如果没被捕获，会导致整个调度 goroutine 或线程退出——后果不是这一个任务失败，是从此以后所有定时任务都不再执行，而且没有任何告警。
往往是几天后有人问「怎么报表没生成」才发现。
所以每个任务的入口都应该包一层规复逻辑，捕获异常、记日志、继续调度。这个不能指望库帮你做，得自己在注册任务时统一包装。
六、没有可观测性

任务跑了没有、跑了多久、成功还是失败——如果这些信息只存在于日志里，那现实上等于没有。
最低限度应该记录：上次执行时间、耗时、结果、连续失败次数。有了这四个，才能配告警。
「连续失败次数」尤其重要：偶尔失败一次可能是网络抖动，连续失败三次就是真出问题了。
说点做不到的

cron 不包管准确到秒。 调度器有自己的扫描间隔，呆板负载高的时候延迟几秒很正常。需要准确触发的场景不应用 cron。
表达式不适合表达复杂规则。 「每月最后一个工作日」「法定节假日不执行」这类，cron 表达式写不出来，只能在任务内部再判断一次。许多人试图用复杂表达式硬怼，结果写出没人看得懂也没人敢改的东西。
任务之间的依赖 cron 管不了。 「A 跑完再跑 B」用两个 cron 错开时间来实现是脆弱的——A 慢了 B 就读到脏数据。有依赖关系的应该用工作流编排，不是定时任务。
最后

定时任务的复杂度几乎全在「它没按预期跑」的那些情况里，而这些情况在开发环境基本不会出现。
上线前值得问自己四个问题：多实例会不会重复跑、上一次没跑完怎么办、异常了会不会把调度器带死、跑没跑我怎么知道。
这四个想清楚了，剩下的就是写表达式。
我在 forxi.cn 上做了个在线的定时任务工具，主要是给不想自己搭一套的场景用的，能力上肯定不如专业调度系统，胜在打开就能配。

免责声明：如果侵犯了您的权益，请联系站长及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金.