Комментарии 10
Спасибо! Вторая замечательная статья! Очень подробно и понятно.
В каких случаях может использоваться fanout exchange? Какой реальный usecase использования доставки одного сообщения в несколько очередей? Возможно, вопрос покажется глупым, но мне, к сожалению (или к счастью) не приходилось сталкиваться с такими задачами. Всегда хватало direct exchange.
Применение fanout exchange можно представить в контексте микросервисов. Например, бессмысленное вещание события на которое должны реагировать определенные потребители. Producer определяет только обменник. Consumers зная обменник создают временные очереди и получают только актуальные сообщения.
Direct exchange можно настроить так, чтобы он работал как fanout exchange, но такая реализация должна быть медленнее из-за ключа маршрутизации. Также и producer и consumer должны знать и про обменник и про очередь, что окажет отрицательное влияние на масштабируемость решения. Фрейм заголовка сообщения также должен содержать ключ маршрутизации.
Если вещание не должно быть бессмысленным (требуется дополнительная фильтрация), то стоит использовать direct exchange.
Direct exchange можно настроить так, чтобы он работал как fanout exchange, но такая реализация должна быть медленнее из-за ключа маршрутизации. Также и producer и consumer должны знать и про обменник и про очередь, что окажет отрицательное влияние на масштабируемость решения. Фрейм заголовка сообщения также должен содержать ключ маршрутизации.
Если вещание не должно быть бессмысленным (требуется дополнительная фильтрация), то стоит использовать direct exchange.
Знать про очередь необходимо при обмене по умолчанию
И все же я не увидел ответ на вопрос о реальном примере такого использования. Например, на событие X нужно отправить два разных письма пользователю. Это тот случай, когда к одному exchange будут подключены две очереди; в каждую очередь попадет одно и то же сообщение, но будет два разных потребителя, которые по разной логике обработают это сообщение. Я правильно понял?
Да. Все верно
Всё зависит от той логики, которая вам нужна. То что ниже можно и в одном сервисе делать, но в разных архитектура чище и управление более гибкое.
А статьи очень похожи на перевод официальной документации. Если хотите поближе понять очереди и профит, поищите как был реализован инстаграмм на первых этапах, там связь реббита с редисом есть, видео было где то на ютубе
- подсчет сообщений определенного типа
- разная логика обработки сообщения
- логгирование
- обновление последнего актуального состояния
- передача сообщения «дальше», интеграция
- накапливание сообщений (среднее значение, за интервал времени)
- Репликация
- повышение скорости передачи нескольким слушателям. Fanout работает быстрее чем topic в несколько раз.
- Несколько конечных устройств должны получить одно и то же сообщение (пример-чат, пользователь залогинен на 5ти разных устройствах)
- Или после топика отдать сразу «всем», так как эксчейнджи биндятся к эксчейнджам.
А статьи очень похожи на перевод официальной документации. Если хотите поближе понять очереди и профит, поищите как был реализован инстаграмм на первых этапах, там связь реббита с редисом есть, видео было где то на ютубе
Спасибо, www.youtube.com/watch?v=E708csv4XgY — думаю, речь про это.
В случае x-match=all, должно ли совпадение быть полным или хедеры привязки должны только быть подмножеством хедеров обменника?
Годная статья!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
RabbitMQ. Часть 2. Разбираемся с Exchanges