在我们的应用程序中，发布者会创建一条消息并将其发送到主题。
然后，当所有主题的订阅者都收到消息时，它需要等待。它没有出现，消息总线实现可以自动执行此操作。因此，我们倾向于让每个订阅者在完成后为客户端发送自己的新消息。
现在，客户端可以接收所有这些消息，并且当它从每个目的地获得一个消息时，做它必须做的任何清理。但是如果客户端（发送者）在确认流中部分崩溃会怎么样？为了处理这样的不幸，我需要（重新）实现客户端上已经实现的总线 - 保存传入的确认，直到我得到足够的确认。
我不相信，我们的需求是深奥的 - 您如何处理发件人（发布者）必须等待来自多个收件人（订阅者）的确认的情况？有点像从每个订户请求（和等待）退货收据到邮件列表...
如果重要的话，我们正在使用RabbitMQ。谢谢！
答案 0 :(得分：5)
您正在寻找的功能听起来像是一种消息传递解决方案，可以跨消息的发布者和订阅者执行事务。在Java世界中，JMS指定了这样的事务。 JMS实现的一个示例是HornetQ。
RabbitMQ没有提供这样的功能，并且它有充分的理由。 RabbitMQ的构建非常强大，同时表现得像地狱一样。您描述的事务行为只能通过合理性能损失的成本来实现（特别是如果您希望保持出色的稳健性）。
使用RabbitMQ，确保消息成功使用的一种方法确实是在消费者方面发布一条答案消息，然后由原始发布者使用。这可以通过RabbitMQ's RPC procedure calls来实现，这可以帮助您为问题设置找到一个干净的解决方案。
如果（原始）发布者在收到所有答案之前崩溃，您可以假设所有未完成的答案仍在代理上排队。因此，您必须以能够继续处理这些留言的方式构建您的发布者。这可能会变得非常重要。
最后，我建议使用以下解决方案：以一种方式设计您的生产组件，您可以使用与原始发布者分开的一个或多个专用答案使用者来使用答案。
此解决方案的好处是：
现在更普遍一点：消息传递的主要好处之一是代理将应用程序组件分离。在AMQP中，这是通过交换和绑定实现的，它允许您将消息分发逻辑从应用程序移动到中心配置点。
如果向客户端添加RPC样式的调用，则组件很可能再次紧密耦合，这意味着如果其中一个消耗组件失败/不可用/太慢，则发布组件将失败。这正是您想要避免的。否则，为什么要拆分组件？
我的建议是，您可以设计应用程序，使发布者可以尽可能独立于消费者的成功完成其任务。反向信道应该是一种特殊情况，并以所描述的不那么耦合的方式实现。