RabbitMQ сценарий реального мира - PullRequest
2 голосов
/ 08 июля 2011

Что мне требуется от использования RabbitMQ: производитель создает сообщения, а получатель получает все сообщения, которые публикуются после того, как он впервые подключился к очереди.

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

Потребитель C1 создает очередь Q1, которая является эксклюзивной и надежной. Сейчас он некоторое время не работает, и тем временем другой пользователь C2 пытается подключиться к очереди Q1. C2 будет успешным, поскольку Q1 теперь не имеет подключенного абонента. Таким образом, C2 подключается к эксклюзивной и длительной очереди. Теперь, если C1 пытается подключиться к очереди Q1, он не может этого сделать, поскольку потребитель C2 уже подписан на очередь Q1.

Как можно предотвратить такой сценарий?

Надеюсь, в этот раз мне ясно.

Ответы [ 3 ]

1 голос
/ 08 июля 2011

Ааа !! Простой ответ ... Я не знал этой вещи о потребителе. Сделайте потребителю эксклюзив . Теперь только этот потребитель может подключиться к очереди. Но если канал, создающий этого потребителя, закрыт, цель потерпит неудачу. Следовательно, канал никогда не должен быть закрыт, если используются исключительные очереди или потребители. Вы можете найти больше об этом здесь .

0 голосов
/ 08 июля 2011

Я уже ответил на это в вопросе с таким же названием, который вы опубликовали вчера, и я не уверен, куда это ушло.Вы удалили его?

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

Ваше приложение отвечает за предотвращение соединения C2 потребителя сочередь предназначена для потребителя C1.RabbitMQ не собирается волшебным образом предотвращать это.

0 голосов
/ 08 июля 2011

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

Если C1 возвращается, он может использовать свое предыдущее соединение. И оба потребителя получают сообщения.

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