Очереди сообщений: Kafka и RabbitMQ

Очереди сообщений: Kafka, RabbitMQ

(Раздел: Технологии и Инфраструктура)

Краткое резюме

• Apache Kafka — распределенный журнал событий (log), ориентирован на потоковую обработку, репликацию и горизонтальный скейлинг через партиции.
• RabbitMQ — брокер очередей AMQP с гибкой маршрутизацией (exchanges/bindings), приоритетами, TTL, подтверждениями и классическими задачами очередей.

Оба инструмента зрелые, но решают разные задачи: Kafka — для масштабируемых стримов и аналитики, RabbitMQ — для оперативной оркестрации задач, RPC и многообразной маршрутизации.

Где что уместно в iGaming

• Нужны высокие TPS событий (ставки, игровые события, телеметрия) и горизонтальный скейл через партиции.
• Важен холодный/горячий ре-консюм (повторное чтение лентовых данных), ретеншн и компакшн для агрегатов (баланс, состояние игрока).
• Нужны стрим-процессы (Kafka Streams/ksqlDB/Flink) для realtime-агрегатов: лидеры турниров, лимиты ответственной игры, антифрод-сигналы.

• Нужны классические очереди задач: KYC-проверка, отложенные/повторные выплаты, отправка e-mail/SMS/push, webhooks к PSP.
• Гибкая маршрутизация (topic/direct/fanout), приоритеты, TTL, delay, dead-letter и RPC-паттерны.
• Требуются строгие per-consumer ограничения (prefetch/QoS), простое управление нагрузкой и быстрые ретраи.

Частый итог: Kafka для событий и аналитики + RabbitMQ для оркестрации и интеграций.

Модель данных и маршрутизация

Kafka

Топики → разбиваются на партиции, каждая — упорядоченный лог.
Ключ сообщения определяет партицию → упорядоченность в рамках ключа.
Консьюмеры читают по offset, группы консьюмеров масштабируют обработку.
Ретеншн по времени/объему; log compaction хранит последнюю версию ключа.

RabbitMQ

Exchanges (direct/fanout/topic/headers) + bindings → сообщения попадают в queues.
Подтверждения (ack/nack/requeue), publisher confirms, priorities, TTL, dead-letter (DLX/DLQ).
Quorum queues (Raft) для высокой доступности; lazy queues для экономии RAM.

Гарантии доставки и идемпотентность

At-most-once: без ретраев; риск потерь, минимальная задержка.
At-least-once: стандарт по умолчанию → возможны дубликаты → идемпотентные хендлеры (ключ запроса/транзакции, upsert, dedup-таблица, outbox).
Exactly-once: в Kafka достигается в связке идемпотентный продьюсер + транзакционные топики + согласованное потребление, но чаще дороже и сложнее; в RabbitMQ — ограниченно и с костами. В реальных платежных/ставочных потоках применяется at-least-once + строгая идемпотентность.

• Уникальные idempotency-keys (UUID/ULID) на событие/команду.
• Outbox-паттерн в БД сервиса + Change Data Capture (Debezium) → предотвращение “двойной записи”.
• Dedup по (key, created_at) в отдельном сторе с TTL.

Заказ/порядок сообщений

Kafka гарантирует порядок внутри партиции. Ключ выбирайте так, чтобы в одном ключе оказалась вся “жизнь” сущности (например, `player_id` для баланса).
RabbitMQ порядок не строго гарантирован при повторных доставках/нескольких консьюмерах; критичные к порядку пайплайны — лучше в Kafka или через single-active consumer и сериализацию потока.

Проектирование топиков и очередей

• Гранулярность: `domain.event` (например, `payments.deposit.created`).
• Ключи: `player_id`, `account_id`, `bet_id` для упорядоченности.
• Партиций = N по целевой TPS (правило: 1 партиция ≈ X сообщений/сек/консюмер); закладывать запас на рост.
• Ретеншн: события — часы/дни; компакшн — для “состояний”.

• Exchanges по доменам: `payments.direct`, `risk.topic`.
• Очереди под потребителей: `kyc.checker.q`, `psp.webhooks.retry.q`.
• DLQ на каждую рабочую очередь; delay для backoff.
• Prefetch задает параллелизм, очереди quorum — для HA.

Ошибки, ретраи и DLQ

Классифицируйте ошибки: временные (сетевые/PSP 5xx) → ретраи; фатальные (валидация, схема) → сразу DLQ.
Exponential backoff + jitter, лимит ретраев, “poison-pill” детектирование.
Отдельные retry-queues по шагам (5s, 1m, 5m, 1h).
DLQ-обработчик: алерт, трейс, ручной разбор, ре-инжект с патчем.

Контракт данных и схемы

Используйте Avro/Protobuf + Schema Registry (для Kafka — стандарт де-факто).
Версионирование: backward-compatible изменения (добавление опциональных полей), запрет на ломающие миграции.
Поля PII — шифрование/токенизация; соблюдайте GDPR и локальные нормы.

Мониторинг, наблюдаемость и SLO

