Как настроить RabbitMq, чтобы несколько приложений могли управлять своими собственными очередями и привязками к общему обмену.

Question

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

Мы хотели бы гарантировать, что очереди и привязки каждого приложения могут управляться только этим приложением и пользователем, с которым связано приложение. Я предполагал использовать виртуальные хосты, чтобы обмен находился в виртуальном хосте /common, который каждый пользователь приложения имел доступ на чтение, а очереди и привязки каждого приложения жили в собственном виртуальном хосте /<app>, к которому у пользователя был полный доступ.

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

Есть ли способ достичь этого?

Answer 1

Я думаю, добиться того, что вы просили вам нужно использовать федерацию. У меня такая же проблема с доменом. Один обмен, а затем различные приложения, используемые из разных очередей. Если я прав, выполните следующие действия:

Обмен A => Федерал. Для обмена 1/2/3/4/... у этих обменов есть разные хорваты.

создать другого пользователя-призрак и пользователя для разных приложений. Дайте доступ к этим виртуальному хосту к различному обмену (Exchange 1/2/3/4 /)

создавать различные очереди, чтобы связать с различной валютой 1/2/3/4/

Это понятно?

Answer 2

Очереди управляются кроликом. Потребители не могут управлять ими. Потребители могут создавать/объявлять очереди с тем или иным набором параметров. Один из этих параметров - «exclusive», что указывает на то, что доступ к очереди может получить только текущее соединение.

Виртуальный хост указан при подключении, а не при привязке, как вы сказали, поэтому вам нужно будет сделать это в отдельном потоке. Либо это, либо реорганизовать вас vhosts.

Возможно, вам это не нужно, и было бы достаточно иметь ключи маршрутизации и объявить очереди эксклюзивными вместо «/ app» vhostand, вместо обмена «common» vhost.

Answer 3

В строке подключения указываются виртуальные хосты (vhost). Vhosts позволяет отделить приложения от одного брокера. Вы можете изолировать пользователей, обмены, очереди и т. Д. С одним конкретным vhost. Вы можете отделить среды, например. производство на одного vhost и постановку на другой vhost внутри того же брокера, вместо того, чтобы создавать несколько брокеров.

https://devcenter.heroku.com/articles/cloudamqp#separate-applications