asynchronous - 数据库事务和集成事件调度 - 如何使其原子化？

Question

我正在设计一个具有多个有界上下文(微服务)的系统。我将有 2 种事件。

Domain Events ，这发生在单个事务中的“内存中”(同步)

Integration Events,在有界上下文之间使用(异步)

我的问题是，如何确保一旦事务提交(此时我确定所有 Domain Events 都已成功处理) Integration Events也很成功。

当我的事务提交时，通常我会发送 Integration Events (例如到队列)，但是这个队列也有可能关闭，因此必须“还原”先前刚刚提交的事务。如何？

我想到的唯一解决方案是存储 Integration Events到同一个数据库，在同一个事务中，然后处理 Integration Events记录并将它们推送到队列 - 这将类似于“使用当前数据库作为预队列，然后将其推送到 真实队列 (但是我读到为此使用 DB 是一种反图案)。

是否有任何模式(可靠的方法)来确保两者: 事务提交 和 消息推送到队列 是原子操作吗？

编辑
阅读后 https://devblogs.microsoft.com/cesardelatorre/domain-events-vs-integration-events-in-domain-driven-design-and-microservices-architectures/ ，作者实际上建议了在同一个 DB 中“预排队”的方法(他称之为“准备发布事件”)。

Answer 1

结帐 transactional outbox pattern .

这种模式确实创建了一个预队列。但好的部分是将消息从预队列推送到真实队列是完全解耦的。相反，您有一个称为中间人的消息中继，它读取您的事务日志并将您的事件从真正的队列中推送。现在，由于发送消息和您的域事件完全解耦，您可以在单个事务中完成所有域事件。

并确保您的所有服务都是幂等的(尽管有重复调用，但结果相同)。这种事务发件箱模式确实保证消息被发布，但如果消息中继在发布后(在确认之前)失败，它将再次发布相同的事件。

在其他场景中也需要幂等服务。由于事件总线(真正的队列)可能有同样的问题。事件总线传播事件，服务确认，然后网络错误，然后由于事件总线未确认，相同的事件将再次发送。

嗯，实际上单是幂等就可以解决整个问题。在域事件计算完成后(单个事务)，如果发布消息失败，服务可以简单地抛出错误而不回滚。由于事件未被确认，事件总线将再次发送相同的事件。现在由于服务是幂等的，同一个数据库事务不会发生两次，它基本上会覆盖或更好(应该)跳过并直接移动到消息发布和确认。