在构建持久化工作流库时，选择合适的数据存储至关重要。Postgres因其并发控制、关系数据模型和事务支持等特性，成为理想选择。其并发控制支持分布式队列的扩展，关系模型结合二级索引提升了工作流元数据的可观察性，而事务机制则确保了数据库操作的精确一次执行。这些技术优势使Postgres成为构建高性能、可扩展工作流库的坚实基础。

为什么Postgres是持久化工作流执行的理想选择？

在构建持久化工作流库时，最关键的设计决策之一是选择用于存储工作流元数据的数据存储。持久化工作流的核心操作包括检查点保存工作流状态以及从最新检查点恢复中断的工作流。虽然几乎所有数据存储都能处理这些操作，但选择合适的存储对于确保工作流的可扩展性和性能至关重要。

本文将深入探讨为什么我们选择基于Postgres构建持久化工作流库。除了非技术性原因（如Postgres的流行性、开源特性、活跃社区以及超过40年的实战测试），我们将重点讨论技术性原因，即Postgres的关键特性如何帮助我们开发出健壮且高性能的工作流库。具体来说，我们将探讨以下三个方面：

1. Postgres的并发控制（特别是其锁机制）如何支持可扩展的分布式队列。
2. 关系数据模型（结合二级索引的合理使用）如何实现高效的工作流元数据监控工具。
3. Postgres事务如何确保执行数据库操作的步骤具有“恰好一次”的执行保证。

构建可扩展的队列

将持久化工作流加入队列以便稍后执行是一种常见需求。然而，使用数据库表作为队列存在竞争风险。在数据库支持的工作流队列中，客户端通过将工作流添加到队列表中来入队，而工作线程则出队并处理最早入队的工作流（假设是FIFO队列）。如果多个工作线程同时从队列中拉取任务，它们可能会尝试出队相同的工作流，导致大多数工作线程无法找到新任务并需要重试。这种竞争会在系统中形成瓶颈，限制任务的出队速度。

Postgres通过其锁机制提供了解决方案。使用SELECT FOR UPDATE SKIP LOCKED查询，工作线程可以锁定未被其他工作线程锁定的最老工作流，从而避免竞争。这种方式允许多个工作线程并发地拉取新工作流，而不会产生竞争，极大地提高了系统的吞吐量。

实现工作流的可观测性

持久化工作流的一个优势是它们提供了内置的可观测性。如果每个工作流的每个步骤都被检查点保存到持久化存储中，你可以扫描这些检查点来实时监控工作流并可视化其执行过程。Postgres的关系模型使得任何工作流监控查询都可以轻松地用SQL表达。例如，你可以编写查询来查找过去一个月中所有出错的工作流。

为了确保这些查询在大规模（超过1000万工作流）下仍能高效执行，Postgres提供了二级索引。二级索引允许Postgres快速查找具有特定属性或属性范围的所有工作流。我们通过为最常用的查询字段添加二级索引，在查询性能和运行时开销之间取得了平衡。

实现“恰好一次”语义

通常，持久化工作流保证步骤“至少执行一次”。如果程序在执行步骤时失败，工作流会从最新的检查点恢复并重新执行该步骤，这可能导致步骤被执行多次。通过在Postgres上构建持久化工作流，我们可以利用Postgres事务来确保步骤“恰好执行一次”。具体做法是将整个步骤及其检查点放在同一个事务中执行。如果工作流在步骤执行期间失败，整个事务会回滚，步骤不会被执行；如果事务提交后工作流失败，步骤检查点已经写入，步骤不会被重新执行。

了解更多

如果你喜欢使用Postgres进行开发，欢迎与我们联系。在DBOS，我们的目标是使持久化工作流尽可能轻量且易于使用。你可以通过以下链接了解更多：

• 快速入门：https://docs.dbos.dev/quickstart
• GitHub：https://github.com/dbos-inc

评论内容主要围绕DBOS及其与其他工作流系统的比较展开，观点多样且涉及多个技术细节。以下是总结：

1. DBOS的易用性与优势

   • 有用户表示DBOS易于集成，且无需改变现有基础设施。
     引用：
     • "Recently moved some of the background jobs from graphile worker to DBOS. Really recommend for the simplicity."
     • "最近将一些后台任务从graphile worker迁移到DBOS，推荐其简单性。"

2. “Exactly Once”语义的争议

   • 有评论指出，完全保证“Exactly Once”是不可能的，建议使用幂等性来应对风险。
     引用：
     • "Anything that guarantees exactly once is selling snake oil."
     • "任何保证‘Exactly Once’的说法都是在卖蛇油。"

3. 与其他系统的比较

   • 用户将DBOS与Temporal、Azure Durable Functions、Inngest等系统进行比较，认为它们在功能上相似，但各有优缺点。
     引用：
     • "I think the model isn’t too different than Azure Durable Functions."
     • "我认为DBOS的模型与Azure Durable Functions没有太大不同。"

4. 开源与商业模式的批评

   • 有用户对DBOS的核心组件Conductor未开源表示失望，认为这是其商业模式的一部分。
     引用：
     • "I was really disappointed to learn that Conductor, which is the DBOS equivalent of the Temporal server, is not open source."
     • "得知DBOS的核心组件Conductor未开源，我感到非常失望。"

5. 技术细节与实现

   • 有评论提到FOR UPDATE SKIP LOCKED等技术细节，认为这些技术并不新鲜。
     引用：
     • "Every few years someone discovers FOR UPDATE SKIP LOCKED and represents it."
     • "每隔几年就有人重新发现FOR UPDATE SKIP LOCKED并重新提出。"

6. 与其他轻量级解决方案的对比

   • 用户提到其他轻量级解决方案，如Durable和Underway，认为它们也是可行的选择。
     引用：
     • "Some other lightweight solutions around."
     • "还有其他一些轻量级解决方案。"

7. 与复杂数据编排框架的集成

   • 有用户询问DBOS是否可与Dagster等复杂数据编排框架集成，认为两者可以互补。
     引用：
     • "Often wondered whether it would be possible / advisable to combine DBOS with, e.g., Dagster."
     • "经常思考是否可以将DBOS与Dagster等框架结合使用。"

总结：DBOS因其易用性和简单性受到一些用户的认可，但在“Exactly Once”语义、开源性和与其他系统的比较上存在争议。用户对其技术细节、商业模式及与其他框架的集成提出了不同看法。