我希望在我的应用程序中将 MassTransit 用于各种用例。一种用例是处理应用程序中的“域事件”。在此用例中，我有一些正在更改聚合的业务数据，并且希望将一些域事件排队，这些事件将由同一应用程序处理，但以最终一致的方式且在当前 HTTP 请求的上下文之外。这些不是“集成事件”，我的意思是我不认为他们需要去代理，因为这些事件的消费者是同一个应用程序。
我一直在尝试遵循发件箱上的 MassTransit 文档
到目前为止，我的发件箱与我的 EF Core dbcontext 配合得很好。我还使用“内存中”传输将事件传递给消费者（再次在同一个应用程序中）。我遇到的问题，我怀疑是因为这是内存传输的默认行为，一旦消息传递给消费者，无论消费者是否成功完成，消息都会从发件箱中删除SQL Server 中的表。
本质上，假设消费者在消息/事件被传递给它之后正在处理消息/事件，并且在处理过程中机器/容器停机/终止。该消息基本上已消失/丢失，因为它不再位于 SQL Server 的发件箱表中。
使用内存传输时，有没有办法在这里分层某种类型的保证？我是否需要在此处使用代理和不同的传输来处理应用程序域事件？非常感谢这里的任何指导。
另外，我认为这篇文章与我的问题类似，但我仍然不明白解决方案是什么。 https://masstransit.io/documentation/patterns/in-memory-outbox
我尝试过使用 .UseScheduledRedelivery，但要么没有正确配置它，要么它没有对内存传输执行任何操作，因为我没有看到任何行为变化。
正如您猜测的那样，正确的真实/分布式消息传递而不是内存中的事件对于 处理领域事件，因为您只需要在同一进程中处理这些事件。
Microsoft 的EShop（在容器上） 参考应用程序使用 MediatR
来处理域事件。他们直接使用
RabbitMQ和
Azure Event Bus的 API 构建了自己的抽象。此集成事件层实现可以替换为像
Mass Transit这样的服务总线。事实上PDF是这么推荐的。我建议阅读
Resiliently publishing to the event bus
部分了解集成事件。 对于领域事件，他们选择将所有进程中相关的内容包装在一个原子事务中。如果失败，则无需采取缓解措施，并且必须由用户或某种集成事件队列重新执行触发命令的操作。来源：