artemmatveev19 фев 2020 в 17:30

RabbitMQ. Часть 2. Разбираемся с Exchanges

7 мин

233K

.NET * C# * DevOps * Микросервисы * Мессенджеры *

Туториал

+11

Комментарии 11

W001fer 20 фев 2020 в 10:52

Спасибо! Вторая замечательная статья! Очень подробно и понятно.

Jsty 20 фев 2020 в 14:54

В каких случаях может использоваться fanout exchange? Какой реальный usecase использования доставки одного сообщения в несколько очередей? Возможно, вопрос покажется глупым, но мне, к сожалению (или к счастью) не приходилось сталкиваться с такими задачами. Всегда хватало direct exchange.

artemmatveev 20 фев 2020 в 14:55

Применение fanout exchange можно представить в контексте микросервисов. Например, бессмысленное вещание события на которое должны реагировать определенные потребители. Producer определяет только обменник. Consumers зная обменник создают временные очереди и получают только актуальные сообщения.

Direct exchange можно настроить так, чтобы он работал как fanout exchange, но такая реализация должна быть медленнее из-за ключа маршрутизации. Также и producer и consumer должны знать и про обменник и про очередь, что окажет отрицательное влияние на масштабируемость решения. Фрейм заголовка сообщения также должен содержать ключ маршрутизации.

Если вещание не должно быть бессмысленным (требуется дополнительная фильтрация), то стоит использовать direct exchange.

artemmatveev 20 фев 2020 в 15:53

Знать про очередь необходимо при обмене по умолчанию

Jsty 20 фев 2020 в 17:43

И все же я не увидел ответ на вопрос о реальном примере такого использования. Например, на событие X нужно отправить два разных письма пользователю. Это тот случай, когда к одному exchange будут подключены две очереди; в каждую очередь попадет одно и то же сообщение, но будет два разных потребителя, которые по разной логике обработают это сообщение. Я правильно понял?

artemmatveev 20 фев 2020 в 17:51

Да. Все верно

Calc 4 мар 2020 в 18:15

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

подсчет сообщений определенного типа
разная логика обработки сообщения
логгирование
обновление последнего актуального состояния
передача сообщения «дальше», интеграция
накапливание сообщений (среднее значение, за интервал времени)
Репликация
повышение скорости передачи нескольким слушателям. Fanout работает быстрее чем topic в несколько раз.
Несколько конечных устройств должны получить одно и то же сообщение (пример-чат, пользователь залогинен на 5ти разных устройствах)
Или после топика отдать сразу «всем», так как эксчейнджи биндятся к эксчейнджам.

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