共计 1391 个字符，预计需要花费 4 分钟才能阅读完成。
在上一节中，我们引入了时间维度的任务调度，使异步系统能够管理“未来要做的事情”。但随之而来的一个现实问题是：如果系统在任务尚未完成时崩溃或重启，这些任务该怎么办？ 本篇将系统讲解异步系统中极其关键、却常被低估的一项能力——任务恢复与容错设计。
一、为什么“可恢复性”是工程系统的底线
在真实运行环境中，以下情况一定会发生：
- 进程重启
- 服务发布
- 机器宕机
- 运行时异常
如果系统重启后“忘记了一切”，那么：
- 延迟任务会丢失
- 正在执行的任务状态不明
- 数据一致性被破坏
因此，一个工程级异步系统必须满足一个最低要求：
系统可以重启，但任务不能消失。
二、任务恢复的核心前提：状态必须持久化
任何想要“恢复”的系统，都必须先回答一个问题：
系统重启后，从哪里知道有哪些任务？
答案只有一个：
关键任务状态必须持久化到进程外部存储。
常见持久化介质包括：
- 数据库（MySQL / PostgreSQL）
- Redis（队列 / 有序集合）
- 分布式 KV
进程内存，只能作为缓存，不能作为事实来源。
三、任务持久化的最小模型
一个可恢复任务，至少需要保存以下信息：
- task_id
- 当前状态
- 执行参数
- 下一次可执行时间（如有）
- 重试次数
示例任务记录结构：
task_record = {
"task_id": "t123",
"payload": {"user_id": 1},
"status": "pending",
"retry": 1,
"run_at": 1700000000
}
这类结构，既可存储在数据库中，也可序列化存入 Redis。
四、系统启动时的任务重建流程
系统启动后的第一件事，不是接收新任务，而是 恢复旧任务。
一个典型流程包括：
- 从存储中加载未完成任务
- 根据状态重新入队
- 修正异常中断的状态
示例伪代码：
async def recover_tasks(storage, scheduler):
tasks = await storage.load_unfinished()
for task in tasks:
if task.status == "running":
task.status = "pending"
await scheduler.add(task)
这一过程确保：
- 崩溃前正在执行的任务不会永久丢失
- 系统可以“接着上次的事情继续做”
五、处理中断任务的工程策略
对于状态为 RUNNING 的任务，工程上通常采用保守策略：
- 假设其未完成
- 回退为 PENDING
- 重新调度执行
这与前文提到的幂等性设计形成闭环：
只有幂等任务，才具备安全恢复的前提。
六、避免“重复执行恐慌”
很多工程师对任务恢复最大的担忧是：
会不会重复执行任务？
正确的工程答案是：
重复执行是可接受的，不可控丢失才是不可接受的。
通过以下手段，可以将重复执行风险降到可控范围：
- 幂等操作
- 去重校验
- 状态原子更新
而试图“绝不重复执行”，往往会导致系统复杂度和故障概率急剧上升。
七、任务恢复与调度系统的协同
任务恢复不是独立模块，而是调度体系的一部分：
- 恢复任务 → 重新进入队列
- 延迟任务 → 保留原 run_at
- 优先级任务 → 恢复原优先级
这要求任务模型在设计之初就具备足够的表达能力。
八、从“程序健壮”到“系统韧性”的跃迁
到这一阶段，你的系统已经具备一个重要特质：
韧性（Resilience）。
它意味着：
- 系统允许失败
- 系统能够恢复
- 系统在长期运行中保持连续性
这正是工程系统与脚本程序之间的本质差异。
下一篇，我们将站在更高层面继续推进：
异步系统中的容量评估与压测思维——系统上线前你必须知道的极限在哪里。
