作为发布者使用 MassTransit 和 ActiveMQ 实现有保证的交付

Question

我在我的设置中看到 ActiveMQ 吞吐量为每秒 2000 条连续消息，而 RabbitMQ 吞吐量为每秒 250 条连续消息。 RabbitMQ 缓慢的原因是发送者的消息确认。这样就保证了交货。 ActiveMQ 文档也讨论了这个主题并指出

如果您不使用事务并发送持久消息，则每次发送都是同步的并会阻塞，直到代理向生产者发回消息已安全持久到磁盘的确认。此确认提供了消息不会丢失的保证，但由于客户端被阻止，因此也会造成巨大的延迟损失。

这种“巨大的延迟损失”是我所期待但没有看到的。 250 次往返的数量听起来比 2000 次更现实。我怀疑我没有通过 ActiveMQ 获得有保证的交付。我无法人为地收到丢弃的消息。

MassTransit 代码包括 nms.AsyncSenc = true。在 nms.AsyncSenc = true 的上下文中，文章提到了以下内容：

许多高性能应用程序被设计为能够容忍故障情况下的少量消息丢失。如果您的应用程序是以这种方式设计的，则即使在使用持久消息时，您也可以启用异步发送来提高吞吐量。

我得到的保证是什么？如何获得保证交货？

Answer 1

我认为您可能误解了您引用的 ActiveMQ 文档。它没有描述您在启用异步发送时所拥有的任何保证。

简而言之，您无法通过异步发送获得有保证的交付。这就是为什么文档说异步发送持久消息仅适用于“设计为在故障情况下容忍少量消息丢失”的应用程序。因此，如果“您的应用程序是以这种方式设计的”，您应该仅启用带有持久消息的异步发送。

可以在任何保证下异步发送的唯一情况是：

• 使用事务时，您可以异步发送所有消息并提交（同步）一次。
• 当使用像 JMS 2 这样支持回调机制（如

  CompletionListener

  ）的 API 时，您可以异步发送，并且如果发送消息出现问题，仍然会收到通知。