Пейджер

🌍 Привет мир! 👋

🌍 Привет мир! 👋

Большое количество проектов идут по пути микросервисной архитектуры, при таком подходе большое внимание уделяется асинхронной коммуникации и реализуется это за счет брокеров сообщений. Тема актуальная, поэтому встречаем один из часто используемых брокеров #RABBITMQ.

🚀 Мотивация

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

📝 Core понятия RabbitMQ

📌 Producer - приложение, которое отправляет сообщения.
📌 Queue - буфер (очередь), место хранения сообщений.
📌 Consumer - приложение, которое получает сообщения.
📌 Exchange - посредник, выполняет роль маршрутизитора между Producer и Queue.
📌 Binding - «связь», которая создается между queue и exchange.
📌 Routing key - атрибут сообщения, на который обращает внимание exchange при принятии решения о том в какую очередь отправить сообщение.

❓ Что такое EXCHANGE

В RabbitMQ producer не отправляет сообщения напрямую в queue. Producer может отправлять сообщения только в exchange. Exchange c одной стороны принимает сообщения от producer, а с другой стороны передает их в queue. Exchange должен знать, что делать с полученным сообщением. Должно ли оно быть добавлено в конкретную queue? Или в несколько queues? Или оно должно быть отклонено? Правила для этого определяются типом exchange.

⚒️ Типы exchange

📎 Direct это самый простой exchange, сообщение отправляется в ту очередь, c которой есть связь (Binding) и точно совпадает routing key сообщения с routing key в связи.

✏️Пример:
📌 exchange = users-exchange
📌 queue = user-registration-queue
📌 routing key = user-registration

📎 Queue привязана к Exchange, c помощью routing key, таким образом, когда придет новое сообщение с ключом маршрутизации user-registration, оно будет направлено в очередь user-registration-queue.

⚠️ Если routing key сообщения не соответствует ни одному ключу привязки, сообщение отбрасывается.

⚠️ Если к exchange привязано более одной очереди с одним и тем же routing key, сообщение будет отправлено всем соответствующим очередям.

📎 Topic очень похож на direct, но маршрутизацию можно выполнить не только с помощью фиксированного routing key, а также с использованием routing pattern.
Сообщения направляются в одну или несколько очередей на основе routing key сообщения и routing pattern, который задан при создании связи между exchange и queue.
Pattern создается с помощью слов через точку и опциональных специальных символов:

📌 * star - может заменить одно любое слово.
📌 # hash - может заменить ноль или более слов.

📝 Пример routing pattern:

1. aaa.*
2. aaa.#

Cообщение с routing key = aaa.bbb будет отправлено в обе очереди, но если взять routing key = aaa.bbb.ccc то только во вторую.

📎 Fanout копирует и направляет сообщения во все очереди, привязанные к нему, независимо от routing key.

📎 Headers, при таком типе exchange, routing key также не учитывается, но вместо ключа идет проверка на соотношение значений в headers message. Заголовки в данном случае представляют из себя key-value пары, прям как в объекте.
key-value пара указанная в сообщении должна соответствовать паре ключ-значение, указанной в binding. Поскольку у сообщения может быть несколько значений headers, можно выбрать, все ли они должны быть точно такими, как указано в привязке или достаточно, чтобы соответствовало какое-либо одно из них.
Это можно указать, добавив к привязке специальный аргумент x-match со значением:

📌 all - означает, что все пары заголовков (ключ, значение) должны совпадать.
📌 any - должна совпадать хотя бы одна из пар заголовков.

⚠️ all - это значение по умолчанию, если x-match не указан.

Есть еще Default Exchange и Dead Letter Exchange, но о них следующий раз.

💬 Делитесь своим мнением в комментариях👇! Если вам понравилась статья, не забудьте поставить лайк👍
Медиа 1
Хотите больше таких постов?
Подпишитесь на канал и читайте продолжение в Telegram.
Подписаться на @ivanchikovitclub Открыть пост в Telegram