Victor Bomberow

Плагин работает с прямыми привязками, каждому ТС будет соответствовать своя очередь. Поддержание очереди не самая сложная работа для RabbitMQ.

Если вас устраивают ограничены плагина, можете не рассматривать вариант с СУБД. Но если именно через RabbitMQ, то хранить всё в одной очереди идея не лучшая, ибо будете на каждый чих n проверок делать.

С двумя очередями уже поинтереснее, когда первая будет буфером, а вторая - с фактической информацией, но нужно делать свой воркер, который читает из буфера и пишет в очередь, обеспечивая уникальные значения. Очередей две, но нагрузка у вас получится будет на воркере, а не кластере RabbitMQ, а из второй очереди клиенты могут читать и искать сообщение с инфо о своём ТС.
Но фишка RabbitMQ все же в queue/exchanges, делать такое на RabbitMQ не очень хорошо.

Если у пользователя rabbitmq есть права на данном виртуальном хосте, на котором расположена очередь, он может отсылать туда сообщения, если очередь не заполнена максимально, и на этом все, что касается именно очередей.

Учитывая вашу настоящую проблему, вам нужно обратить внимание на exchanges (набор очередей), и производить публикацию через них, тогда Rabbitmq сам будет балансировать нагрузки сообщений между всеми очередями, которые зарегистрированы в определенном exchange.

(в вырожденом случае это может быть и одна очередь, но rabbitmq пришел к такому из-за необходимости поддержки кластеризации)

https://www.rabbitmq.com/tutorials/tutorial-three-...