如果你需要跨队列到普通SQL数据库或类似系统的事务，我认为你做错了。当然，你可能需要在处理队列中的事物时有事务（标记为“已取出”，但尚未删除，然后在超时或其他情况下删除或“放回（或放入失败消息收件箱）”）对于队列系统来说可能非常重要。但一旦“如果处理消息时发生故障则保存失败”直接与数据库事务耦合，你就创建了一个非常脆弱且繁琐的系统。坦白说，这可能对某些情况来说仍然是最佳解决方案。但更好的方法是确保将队列视为消息传递系统，并按照适当的消息传递语义来处理消息。如果你无法做到，因为……
源讨论Postgres的LISTEN/NOTIFY无法扩展原帖 321 条评论 · 导入时统计使用数据库作为队列是完全没问题的，甚至在很多情况下是确保正确性的关键。在许多队列的使用场景中，你需要原子性地更新数据库以对应从队列中弹出，如果它们是独立的系统，你最终需要使用 XA 或脆弱且不可靠的自定义幂等逻辑。我以前见过这种情况出错，而且后果很严重，常见的结果是可见于业务的数据损坏，可能带来财务影响。 这似乎又是一个 Postgres 因公司遇到其技术极限而获得免费宣传的例子。我理解他们为何在这些情况下选择用工程博客文章来化悲痛为力量，但这在 HN 上太常见了。一些初创公司基于 Postgres 开发，然后在最关键的增长时期花费一半的工程预算来处理其局限性，而不是扩展他们的业务。OpenAI 几个月前也有过类似的博客文章，w…
完整原文把你的经验，加入这段讨论。
>但当“处理消息时如果发生死亡则进行失败保存”直接与数据库事务耦合时，你就创造了一个非常脆弱且笨重的东西。 从队列中处理事物的标准工作流程是，在事务性数据库中跟踪所有已处理的消息，并简单地请求剩余的未处理消息。这通常只是在数据库中存储最后一个成功处理的消息ID，并在处理该消息的同一事务中更新它。如果发生错误，你将回滚事务，这也会回滚最后一个消息ID。消费者将在下一次尝试时自动重新请求失败的消息，从而为你提供至少一次消息传递的内置幂等性。
完整原文>> 公平地说，这可能仍然是某些情况下的最佳解决方案。 这存在争议。假设你的团队从关系型角度来看很了解Postgres。现在他们需要处理一些消息，并需要某种类型的通知/消息传递。无论如何都有一个学习曲线。我认为他们应该将这个学习曲线花在更标准的方法上，这些方法并不比从头开始更难。当然，如果你知道你的网站/服务只会被你自己和你奶奶使用，你可以随心所欲（只需使用文本文件或更好的方法是直接给她打电话）。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。