Очереди сообщений. Основные понятия

Очереди сообщений помогают справится с высокой нагрузкой, сокращают время ответа за счёт асинхронной обработки и предотвращает потерю информации при сбоях.

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

🔹 Сообщения могут содержать любые данные, необходимые для выполнения какой-либо операции.

🔹 Компонент, который добавляет сообщение в очередь, называется производителем (Producer).

🔹 Компонент, который извлекает сообщение из очереди и обрабатывает его, называется потребителем (Consumer).

Очередь может использоваться несколькими производителями и потребителями одновременно.

Два подхода к обмену сообщениями

➡️ Метод Pull: потребитель периодически опрашивает очередь на наличие новых сообщений и извлекает их по одному или нескольким за раз.

⬅️ Метод Push: очередь уведомляет потребителя о поступлении нового сообщения и отправляет его ему. Этот метод реализует модель “Издатель/Подписчик” (Publisher/Subscriber), когда потребитель подписывается на определенный тип или тему сообщений и получает только те сообщения, которые ему нужны.

Типы гарантии доставки сообщений

1️⃣ At least once: производитель отправляет сообщение в очередь и ждет подтверждения от брокера. Потребитель извлекает сообщение из очереди и отправляет подтверждение о его обработке. Если производитель не получает подтверждения от брокера, он повторно отправляет сообщение. Сообщение будет обработано хотя бы один раз, но при этом возможны ситуации, когда одно и то же сообщение будет обработано несколько раз. Например, когда соединение прервется в момент отправки или получения подтверждения. Для предотвращения последствий дублирования сообщений необходимо, чтобы компоненты были идемпотентными, то есть повторная обработка одного и того же сообщения не приводила бы к изменению состояния системы или ее данных. Также можно использовать уникальные id для сообщений и хранить список уже обработанных сообщений.

2️⃣ At most once: производитель отправляет сообщение в очередь и не ждёт подтверждения от брокера. Потребитель извлекает сообщение из очереди и не отправляет подтверждение о его обработке. Исключается возможность дублирования сообщений, но при этом сообщение может быть потеряно. Например, когда брокер не сможет сохранить сообщение в очереди или потребитель упадет во время обработки сообщения. Этот тип доставки подходит для тех случаев, когда двойная обработка сообщения может привести к серьезным проблемам, а потеря сообщения не является критичной.

3️⃣ Exactly once. Брокер гарантирует, что каждое сообщение будет доставлено и обработано ровно один раз, без потерь или дублирования. Этот тип доставки является самым желательным, но также самым сложным в реализации. Производитель отправляет сообщение в очередь и ждет подтверждения от брокера о его приеме. Потребитель извлекает сообщение из очереди и отправляет подтверждение об обработке.
В реальности полностью исключить вероятность потери или дублирования сообщений невозможно, поэтому этот тип доставки часто реализуется с некоторыми оговорками или допущениями.

Протоколы

🌐 AMQP — бинарный протокол, который проектировался для взаимодействия между различными вендорами. Основными особенностями AMQP является надежность и совместимость.

🌐 STOMP — простой текстовый протокол обмена сообщениями, который очень похож на HTTP и работает поверх TCP.

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

📎 Ссылки
1. Асинхронное взаимодействие. Брокеры сообщений
2. Очереди сообщений
3. Apache Kafka: основы технологии
4. Очереди сообщений в бэкенд-архитектуре: как построить надежную систему
5. Стратегии доставки и дедупликации сообщений

#интеграции #async