Обмен привязкой Rabbitmq к обмену

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

Веб-сайт содержит идентификатор сеанса для каждого пользователя. Когда пользователь аутентифицируется, создается другой обмен с именем sessionId. Пользователю на стороне клиента разрешено привязываться ко всем обменам, кроме главного. Поскольку идентификатор сеанса уникален, было бы очень сложно угадать идентификатор сеанса другого пользователя и выполнить привязку для получения их сообщений.

каждое сообщение будет иметь ключ маршрутизации sessionID.destination. Клиентская сторона будет знать все потенциальные направления.

Чтобы помочь визуализировать:

                            -> SessionID Exchange -> client
Server -> master Exchange | -> SessionID Exchange -> client
                            -> SessionID Exchange -> client

Мой вопрос двоякий. Можно ли привязать обмен к обмену в rabbitmq? Кроме того, кто-то устанавливал подобную систему ранее? Скорее, у кого-нибудь с опытом работы в этой теме уже есть работающая система, которую я могу использовать?

Заранее спасибо.


rabbitmq amqp messaging rabbitmq-exchange
person AlexLordThorsen    schedule 28.08.2012    source источник
comment
Пожалуйста, ознакомьтесь с этой статьей, которую я создал, чтобы объяснить Exchange для привязки обмена jstobigdata.com /rabbitmq/   -  person SyntaX    schedule 26.03.2020

Ответы (3)


arrow_upward
4
arrow_downward

Да можно привязать и обменять на и обменять. Вы даже можете иметь различные типы обменов. Вам нужно использовать channel.exchangeBind() вместо channel.queueBind(). Но это работает аналогичным образом.

У меня есть обмен темами, привязанный к обмену ответвлениями в моей системе. Я обязательно отправляю ключ маршрутизации с сообщениями, отправляемыми на разветвленный обмен. Это не влияет на уровень обмена ответвлениями, но когда он направляется на обмен темами, ключ маршрутизации затем используется для определения того, в какие очереди он отправляется.

person robthewolf    schedule 29.08.2012
comment
Я помню из блогов rabbitmq, что привязка очереди к обмену увеличивает время маршрутизации. Знаете ли вы, является ли привязка биржи к бирже большим ударом по производительности? - person AlexLordThorsen; 29.08.2012
comment
Я не могу быть уверен, какие проблемы с производительностью связаны с привязкой и обменом и обменом. Но я не очень понимаю, что вы имеете в виду, говоря о привязке очереди к обмену, что является ударом по производительности. Если и exchange не имеет привязанной к нему очереди, то сообщения никуда не пойдут. Я бы сказал, что это больший успех - person robthewolf; 30.08.2012
comment
Привязка очереди к обмену — затратный процесс. Привязка очередей ко многим биржам приведет к оттоку привязки. Лучшим решением для масштабируемости является использование биржи для привязки биржи. Клиент создаст свой собственный частный обмен и привяжется к обмену на сервере. Привязка Exchange к Exchange лучше работает и решает проблемы масштабируемости. - person Prakhyat; 09.08.2013

arrow_upward
1
arrow_downward

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

Рассмотрим случай, когда вы хотите, чтобы сообщения отправлялись в возможные очереди назначения на основе привязок, ТАКЖЕ выполняйте больше переходов к другому обмену и его привязке к очереди. В таких случаях привязка обмена к обмену подойдет для этой цели.

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

person Prakhyat    schedule 09.08.2013

arrow_upward
0
arrow_downward

Я нашел этот блог, в котором говорилось о чем-то похожем на мой дизайн. Это не совсем то же самое, но это дало мне понять, что это, по крайней мере, возможно.

http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/

person AlexLordThorsen    schedule 29.08.2012