Настройка очередей сообщений (RabbitMQ/Kafka) для мобильного приложения
Когда мобильный клиент отправляет запрос на покупку, он не должен ждать, пока сервер обработает платёж, обновит инвентарь, начислит бонусы, отправит email и push. Очередь сообщений разрывает эту синхронную цепочку — HTTP-обработчик записывает задачу и сразу отвечает 202 Accepted.
RabbitMQ или Kafka — чем руководствоваться
Не нужно выбирать «который лучше» — они решают разные задачи.
RabbitMQ — message broker с routing, приоритетами, dead-letter queues. Задача «выполнить что-то один раз» (отправить email, транскодировать видео, обновить запись в БД). Consumer подтвердил обработку (basic.ack) — сообщение удалено. Простая операционная модель, Management UI из коробки.
Kafka — distributed log. Задача «хранить поток событий для нескольких потребителей, с возможностью воспроизведения». user.registered — подписаны analytics-сервис, email-сервис, CRM. Каждый читает независимо, со своим offset'ом. При ошибке — перечитывает с нужной позиции. RabbitMQ так не умеет.
| Критерий | RabbitMQ | Kafka |
|---|---|---|
| Задача «выполнить один раз» | Да | Неудобно |
| Несколько независимых потребителей | Через Fanout Exchange | Нативно (consumer groups) |
| Replay событий | Нет | Да (retention period) |
| Порядок сообщений | В рамках одной очереди | В рамках одной партиции |
| Операционная сложность | Низкая | Высокая (ZooKeeper / KRaft) |
Настройка для типичного мобильного приложения
Push-уведомления через RabbitMQ. HTTP-обработчик публикует {user_id, title, body, data} в очередь push.notifications. Workers (несколько параллельных) читают, отправляют через FCM/APNs. Dead-letter queue push.notifications.failed — для сообщений, которые не удалось отправить после N попыток. Periodic job анализирует DLQ и либо повторяет, либо логирует.
Критично: prefetch_count = 1 для воркеров, которые делают HTTP-вызовы (FCM, APNs). Без этого RabbitMQ отдаст воркеру 250 сообщений сразу, тот зависнет на rate limit Firebase, а остальные сообщения будут ждать неподтверждёнными.
Kafka для event streaming. Пример: аналитика действий пользователей в мобильном приложении. Каждый тап, скролл, просмотр экрана — событие в топике mobile.user.events. Consumers: real-time dashboard (Flink), hourly batch (Spark), A/B testing сервис. Retention: 7 дней. Партиций: 24 (по числу воркеров в пике). Ключ партиции — user_id, чтобы события одного пользователя шли в одну партицию и сохраняли порядок.
Кейс: маркетплейс с мобильным приложением, 60 000 заказов в день. Обработка заказа синхронно занимала 1.2 секунды: проверка остатков, резервирование, начисление кешбэка, отправка email + push. Пользователь ждал. После введения RabbitMQ: HTTP-обработчик записывает заказ в PostgreSQL и публикует order.created — ответ за 80ms. Воркеры асинхронно выполняют остальное. Пользователь получает push через 3–5 секунд вместо того чтобы смотреть на спиннер.
Идемпотентность — обязательное условие
Брокеры не гарантируют «exactly once» в общем случае. RabbitMQ с at-least-once доставкой — consumer может получить одно сообщение дважды при reconnect. Consumer должен быть идемпотентным: повторная обработка не создаёт дублей. Способ: уникальный message_id в БД, INSERT ... ON CONFLICT DO NOTHING.
Сроки: RabbitMQ для push + базовых задач — 3–5 дней. Kafka-кластер с мониторингом, Schema Registry, consumer groups для нескольких сервисов — 2–3 недели.