solo 后端的定时任务设计：cron + 数据库表的最小集

背景与问题

后端一有数据就开始需要定时任务（每日汇总、到期检查、通知分发）。引消息队列对 solo 是过度工程。调研「cron + 数据库表」模式的最小设计：幂等、重试、失败可见三件事怎么做。

发现

（来源访问日期均为 2026-09-17）

• 事实（koder.ai 2026-01）：cron + 数据库 job 表即可实现带重试、锁定、幂等的后台任务——不需要独立队列系统，单人团队的现实模式。
• 事实（JobRunr 解说 2025-01）：幂等（idempotence）=同一任务执行多次也不改变首次执行之后的状态——后台任务设计的第一原则。
• 事实（生产强化清单 2026-06）：假设任务一定会跑两次来设计；重试用指数退避+封顶次数；耗尽重试的任务进 dead-letter 表；「you can't fix what you can't see」——可观测性不可省。
• 事实（Raff Technologies 2026-05）：引入队列的代价=workers、broker 可用性、队列深度、重试策略、重复执行——solo 没必要背这些。
• 推测：solo 后端的定时任务事故几乎全部来自两个坑——非幂等导致的重复执行副作用与静默失败（没人发现任务没跑）。设计目标就是把这两个坑堵死，其余从简。

结论

1. job 表 schema：id / name / run_at / status（pending-running-done-failed-dead）/ attempts / locked_by / last_error。cron 每分钟扫一次 pending 且到期的行，CAS 抢锁后执行。
2. 三条铁律：①每个任务写成幂等（用业务键去重：如「已给 user X 发过今日提醒」）②重试指数退避、上限 3 次，耗尽进 dead 状态 ③dead 状态有任务就通知（Workers 端点或邮件）——静默失败是最大敌人。
3. 与 opc-edge-api-workers 组合：HTTP 服务 + D1 job 表 + Cron Triggers（Workers 原生 cron），全套仍在免费档内。
4. 任务粒度从大拆小：一个「每日汇总」拆成「读数据→算指标→写表→发通知」可重入的小步——某步失败只重跑那步。

待办 / 下次继续

• 现有定时脚本盘点，检查是否幂等（重点：通知类）。
  
• job 表 + dead 通知的最小实现（Workers Cron 试做）。
  

关联

opc-edge-api-workers opc-external-uptime-monitoring opc-monitoring-basics-solo