Сергей

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

Из текста не до конца понятно, Вы хотите, чтобы была очередь или sender должен выполняться каждый раз для нового сообщения? Если очередь, то обрабатывать сообщения по одному можно, но только если получатель один. В протоколе AMQP можно вручную получать сообщения по одному - basic_get, или выставить количество неподтвержденных сообщений в 1 и подтверждать обработку каждого.

Для RabbitMQ все консьюмеры одной очереди считаются равноправными, вся маршрутизация выполняется до очереди, то есть каждый отдельный сервис (один консьюмер или их группа) должен иметь свою очередь.

Я не работал с IoT-устройствами, но мне кажется, что отдельная локальная шина звучит логично, так как позволит иметь наименьшие задержки и работать офлайн, а также, возможно, сэкономить батарею. Но зависит от задачи и ресурсов, может оказаться поначалу выгодней работать через серверв. RabbitMQ использовать на IoT-устройстве так себе идея, имхо, для простой отправки в маленьком масштабе он будет невыгоден по ресурсопотреблению.

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

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

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

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