我想要的東西像這樣...是否可以爲RabbitMQ RPC C＃配置多個/不同的CallBack隊列？
我能直到第3步，但不知道如何配置多個回調隊列。它甚至有可能嗎？如果是的話，怎麼樣？請幫我解決一下這個。 在此先感謝。
的RabbitMQ的RPC功能清除「回覆」的一個消息，該消息具有設定要由所述消息生成器進行預設定。如果您嘗試使用RPC功能，則無法工作。根據服務器所說的正確性，您將無法從不同的隊列中獲得不同的消息。
要做到這一點，您需要在應用程序中構建雙向消息傳遞，而不是使用RPC語義和API。這意味着，您需要讓您的消息生產者 - 即提出原始請求的消息生產者 - 也設置爲消息使用者。
客戶端將通過rpc_queue發出請求，然後它也將聽取callback queue 1和callback queue 2作爲消息使用者。
但是，這有一些挑戰。當你從回調隊列收到消息時，你不一定擁有原始請求的所有上下文 - 它不是RPC，所以它不僅僅是一個回調函數。
從我managing long running workflow processes後（其中包括JavaScript的，但同樣的原則也適用）：
當你通過短信促成一個長期運行的過程中，你可能不希望在內存中保存的過程中對象的所有時間。如果有數百或數千個這樣的實例在運行，那可能會消耗大量的內存。另外，您不能保證服務器不會停下來，並在來回發送的消息之間回來。
在上RabbitMQ的模式我的電子郵件當然/電子書，我說說確保響應消息是由正確的對象處理的挑戰。
最簡單的方法是再次使用消息的相關標識。通過發送帶有原始命令的ID，並將其與每個狀態事件消息一起返回，您可以將該消息應用於正確的作業。在一個典型請求/響應情景的相關性ID將可能是一個隨機GUID或UUID。但是，就作業狀態事件而言，相關ID應該是作業的唯一ID。這使查找應用事件消息的作業變得微不足道，並相應地更新作業。
如果正在管理工作流中的原始對象在內存不再，你將不得不重構對象時，相關消息進來，而這正是被上述關聯ID也發揮了作用。消息到達時應檢查相關標識，並將正確的工作流對象再次加載到內存中。一旦完成，消息就可以通過對象處理，狀態可以保存，然後工作流對象可以再次從內存中卸載。
爲了實現此目的，代碼將不得不通過消息偵聽器和工作流對象關係進行重大調整。
我也寫過關於這個更多，在我的RabbitMQ Patterns電子郵件課程/電子書（這不是特定於編程語言）。