Функциональность RPC RabbitMQ работает с настройками «ответ на» для сообщения, которое должно быть предварительно настроено производителем сообщений. Если вы попытаетесь использовать возможности RPC, это не сработает. Вы не сможете получить другое сообщение из другой очереди, исходя из того, что сервер говорит правильно.
Для выполнения этой работы вам нужно будет создать двухсторонний обмен сообщениями в вашем приложении, вместо использования семантики RPC и API. Значит, вам нужно, чтобы ваш поставщик сообщений - тот, который делает исходный запрос, также настроен как потребитель сообщения.
Клиент отправит запрос через rpc_queue, а затем он также прослушает и callback queue 1, и callback queue 2 в качестве потребителя.
Однако есть некоторые проблемы. Когда вы получаете сообщение из очередей обратного вызова, вы не обязательно имеете весь контекст исходного запроса больше - это не RPC, поэтому это не просто функция обратного вызова.
С моего managing long running workflow processes поста (который охватывает JavaScript, но применяется тот же принцип):
Когда у вас есть длинный запущенный процесс облегчено сообщения, вы не можете сохранить объект процесса вокруг в памяти всем время. Если есть сотни или тысячи этих экземпляров, которые могут съесть много памяти. Кроме того, у вас нет гарантии, что сервер не будет опускаться и будет возвращаться между сообщениями, которые отправляются туда и обратно.
В моем курсе электронной почты/книге о шаблонах RabbitMQ я рассказываю о том, как обеспечить, чтобы ответное сообщение обрабатывалось правильным объектом.
Самый простой способ сделать это - снова использовать Идентификатор корреляции сообщения. Отправляя идентификатор с исходной командой и возвращая ее с каждым сообщением о событии, вы можете применить сообщение к правильной задаче. Идентификатор корреляции в типичном сценарии запроса/ответа скорее всего будет случайным GUID или UUID. Однако в случае событий статуса задания идентификатор корреляции должен быть уникальным идентификатором задания. Это делает тривиальным найти задание, к которому применяется сообщение о событии, и соответствующим образом обновить задание.
Если исходный объект, который управляет рабочим процессом, больше не находится в памяти, вам придется восстановить этот объект, когда приходит связанное сообщение. Здесь используется идентификатор корреляции, упомянутый выше. Идентификатор корреляции должен быть проверен при поступлении сообщения, а правильный объект рабочего процесса должен быть снова загружен в память.Как только это будет сделано, сообщение может быть обработано объектом, состояние может быть сохранено, а затем объект рабочего процесса может быть выгружен из памяти еще раз.
Чтобы это произошло, необходимо значительно скорректировать код с перестановкой отношения слушателя сообщения и рабочего процесса.
Я также написал об этом более подробно в своем RabbitMQ Patterns курсе электронной почты (ebook) (который не относится к языку программирования).