外观
如何设计支持断点恢复的长任务工作流？
3 分钟速学卡
30 秒口述： 我会把可恢复长任务建模成持久化状态机，每个阶段保存输入哈希、版本、状态、Checkpoint、产物引用和错误分类，而不是只把函数丢进队列。恢复时从最后一个已提交且可验证的检查点继续，所有副作用使用幂等键、唯一约束或事务消息，超时结果未知时先查询或对账再重试。系统还要支持取消、心跳与租约、补偿、人工介入、进度查询和版本兼容，并通过崩溃注入证明不会重复执行或丢失任务。
- 本质： 长任务可恢复的本质是持久化状态、可验证检查点和幂等副作用。
- 核心机制： 用状态机表达合法迁移与唯一完成条件；从最后健康 Checkpoint 继续，不盲目从头重跑。
- 关键判断： 结果未知先查询或对账，再决定重试；用崩溃、重复和升级注入验证恢复语义。
- 项目落地： 故障演练：视频生成供应商已完成任务但回调丢失时，先用持久化的
provider_job_id查询和对账；确认成功就提交检查点，只有证明未创建时才重试，并通过崩溃、重复消息与延迟回调注入验证。 - 边界与坑： “用消息队列就能恢复”：队列只传递任务，不自动保存业务状态与检查点；“失败就从头重跑”：浪费成本，也可能重复不可逆副作用。
目录
面试官为什么问
这道题考察状态机、分布式一致性、幂等、恢复和可观测性，能够区分“异步执行”与“持久化工作流”。
小白先看懂
长途接力赛每一站都要签收交接棒，下一位选手只从最后签收站继续；如果签收单丢了，不能假设上一棒没跑。赛段对应工作流步骤，签收单对应 Checkpoint，接力棒编号对应幂等键，裁判核查对应结果对账。
技术上，Checkpoint 要在产物验证和状态提交后才算完成。类比没有覆盖代码升级与外部 API 结果未知，因此恢复还要绑定工作流版本，并对不可逆副作用设计查询与补偿。
主题图与核心原理
图：教学图片｜如何设计支持断点恢复的长任务工作流？
替代文本： 围绕“如何设计支持断点恢复的长任务工作流？”组织的中文教学图，通过分区、箭头和标签解释核心机制。
读图结论： 恢复不是从头重跑；副作用必须幂等或可对账。
这张图片用于建立主题机制的直觉。精确公式、参数、失败分支和事实边界仍以正文与 Mermaid 为准。
图片生成记录： model=gpt-image-2，generated=2026-07-15，prompt_version=v1，reviewed=2026-07-16，review_basis=user-confirmed；查看生成 Prompt。
图：长任务从运行到故障恢复的状态链
替代文本： 任务经过排队、运行、阶段提交和完成；崩溃后由租约检测恢复，从最后验证通过的 Checkpoint 继续，结果未知进入查询或人工处理。
图表加载中…
读图结论： 恢复不是重新跑一遍，而是从已验证的持久化状态继续，并单独处理结果未知。
状态迁移必须由单一控制层拥有；Worker 用租约和心跳避免永久占用；Checkpoint 包含工作流版本、输入哈希、产物地址和验证结果。Outbox 或事务消息用于状态与事件的一致提交。
项目和生产视角
故障演练： 视频生成供应商已完成任务，但回调在网络中丢失。若直接重试会重复扣费；正确做法是持久化 provider_job_id，超时后查询供应商状态，对账成功则提交检查点，只有证明未创建时才重新提交。
验证要在每个状态提交前后杀进程、制造重复消息、延迟回调、工作流升级和取消竞争，断言任务最终状态、产物数量、费用和审计一致。
常见错误回答
- “用消息队列就能恢复”：队列只传递任务，不自动保存业务状态与检查点。
- “失败就从头重跑”：浪费成本，也可能重复不可逆副作用。
- “Exactly-once 能解决全部问题”：跨外部系统通常依赖幂等、查询和对账语义。
递进追问
- Checkpoint 在什么时候才算提交成功？
- Worker 崩溃后如何安全接管租约？
- 结果未知与可重试错误有什么区别？
- 工作流代码升级后旧 Run 如何恢复？
- 取消与阶段完成同时发生时怎样决策？
关联阅读
总结
一句话记忆： 长任务可恢复的本质是持久化状态、可验证检查点和幂等副作用。
- 用状态机表达合法迁移与唯一完成条件。
- 从最后健康 Checkpoint 继续，不盲目从头重跑。
- 结果未知先查询或对账，再决定重试。
- 用崩溃、重复和升级注入验证恢复语义。