Go应用超时灾备：本地持续存时触发宕机期间超时的方案咨询

方案合理性 #

这个思路是可行的，核心逻辑是通过记录「最后完成任务处理的时间点」，在重启后把宕机期间本该触发的任务一次性补跑，能直接解决你现在遇到的任务遗漏问题。而且实现成本低，不需要引入复杂的中间件，适合中小规模的任务调度场景。

潜在问题 #

• 高频写入的性能开销：每秒写入文件或SQLite会持续产生IO消耗，尤其是SQLite，频繁写入可能触发锁机制，阻塞其他数据库操作，影响应用整体性能。
• 系统时间波动风险：如果服务器时间被手动修改、或者NTP同步出现大幅跳变，会导致时间窗口计算错误，要么重复触发任务，要么漏掉本该处理的任务。
• 任务重复执行问题：如果应用刚写完时间戳，还没处理完对应时间的任务就崩溃了，重启后会再次触发这段时间的任务，所以你的任务必须具备幂等性，否则会出现重复执行的副作用。
• 批量触发的负载压力：如果宕机时间很长（比如几小时），重启后会一次性触发大量积压任务，瞬间拉高应用CPU、内存占用，甚至直接压垮应用。
• 时间戳记录的一致性问题：文件写入可能因为断电、磁盘故障出现损坏，SQLite如果没正确用事务包裹写入操作，也可能出现时间戳记录不完整的情况，导致补偿窗口计算出错。

模式名称 #

这个属于任务补偿（Task Compensation）的具体实现，更细分的话可以叫基于时间点的回放式任务恢复。它有点像简化版的事件溯源，但事件溯源通常会记录所有事件本身，而你只记录时间点，通过时间窗口来补全遗漏任务。

内容的提问来源于stack exchange，提问作者Absurdev