是否可以为 RabbitMQ RPC C# 配置 multiple/different 回调队列？
Is it possible to configure multiple/different CallBack queue for RabbitMQ RPC C#?
我想要这样的东西...
- 客户提出请求。
- Throught Exchange 转到rpc_queue
- 来自 rpc_queue
的服务器读取请求
- 服务器给不同的回调队列回复。不同的方式 对于 X 类型的响应，它应该转到 "Callback queue1"，对于 Y 类型的响应，它应该转到 "callback queue2"
我可以到第3步。但是不知道如何配置多个回调队列。有可能吗？如果是，如何？请帮我解决一下这个。
提前致谢。
RabbitMQ 的 RPC 功能根据消息的 "reply-to" 设置工作，消息生产者必须预先设置。如果您尝试使用 RPC 功能，它将不起作用。根据服务器所说的正确性，您将无法从不同的队列中获取不同的消息。
要实现此功能，您需要在您的应用中构建双向消息传递，而不是使用 RPC 语义和 API。这意味着，您需要让您的消息生产者（发出原始请求的那个）也设置为消息消费者。
客户端将通过 rpc_queue 发出请求，然后它还将作为消息消费者收听 callback queue 1 和 callback queue 2。
然而，这也有一些挑战。当您从回调队列接收到消息时，您不必再拥有原始请求的所有上下文 - 它不是 RPC，因此它不仅仅是一个回调函数。
来自我的 managing long running workflow processes post（涵盖 JavaScript，但同样的原则适用）：
When you have a long running process facilitated by messaging, you may not want to keep the process object around in memory all the time. If there are hundreds or thousands of these instances running, that could eat up a lot of memory. Additionally, you have no guarantee that the server won’t go down and come back up in between messages that are sent back and forth.
In my email course / ebook on RabbitMQ Patterns, I talk about the challenge of ensuring the response message is handled by the right object.
The easiest way to do this is to again use the Correlation ID of the message. By sending an ID with the original command, and returning it with each status event message, you can apply the message to the correct job. The correlation ID in a typical request / response scenario will likely be a random GUID or UUID. In the case of the job status events, however, the correlation ID should be the job’s unique ID. This makes it trivial to find the job to which the event message applies, and update the job accordingly.
If the original object that is managing the workflow is no longer in memory, you will have to reconstruct that object when a related message comes in. This is where the correlation ID that is mentioned above comes in to play. The correlation ID should be examined when a message arrives, and the correct workflow object should be loaded in to memory again. Once that has been done, the message can be processed by object, the state can be saved and then the workflow object can be unloaded from memory once more.
To make this happen, the code will have to be adjusted significantly with the message listener and workflow object relationship inverted.
我还在我的 RabbitMQ Patterns 电子邮件课程/电子书中（不特定于编程语言）写了更多关于这个的内容。
我想要这样的东西...
- 客户提出请求。
- Throught Exchange 转到rpc_queue
- 来自 rpc_queue 的服务器读取请求
- 服务器给不同的回调队列回复。不同的方式 对于 X 类型的响应，它应该转到 "Callback queue1"，对于 Y 类型的响应，它应该转到 "callback queue2"
我可以到第3步。但是不知道如何配置多个回调队列。有可能吗？如果是，如何？请帮我解决一下这个。 提前致谢。
RabbitMQ 的 RPC 功能根据消息的 "reply-to" 设置工作，消息生产者必须预先设置。如果您尝试使用 RPC 功能，它将不起作用。根据服务器所说的正确性，您将无法从不同的队列中获取不同的消息。
要实现此功能，您需要在您的应用中构建双向消息传递，而不是使用 RPC 语义和 API。这意味着，您需要让您的消息生产者（发出原始请求的那个）也设置为消息消费者。
客户端将通过 rpc_queue 发出请求，然后它还将作为消息消费者收听 callback queue 1 和 callback queue 2。
然而，这也有一些挑战。当您从回调队列接收到消息时，您不必再拥有原始请求的所有上下文 - 它不是 RPC，因此它不仅仅是一个回调函数。
来自我的 managing long running workflow processes post（涵盖 JavaScript，但同样的原则适用）：
When you have a long running process facilitated by messaging, you may not want to keep the process object around in memory all the time. If there are hundreds or thousands of these instances running, that could eat up a lot of memory. Additionally, you have no guarantee that the server won’t go down and come back up in between messages that are sent back and forth.
In my email course / ebook on RabbitMQ Patterns, I talk about the challenge of ensuring the response message is handled by the right object.
The easiest way to do this is to again use the Correlation ID of the message. By sending an ID with the original command, and returning it with each status event message, you can apply the message to the correct job. The correlation ID in a typical request / response scenario will likely be a random GUID or UUID. In the case of the job status events, however, the correlation ID should be the job’s unique ID. This makes it trivial to find the job to which the event message applies, and update the job accordingly.
If the original object that is managing the workflow is no longer in memory, you will have to reconstruct that object when a related message comes in. This is where the correlation ID that is mentioned above comes in to play. The correlation ID should be examined when a message arrives, and the correct workflow object should be loaded in to memory again. Once that has been done, the message can be processed by object, the state can be saved and then the workflow object can be unloaded from memory once more.
To make this happen, the code will have to be adjusted significantly with the message listener and workflow object relationship inverted.
我还在我的 RabbitMQ Patterns 电子邮件课程/电子书中（不特定于编程语言）写了更多关于这个的内容。