Python定时任务失败后的补救方法

定时任务中断后需靠持久化状态+主动检查补偿，APScheduler需换SQLAlchemyJobStore并设coalesce=True和足够misfire_grace_time，Celery定时任务需显式配置autoretry_for，schedule须加循环执行run_pending()，所有补偿必须与幂等设计结合。

任务没跑完就被杀掉，怎么补救

Python 定时任务（比如用 APScheduler 或 schedule 库触发的）一旦被强制终止（如进程被 kill -9、容器重启、服务器断电），就彻底丢失上下文——它不会自动重试，也不会记住“该在 10:00 跑但没跑成”。补偿不是靠定时器本身，而是靠外部状态记录 + 主动检查。

• 必须把“是否已执行”这个状态存到持久化介质里，比如数据库某张表的 last_run_at 字段或 Redis 的 task:send_email:latest 键
• 每次任务启动前，先查这个状态：如果距离计划时间已超阈值（比如 5 分钟），且状态显示未完成，就主动执行一次补偿逻辑
• 避免重复执行：更新状态要和业务逻辑放在同一个事务里（DB）或用 Lua 脚本（Redis），否则可能写入成功但业务失败，下次又补

APScheduler 挂了之后怎么续上错过的 job

APScheduler 默认不保存 job 执行历史，MemoryJobStore 一崩全丢。想让它“记得”错过什么，得换存储 + 开启 misfire 处理。

• 改用 SQLAlchemyJobStore，并确保数据库连接稳定；jobstore 配置里必须设 coalesce=True，否则多个错失触发点会被合并成一次
• 每个 job 的 misfire_grace_time 参数不能设太小（比如默认 1 秒），否则刚启动就发现“3 分钟前该跑的没跑”，直接丢弃；建议设为 60（秒）以上
• 注意：APScheduler 不会回溯执行“所有错失的”，只执行“最近一次错失的”——它没有队列语义，别指望它补 10 次

用 Celery 做定时任务时，failed task 怎么自动重试

Celery 的 apply_async 支持重试，但定时任务（beat）发出去的 task 如果失败，默认不重试，除非显式配置。

• 在 task 函数上加装饰器参数：@app.task(autoretry_for=(Exception,), retry_kwargs={'max_retries': 3, 'countdown': 60})
• 更稳妥的做法是：把定时触发逻辑和实际执行逻辑拆开，定时器只发一个“调度 task”，它再调用真正的业务函数，并自己捕获异常+记录失败；这样失败可进监控，也能人工干预
• 别依赖 retry 处理数据库连接失败等临时问题——如果 broker（如 RabbitMQ）本身不可用，task 根本发不出去，重试也没用

本地开发时 schedule.run_pending() 不生效的常见原因

很多人写完 schedule.every().hour.do(job) 就以为万事大吉，结果发现 run_pending() 从不执行——根本原因是它只跑一次，不阻塞也不循环。

• 必须手动加个死循环：while True: schedule.run_pending(); time.sleep(1)，否则脚本执行完就退出
• 如果用了 threading 启另一个线程跑这个循环，注意主线程别提前结束（比如没 join），否则子线程被强杀
• Windows 下某些 IDE（如 PyCharm）调试时，time.sleep() 可能被中断，导致循环卡住；换成 time.sleep(0.5) 更稳