无需历史重放的持久执行

# 无需历史重放的持久化执行 来源：https://trigora.dev/blog/durable-execution-without-history-replay/ 大多数持久化执行系统通过重放保存的执行历史来恢复。当工作节点发生故障后，新的工作节点会加载历史记录并重新执行程序，直到重建出当前位置。 这是一种有效的模型。它在允许工作节点保持临时性的同时，提供了持久化进度。但它也将累积的历史记录变成了恢复路径的一部分。 对于那些运行数小时或数天、调用众多工具、等待外部事件、创建子执行并动态改变方向的程序来说，这种权衡变得尤为明显。长期运行的代理程序正日益呈现出这种特征。 我构建并评估了一种不同的恢复原语：对程序的延续进行检查点备份，而非从历史记录中重建。 ## 透明延续检查点 我将这种方法称为**透明延续检查点**，简称 TCC。 在持久化边界处，编译器和运行时会捕获活跃的延续：程序从当前位置继续执行所需的控制状态。当故障后恢复执行时，运行时会加载已提交的延续并直接恢复程序。 历史重放重建当前位置。TCC 恢复已提交的延续并继续执行。两者的区别在于： **历史重放** 加载保留的历史 → 重新执行前缀 → 重建当前位置 **TCC** 加载已提交的延续 → 恢复活跃执行状态 → 继续执行 外部效应仍然是显式的持久化操作。已完成的持久化工作在恢复后不会重复执行，而未经支持的语言结构会在编译期间失败，而不是产生歧义的运行时行为。 当前原型支持持久化效应、外部等待与事件、子执行、取消、结构化并发以及崩溃恢复。 ## 变化之处 TCC 并未使恢复成为常数时间操作。恢复时间仍然与活跃延续的大小和结构相关。 预期的变化在于恢复所依赖的对象。 采用重放方式时，恢复受为重建当前位置而保留的执行历史影响。而采用 TCC 时，恢复主要受程序仍然需要的状态影响。 一个已经执行了数万次操作但保留了较小活跃延续的程序，不应仅因其历史漫长而变得更难恢复。 ## 初步评估 我进行了一次受控比较实验，其中活跃延续状态大致固定，而持久化边界深度从 10 增加到 1000。 恢复延迟与先前持久化边界深度关系图（1ms、10ms、100ms、1s；持久化边界深度：10、100、1000） 图表标注：TCC恢复、时间重放重建、受控评估 · ~4 KB 活跃状态 在该评估中，TCC 恢复时间保持在约 0.6 至 0.9 毫秒之间。被评估的 Temporal 基准中的新工作节点重放重建时间则从约 61 毫秒增加到 1.7 秒。 该评估未包含工作节点创建时间，活跃状态约为 4 KB，这些结果不应被解释为通用的生产环境加速声明。它们展示的是在测试条件下恢复能力的扩展差异，而非每个 TCC 工作负载都将优于每个基于重放的系统。 方法论和局限性说明 (https://trigora.dev/research/recovery-vs-history) 我还在 50,000 个生成的测试用例中验证了执行语义，在评估子集中未观察到语义失败。 ## 仍然困难之处 将原型转化为生产基础设施仍然涉及大量工作： - 可移植的延续表示 - 程序和检查点版本管理 - 高效处理更大的活跃状态 - 持久化存储和提交协议 - 运维可观测性 - 跨语言前端的兼容性 - 框架集成 - 长期运行的正确性和故障测试 还有一些设计问题围绕着检查点保留、从前一个延续分支、运行时版本间的迁移，以及执行表示在多大程度上应在不同语言间保持稳定。 我正在围绕此模型构建 Trigora，最初面向长期运行的 AI 代理。更广泛的问题是，基于延续的恢复能否为动态的、长期运行的软件提供更好的执行基础。 架构、语义、基准测试设置和当前局限性在技术论文 (https://trigora.dev/research/whitepaper) 中有更详细的描述。你也可以通过当前 TCC 编译器/运行时的受控演示，查看延续恢复的实际运作 (https://demo.trigora.dev/)。 我特别欢迎来自工作流引擎、编译器、检查点系统或分布式运行时领域的工作者提出批评意见。