2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
一篇题为“持久化执行只需 Postgres 即可”的 DBOS 博客文章本周登上了黑客新闻（Hacker News）首页（306 分，132 条评论）。该讨论帖像往常一样出现了两极分化。一半读者将其视为一种解脱：不再需要单独部署工作流服务来确保多步骤任务在崩溃后能够继续运行。另一半读者则将其视为警告：你即将把编排负载施加到已经运行你的应用程序的同一个数据库上。这两种反应都是正确的，而哪一种适用于你，取决于标题中忽略的一个问题。
我运营着一个比较开发者工具的网站，因此阅读了大量的“X 与 Y 对比”类文章。在持久化执行这一类别中，架构选择的重要性远超产品品牌本身。以下是基于事实的版本，内容已对照 DBOS 官方文档、Supabase 的独立文章以及源代码库进行了核实。
持久化执行解决的问题
想象一个包含五个步骤的函数在第四步崩溃了。第一步到第三步已经完成，第四步完成了一半，而简单的重试机制会重新运行所有五个步骤。如果第二步涉及向客户收费，那么客户就会被重复收费。持久化执行通过检查点机制解决了这个问题。每个步骤在下一步开始之前都会记录其结果，因此当系统崩溃并重启时，会从最后一个已完成的步骤恢复，而不是从头开始。其承诺是，即使运行工作流的机器在中途宕机，工作流也能确保恰好执行一次。支付捕获、订单履行以及任何重复执行会造成实际经济损失的多步骤流程，都是值得为此付出努力的应用场景。
Postgres 方案的工作原理
传统模型（如 Temporal 系统所采用的）运行一个独立的编排器。一个中心服务持有工作流状态，并通过网络将任务分发给工作节点。DBOS 的观点是，数据库可以直接扮演这一角色，从而完全省去额外的服务。
在机械实现上，工作节点在执行过程中直接将每个步骤的检查点写入 Postgres，而不是向编排器汇报。状态存储在普通表中。当一台服务器崩溃时，另一台服务器会读取最新的检查点，并从最后一个已完成的步骤恢复工作流。重复工作会通过 Postgres 处理任何重复数据的方式被捕获：即通过完整性约束。如果两个工作节点获取了同一个工作流，第二个节点会在检查点约束上失败并退避。
“恰好一次”的承诺是值得理解的部分，因为这是数据库体现其价值的关键所在。DBOS 在同一个 Postgres 事务中运行一个步骤并写入其检查点。工作与工作的记录要么同时提交，要么都不提交，这就消除了步骤成功但系统忘记记录这一情况的间隙。那些将工作流状态保存在独立服务中的系统通常只能保证“至少一次”交付，并要求你自己使每个步骤具备幂等性。
将所有内容放在一个数据库中还会带来两个较小的特性。队列变成了表上的 SELECT ... FOR UPDATE SKIP LOCKED 操作，因此工作节点可以在没有独立消息代理的情况下协作拉取任务。可观测性也变成了普通的 SQL 查询：“有多少工作流卡在第三步”是一个你已经知道如何编写的查询，而不是你需要购买的仪表板。
你需要放弃什么
这一切并非没有代价，诚实的框架比营销说辞更重要。将工作流状态放在主数据库中意味着你的工作流负载和应用程序负载共享同一个 Postgres 实例。对于适度的流量来说，这是一个优势，因为少了一个需要运行、备份和推理的系统。但在高吞吐量下，这变成了一种需要你精心规划的耦合关系，因为工作流的峰值现在会与用户查询竞争相同的连接数和输入/输出资源。
还有一个更细微的注意事项。T
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
