持久化 APScheduler 代理调度

后台代理的定时任务经常死在重启后：cron 表达式写在代码里，进程一停，下一次触发就没了；间隔任务在服务器滚动发布时被清空；日历任务因为机器休眠而错过。这个问题本质上是把调度状态放到了内存里，只要进程消失，调度器知道的一切都消失。

它解决的具体问题

这个技能针对的是 Python 代理的持久化调度：

• 用 interval 做固定间隔任务，间隔抖动支持 jitter
• 用 cron 做周期任务，适合每天清理、每小时拉取等
• 用日历触发器做特定日期的任务，比如月末结算
• 用一次性任务（date）做延迟触发，比如等待外部审批
• 用持久化 job store 让任务定义和下一次运行时间落到外部存储

持久化之后，重启不会清空调度器状态。调度器恢复时会从 job store 里读回任务，并计算下一次触发时间。对于按小时跑批的代理、夜间数据同步、周期性代理对话，这就避免每次上线都要手动补跑。

它如何工作

技能基于 APScheduler，通常有几个关键步骤：

• 选择持久化 job store：SQLite 适合单文件本地任务，PostgreSQL、MySQL、MongoDB、Redis 适合多实例；MQTT 也可用于外部触发
• 注册任务：把 Python 代理的入口函数交给调度器，并声明 interval、cron、日历或一次性触发器
• 启动调度器：调度器启动后从 job store 加载未完成的任务，继续排程
• 加入 jitter：给定时任务加随机抖动，避免多个代理在同一时刻一起压到下游 API
• 可选 Python web 运行时：把调度器挂到服务里，让任务随应用一起运行

这里能持久化的是 调度状态，不是任务执行结果本身。你在任务函数里做的事情仍需自己写日志、重试或幂等保护。

适用边界与注意点

• APScheduler 可以当任务队列用，但它不会替你重新执行跑到一半的业务逻辑
• 任务函数要尽量幂等：调度器恢复后可能立即触发一次，也可能因为错过时间而补触发
• 如果 job store 和代码模型不匹配，升级时要处理字段迁移
• 多实例部署时，注意避免多个调度器同时写同一个 job store
• 不要在任务里做长时间阻塞 I/O，否则会拖慢调度线程