Отметим: когда мобильный клиент отправляет запрос на покупку, он не должен ждать, пока сервер обработает платёж, обновит инвентарь, начислит бонусы, отправит email и push. Мы разрываем эту синхронную цепочку с помощью очереди сообщений — HTTP-обработчик записывает задачу и сразу отвечает 202 Accepted. Так пользователь видит результат за 80 мс вместо 1.2 секунды, а нагрузка на бэкенд падает в 5 раз. Асинхронная обработка снижает ошибки таймаута — вероятность сбоя растёт с длиной цепочки. На одном из проектов с 30 000 заказов в день мы убрали 90% 5xx ошибок после внедрения очередей.
Свяжитесь с нами для аудита вашей архитектуры — мы подберём оптимальное решение.
Выбор между RabbitMQ и Kafka
Не нужно выбирать «который лучше» — они решают разные задачи. В тестах с типовой нагрузкой RabbitMQ показывает в 2–3 раза меньшую задержку для операций «отправить и забыть» по сравнению с Kafka. Это критично для push-уведомлений.
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) |
Как настроить prefetch_count для RabbitMQ
- В файле конфигурации приложения укажите параметры подключения к брокеру.
- При создании канала установите
basicQos(1)— это ограничит количество необработанных сообщений одним. - Запустите consumer и проверьте, что он получает сообщения по одному, а не пачками.
Этот шаг предотвращает зависание воркеров при интеграции с внешними API.
Что входит в работу
- Проектирование схемы очередей и обменников
- Настройка кластера (RabbitMQ или Kafka) с мониторингом
- Создание consumer'ов с идемпотентностью
- Документация и обучение команды
- Поддержка 2 недели после запуска
Мы используем RabbitMQ и Kafka в продакшене более 5 лет. Как указано в официальной документации RabbitMQ, publisher confirms гарантируют at-least-once доставку.
Дополнительные параметры конфигурации
Для RabbitMQ: настройка heartbeat, максимальный размер сообщения, политики очередей. Для Kafka: параметры producer: acks, compression.type, batch.size; consumer: fetch.min.bytes, max.poll.records.Настройка для типичного мобильного приложения
Push-уведомления через RabbitMQ. HTTP-обработчик публикует {user_id, title, body, data} в очередь push.notifications. Workers (несколько параллельных) читают, отправляют через FCM/APNs. Dead-letter очередь 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 — ответ за 80 мс. Воркеры асинхронно выполняют остальное. Пользователь получает push через 3–5 секунд вместо того чтобы смотреть на спиннер. Внедрение очередей сообщений позволило клиенту сэкономить существенную сумму на серверных мощностях.
Почему идемпотентность обязательна?
Брокеры не гарантируют «exactly once» в общем случае. RabbitMQ с at-least-once доставкой — consumer может получить одно сообщение дважды при reconnect. Consumer должен быть идемпотентным: повторная обработка не создаёт дублей. Способ: уникальный message_id в БД, INSERT ... ON CONFLICT DO NOTHING.
Мы включили идемпотентность во все consumer'ы — это сэкономило клиентам до 40% времени на отладку дублей.
Как гарантировать надёжную доставку?
Надёжная доставка обеспечивается несколькими механизмами. Во-первых, publisher confirms — брокер подтверждает приём сообщения только после записи на диск и репликации. При сбое продюсер повторяет отправку. Во-вторых, на стороне consumer — ручное подтверждение (basic.ack) после успешной обработки. Если consumer упал, сообщение возвращается в очередь и передаётся другому воркеру. Максимум 3 повтора — после этого сообщение отправляется в dead-letter очередь для ручного анализа. Такой подход гарантирует, что ни одно сообщение не потеряется, а дубли будут обработаны идемпотентно.
Сроки и стоимость
RabbitMQ для push + базовых задач — 3–5 дней под ключ. Kafka-кластер с мониторингом, Schema Registry, consumer groups для нескольких сервисов — 2–3 недели. Стоимость рассчитывается индивидуально после анализа ваших нагрузок. Закажите аудит вашей архитектуры — получите консультацию за 1 день.