是否可以为RabbitMQ RPC C＃配置多个/不同的CallBack队列？

Question

我想要这样的东西......

1. 客户提出请求。
2. 交换它是rpc_queue
3. 来自rpc_queue的服务器读取请求
4. 服务器回复不同的CallBack队列。不同的意思对于X类型的响应，它应该转到“Callback queue1”，对于Y类型的响应，它应该转到“callback queue2”

我能够直到第3步。但是不知道如何配置多个回调队列。它甚至可能吗？如果是，怎么样？请帮我解决一下这个。 提前谢谢。

Answer 1

RabbitMQ的RPC功能解决了消息的“回复”设置，该设置必须由消息生产者预先设置。如果您尝试使用RPC功能，它将无法正常工作。根据服务器所说的正确，您将无法从不同的队列中获取不同的消息。

要实现这一目标，您需要在应用程序中构建双向消息传递，而不是使用RPC语义和API。这意味着，您需要让您的消息生成器 - 生成原始请求的消息生成器 - 也设置为消息使用者。

客户端将通过rpc_queue发出请求，然后它还会同时收听callback queue 1和callback queue 2作为消息使用者。

然而，这有一些挑战。当您从回调队列收到消息时，您不一定拥有原始请求的所有上下文 - 它不是RPC，因此它不仅仅是一个回调函数。

从我的managing long running workflow processes帖子（涵盖JavaScript，但同样的原则适用）：

  

当您通过消息传递促进长时间运行的过程时，您可能不希望始终将进程对象保留在内存中。如果有数百或数千个这样的实例在运行，那可能会占用大量内存。此外，您无法保证服务器不会停止运行并在来回发送的消息之间重新启动。

     

在我的关于RabbitMQ Patterns的电子邮件课程/电子书中，我谈到了确保正确对象处理响应消息的挑战。

     

最简单的方法是再次使用邮件的关联ID。通过使用原始命令发送ID并将其与每个状态事件消息一起返回，您可以将消息应用于正确的作业。典型请求/响应方案中的相关ID可能是随机GUID或UUID。但是，在作业状态事件的情况下，相关ID应该是作业的唯一ID。这使得查找事件消息所适用的作业变得微不足道，并相应地更新作业。

     

如果管理工作流的原始对象不再在内存中，则必须在相关消息进入时重建该对象。这是上面提到的相关ID进入的位置。当消息到达时应检查相关ID，并且应将正确的工作流对象再次加载到内存中。完成后，可以按对象处理消息，可以保存状态，然后可以再次从内存中卸载工作流对象。

     

为了实现这一点，必须在消息监听器和工作流对象关系被反转的情况下显着调整代码。

我还在我的RabbitMQ Patterns电子邮件课程/电子书（不是特定于编程语言）中写了更多这方面的内容。