Метрики продьюсеров/консьюмеров: lag, throughput, ошибки, ретраи, время обработки.
Логи + трейсинг (корреляционные ID: `trace_id`, `message_id`).
SLO: p99-латентность публикации/доставки, допустимый consumer lag, время восстановления после фейлов.
Алерты на рост DLQ, превышение lag, падение партиций/кворума.

Безопасность и комплаенс

TLS в транзите, шифрование секретов (SOPS/Vault), ограниченные ACL/RBAC.
Отдельные топики/очереди для чувствительных доменов (платежи, KYC).
Аудит-лог публикаций/подписок, хранение ключей вне кода.
Региональные требования (EU/Турция/ЛатАм): ретеншн, локализация хранения, маскирование.

Высокая доступность, отказоустойчивость и DR

• Кластер 3–5 брокеров минимум; replication.factor ≥ 3.
• min.insync.replicas и acks=all для прочных записей.
• Кросс-региональные репликации (MirrorMaker-2) для DR.

• Quorum queues для HA, четное/нечетное число нод с кворумом.
• Federation/Shovel для меж-ЦОД репликации, DR-сценариев.
• Холодный/теплый стенд, тесты переключения.

Производительность и тюнинг

• `linger.ms` и `batch.size` для батчинга; `compression.type` (lz4/zstd).
• `acks=all`, но следить за латентностью; тюн `max.in.flight.requests.per.connection` с идемпотентностью.

• Достаточно партиций; диски NVMe; сетка 10/25G; GC-настройки JVM.

• Правильный group management, `max.poll.interval.ms`, паузить партиции при бэкофе.

• Publisher confirms в батчах; channels переиспользовать.

• `prefetch` (напр. 50–300) по времени обработки; lazy queues для больших бэклогов.
• Разносить горячие очереди по нодам; тюн TCP/файловые дескрипторы.

Типовые паттерны для iGaming

Outbox + Kafka для надежной публикации доменных событий (ставка размещена, депозит зачислен).
RabbitMQ RPC для синхронных запросов к интеграциям (проверка документа KYC, расчет бонуса).
Сага-паттерн: оркестрация через события (Kafka) и команды (RabbitMQ) с компенсирующими шагами.
Fan-out уведомлений: из одного события → CRM, антифрод, аналитика.
Smart-retry PSP-вебхуков с прогрессивными задержками и DLQ.

Миграция и гибридные архитектуры

Начните с RabbitMQ для “операционки”, добавьте Kafka для событий и аналитики.
Дублируйте публикации: сервис → outbox → коннектор в обе стороны (Kafka + RabbitMQ) до полной стабилизации.
Постепенно переносите подписчиков аналитики/стрим-агрегаций на Kafka Streams/ksqlDB.

Мини-чек-лист выбора

1. Нагрузка/TPS > десятков тысяч/сек? → Kafka.
2. Нужен ретеншн и повторное чтение как из журнала? → Kafka.
3. Гибкая маршрутизация, приоритеты, отложенная доставка, RPC? → RabbitMQ.
4. Строгий порядок по ключу и горизонтальный скейл → Kafka (ключ/партиции).
5. Простые задачи/ворк-кью с управлением параллелизмом → RabbitMQ.
6. В идеале — комбинация: Kafka (события) + RabbitMQ (оркестрация).

Примеры минимальных конфигураций

Пример: задержанные ретраи и DLQ в RabbitMQ (через policy)

Рабочая очередь: `psp.webhooks.q`

Очередь ретраев: `psp.webhooks.retry.1m.q` (TTL=60s, DLX указывает назад на рабочую)

DLQ: `psp.webhooks.dlq`

• `psp.webhooks.q` → `x-dead-letter-exchange=psp.retry.exchange`
• `psp.webhooks.retry.1m.q` → `x-message-ttl=60000`, `x-dead-letter-exchange=psp.work.exchange`
• `psp.webhooks.dlq` → мониторинг и ручной разбор.

Пример: топик Kafka для ставок

Топик: `bets.placed.v1`, партиции: 24, RF=3, ретеншн 7 дней.
Ключ сообщения: `player_id` или `bet_id` (выберите, что важнее для порядка).
Схема: Protobuf/Avro с `bet_id`, `player_id`, `stake`, `odds`, `ts`, `idempotency_key`.

Тестирование и качество

Contract-тесты продьюсер/консьюмер + проверки схем (Schema Registry).
Chaos-тесты: падение нод, задержки сети, split-brain.
Нагрузочные прогоны с целевым TPS, проверка p99, рост lag и восстановление.

Итоги

Kafka — магистраль событий и стриминг: упорядоченность по ключу, ретеншн/компакшн, высокие TPS, аналитика в реальном времени.
RabbitMQ — операционная очередь задач: гибкая маршрутизация, подтверждения, приоритеты, ретраи/DLQ, RPC.
В iGaming наилучшая практика — комплементарное использование: события и аналитика в Kafka, интеграционные/оркестрационные задачи в RabbitMQ, с едиными стандартами схем, идемпотентностью, мониторингом и строгими SLO.