Сергей

1) Разработчики RabbitMQ ко всем потерям данных на стороне самого RabbitMQ относятся критично, так что, если в какой-то момент будете уверены, что теряет данные именно он, то смело создавайте баг (с подробностями как повторить).
2) Если админы не умеют настраивать стейтфул приложения в контейнерной среде или куча ручных операций, то это больше административная задача, чтобы научиться и, например, использовать шаблоны/чарты/т.п. для предотвращения сюрпризов. Но также RabbitMQ в контейнере нужно настраивать, чтобы не получать деградации и дампов.
3) Со стороны самого RabbitMQ есть зеркалирование очередей (queue mirroring) для дублирования данных, что позволит внезапно терять ноды (но восстановление может обойтись высоким потреблением процессора).
4) Также рекомендую логировать и идентифицировать каждое отправленное и полученное сообщение, чтобы оценивать проблему. Для большей достоверности можно включить логирование ещё и на уровне RabbitMQ (если позволяют ресурсы). На прошлой работе у нас был свой плагин для RabbitMQ, который получал копию всех полученных и отправленных сообщений, выгребал из них нужную метаинформацию и отправлял в Graylog.
5) Ну и конечно нужно делать отправку и приём с подтверждением, но это, я думаю, Вы и без меня уже делаете.

В гугле по словам "rabbitmq" и "rpc" выдаётся ссылка на оф.документацию по Direct reply-to, Вы пробовали такой механизм? Создание/удаление очереди ради получения одного ответа это очень накладно. 50/400rpc это вообще не о чём, даже для RabbitMQ (конечно всё зависит от выделенных ресурсов, хранению на диске и т.д.).

С серверной стороны используется всего 1 порт, это клиентская часть выбирает случайный (по умолчанию), так что количество клиентов, которое может обслужить сервер RabbitMQ (да и любой другой сервис) не ограничено лимитом портов. (Например, в Linux каждое соединение характерирузется 5 параметрами {proto, src_ip, scr_port, dst_ip, dst_port}.)

Ограничение дают вычислительные ресурсы, которыми распоряжается RabbitMQ. Так как очереди в RMQ не самые простые, то они потребляют достаточно памяти, я бы сказал, что каждая очередь (при условии что там немного сообщений) потребляет 30-50 КБ RAM. Можно попробовать включить режим Lazy Queue, чтобы RQM всегда писал/читал с диска и не кэшировал сообщения в памяти. Также RMQ любит процессор, но может хорошо распределить нагрузку между всеми ядрами.

В кластерном режиме RabbitMQ может распределить очереди по всем серверам и обслуживать клиента на любом из них (но балансить клиентов также надо по всем узлам, в идеальности "привязать" клиента к одному серверу). Но проблемы начнутся, когда узлы RMQ начнут "падать" :-) Плюс метадата об очередях синхронизируется между всеми серверами, так что, если поток команд на создание/удаление очередей будет высок, то только на этом может съесться куча процессора и сети.

Принцип очереди в RabbitMQ - сообщение получает только один подписчик, так что, если у Вас действительно одна очередь (а не подписка из каждого приложения на обменник, при которой создаётся отдельная очередь для каждого подписчика), то проблем быть не должно.

Boris Korobkov дал ценное замечание по поводу того, что всем должен рулить сервер и нужно добавить элемент случайности в имена, дополню его несколькими рекомендациями.

1) Если очередь будет создана сервером, то auto-delete не будет работать, если клиент не подпишется на неё.
2) Не забывайте, что если два клиента (например, две вкладки или две сессии одного пользователя) подключатся к одной очереди, то сообщение получит только один из них. В своих решениях я использовал подход, что очередь создавалась клиентом, а обменник сервером, но необходимо убедиться, что до RabbitMQ доходят только легитимные запросы (от авторизованных клиентов) и пользователь ограничен в правах создавать только нужные очереди и подписывать их на нужные обменники.
3) Рекомендовал бы не выставлять порт web-stomp плагина без доп.защиты (например, HAProxy), которая позволит защитить RabbitMQ от перегрузки подключениями.

P.S. Писал статью на Хабр год назад о подобной системе, может быть что-то будет интересное в ней ещё - https://habr.com/post/341068/

Если менеджмент плагин включён, то можно его возможностями воспользоваться для создания/конфигурирования объектов при старте. Пример этого файла можно получить экспортировав определения из webui (внизу страницы было).

Что подразумевается под RPC, Remote Procedure Call? Если так и вопрос появился, например, после просмотра одного из туториала, то это один из паттернов взаимодействия в распределённых приложениях, в котором RabbitMQ Вам сможет помочь. У него "из коробки" есть расширение, которое позволяет получить результат выполнения функции, без создания дополнительных объектов в брокере.

1) Уровень очередей, мастеры очередей могут быть на разных нодах, вот тут описано, как Вы можете повлиять на процесс выбора мастера.

2) Вы можете отправлять/получать сообщения с любой ноды, даже если на ней нет ни мастера, ни слейва этой очереди, RabbitMQ сам спроскирует куда нужно (соответственно внеся некие задержки в запрос). Для работы через HAProxy в последних версиях есть поддержка протокола PROXY, чтобы в менеджмент консоле можно было видеть реальные адреса клиентов, а не адреса прокси.

Задать время жизни можно с помощью www.rabbitmq.com/ttl.html (самое простое повесить политику).
Чтобы протухшее сообщение не просто удалилось, а попало в другую очередь можно воспользоваться этим www.rabbitmq.com/dlx.html

1) Использовать basic_get вместо basic_consume, эта штука получает всего лишь одно сообщение за вызов, пример использования - https://github.com/php-amqplib/php-amqplib/blob/ma...
2) Сделать счётчик полученных сообщений и при достижении 10 закрыть канал.