Comments 3
Кстати, спасибо. Много провел времени с RabbitMQ, но почему-то не встречал этой фичи.
Очень важное дополнение, которое есть в офсправке, но почему-то нет у вас: отправка сообщения должна быть через то же соединение и channel что и слушаем для ответа. Это может быть не всегда так в таких фреймворках как, например, kombu.
В пределах одного connection можно (и рекомендуется) открывать новые channel, так что локи не обязательны.
Спасибо за информацию. Я как-то и не задумывался даже, что кто-то захочет делать отправку через другой connection и channel. Насчет поднятия дополнительных channel не уверен насколько это оправдано для этого кейса. Если вы хотите прям бродкастить RPC, наверное, нам стоит все-таки создать для ответов полноценную очередь. Если вы хотите отправить 2-3 сообщения подряд, то лок не сыграет большой роли.
Но я еще изучу этот вопрос и буду благодарен, если поможете с материалом на эту тему.
Если в кластере пара десятков нод, то в aio-pika есть пулы, чтобы цепляться к разным хостам (там тоже не так просто, но тем-не менее). В RabbitMQ, политика по умолчанию, распределяет очереди по тем нодам на которых они были объявлены, таким образом если в рамках одного соединения, задекларировать 1000 очередей, то нагрузка на кластер будет неравномерная.
RabbitMQ Direct Reply-to. RPC поверх кролика без дополнительных очередей (пример на Python)