Postgres事务：分布式系统的强大武器

背景

Hacker News 平台上近日发布了一篇名为《Postgres transactions are a distributed systems superpower》的文章。作者在几周前撰写的那篇文章中明确建议开发者“just use Postgres”来实现持久化工作流（durable workflows）。这篇新文章引发了广泛讨论，但也揭示了一个重要的误解：作者并非仅仅推荐使用将状态存储在 Postgres 中的工作流引擎，而是强调工作流系统完全可以并应与应用程序代码共存于同一个 Postgres 数据库中。

作者指出，在分布式系统中，数据库共置（co-location）是一个强大的能力。当工作流元数据与应用数据同处一个数据库时，二者可以在同一数据库事务中完成更新，这消除了部分失败的可能，从而极大简化了工作流对各类边界情况的处理。

核心内容

文章首先澄清了之前“just use Postgres”的含义，澄清开发者不应将工作流与应用数据分离到不同数据库中，而是希望工作流系统直接运行在应用所在的同一 Postgres 实例中。

针对持久化工作流的核心挑战——幂等性（idempotency）。作者解释，工作流通过在每个步骤完成后记录检查点（checkpoint）来实现容错。如果工作流中断，可能发生在步骤完成数据库更新后但检查点记录未写入前，导致恢复后重复执行同一步骤。例如，某个给银行账户充值 100 美元的步骤若仅执行更新失败却未记录检查点，恢复后将重复执行，导致账户多扣 200 美元。

传统解决方案是添加应用级账本（如额外支付表），在每次更新前检查已应用记录以确保单次性。然而，当工作流与应用数据共置于同一 Postgres 数据库时，这一复杂性可大幅简化。工作流引擎可在单个数据库事务中完成以下操作：执行步骤的数据库更新、记录检查点，并在事务提交时原子化完成。这样，当事务提交时，更新与检查点均被永久记录，步骤保证仅执行一次；若事务在提交前失败，整个事务回滚，步骤将从头安全重新执行，无需应用级幂等逻辑或额外账本表。

文章还探讨了另一个经典分布式系统难题——多系统原子性更新（atomicity）。例如，订单提交后需同时更新数据库记录并通知仓库履行订单。若在数据库更新后通知发送前发生崩溃或网络故障，可能导致不一致：订单提交但未通知仓库，或仓库收到通知但订单未提交。

传统解决方案是“事务性外箱”（transactional outbox）模式：新建一个 outbox 表，在同一事务中完成数据库记录更新与消息写入，后台进程异步轮询 outbox 并投递消息。该模式保证原子性，但引入了额外的运维复杂性（轮询、投递、重试、监控，以及若工作流引擎独立于数据库可能导致同步偏差的协调作业）。

通过共置工作流与应用数据在同一 Postgres 数据库，作者提出简化方案：使用 Postgres 用户自定义函数（UDF）在应用更新事务中直接入队工作流。UDF 创建包含工作流名称、队列和输入的数据库行，与应用更新原子提交给事务；之后工作进程异步出队并执行工作流。这与事务性外箱原理一致，但无需维护单独的 outbox 表或独立的轮询进程，简化了整个操作。

关键要点

• 数据库共置是分布式系统核心优势：工作流元数据与应用数据同库可实现跨数据事务更新，避免部分失败。
• 共置使事务性步骤获得精确一次执行语义：更新与检查点原子提交，消除重复执行窗口，无需应用级幂等账本。
• 事务性工作流外箱可通过 Postgres UDF 实现：应用更新事务内直接入队，无需额外 outbox 表或独立后台进程。
• 工作流引擎若独立于数据库会增加协调复杂性，推荐与应用共置以简化边界情况处理。
• 最终结果是显著降低分布式工作流构建的运维负担，使其更可靠、更易扩展。

意义与影响

该观点为开发者提供了极具实践价值的指导：将工作流系统直接嵌入应用所在 Postgres 数据库，不仅能消除传统模式中难以处理的部分失败问题，还能使工作流成为数据库原生特性的一部分，从而显著降低系统复杂性和运维成本。DBOS 作为 Postgres 驱动的持久化执行平台，其目标正是将这类 Postgres -backed 持久化执行打造得简单高效。

文章建议开发者若构建可扩展且可靠的系统，可直接参考 DBOS 提供的快速入门（Quickstart）、GitHub 仓库和社区 Discord 频道，进一步探索如何在 Postgres 事务中实现更可靠的分布式工作流。这一思路不仅适用于传统工作流引擎，还为现代数据库应用开发提供了新范式——通过单一事务管理，简化了幂等性和原子性难题，真正将 Postgres 从单纯的存储引擎升级为分布式系统的核心超级能力。