Что такое асинхронная очередь
В синхронной модели отправитель делает запрос и ждёт ответа: если получатель медленный или временно недоступен — весь поток зависает. Асинхронная очередь сообщений разрывает эту зависимость. Отправитель помещает сообщение в брокер (Kafka, RabbitMQ, SQS) и сразу продолжает работу. Получатель — потребитель очереди — забирает и обрабатывает сообщения в своём темпе.
Продюсер → [очередь: событие_просмотр, событие_корзина, событие_покупка] → Потребитель
↑ буферизует при пике ↑ обрабатывает независимо
Зачем это нужно в e-commerce
В e-commerce трафик нередко вырастает в 10–20 раз в периоды распродаж. При синхронной интеграции платформа персонализации может стать узким местом: если она не успевает принять события — они теряются или замедляют основной сайт.
Очередь решает эту проблему тремя способами:
- Буферизация пиков. Все события во время всплеска попадают в очередь — сайт не ждёт их обработки.
- Надёжная доставка. Брокер удерживает сообщение до тех пор, пока получатель не подтвердит обработку.
- Развязка систем. Если платформа персонализации на секунду недоступна — события не теряются, они просто накапливаются и обрабатываются после восстановления.
Ключевые характеристики брокеров
| Параметр | Kafka | RabbitMQ | AWS SQS |
|---|---|---|---|
| Пропускная способность | Очень высокая | Средняя | Высокая |
| Порядок сообщений | Внутри партиции | FIFO в очереди | Стандартная: не гарантируется; FIFO-очередь: гарантируется |
| Хранение сообщений | Долгосрочное (реплей) | Временное | До 14 дней |
| Управление | Самостоятельное | Самостоятельное | Managed |
Важно: при асинхронной обработке событий персонализации (просмотр → добавление в корзину → покупка) критически важно сохранять порядок событий на уровне пользователя. Kafka решает это через партиционирование по user_id.
Гарантии доставки
Брокеры поддерживают разные модели гарантий:
- At-most-once — сообщение доставляется не более одного раза, но может потеряться.
- At-least-once — доставка гарантирована, но возможны дубликаты. Требует идемпотентной обработки на стороне получателя.
- Exactly-once — строгая однократная доставка; реализована в Kafka Transactions и SQS FIFO, требует дополнительных накладных расходов.
Для событий типа «покупка» используйте at-least-once с дедупликацией по уникальному идентификатору события.
Типичные ошибки
- Блокирующий вызов без таймаута. Если очередь перегружена и отправитель ждёт место в буфере — это снова синхронный сценарий. Устанавливайте жёсткие таймауты на publish.
- Нет мониторинга lag-а. Consumer lag — отставание потребителя от продюсера — ключевая метрика здоровья очереди. Игнорирование lag приводит к тому, что данные доходят с большой задержкой.
- Идемпотентность на уровне идей. Алгоритм обработки должен уметь корректно обработать одно и то же событие дважды — без дублирования покупок или двойного зачисления баллов.