Kafka или RabbitMQ: когда что

↑ 5.4 Очереди и брокеры: Kafka, RabbitMQ · ← Предыдущая · → Следующая

Обязательно~3 мин чтенияУровень: middle

Зачем это на собесе

Сравнение брокеров — популярный архитектурный вопрос.

Объяснение

КритерийKafkaRabbitMQ
Модельраспределённый логброкер очередей с маршрутизацией
Хранениехранит N дней, читают многократноудаляет после ack
Порядоквнутри партициивнутри очереди (при одном потребителе)
Масштабированиепартиции, миллионы событий/свертикально/кластеры, десятки тысяч сообщений/с
Маршрутизацияпростая (топик, ключ)гибкая (exchange, binding, headers)
Повторное чтение / replayданет
Задержки, приоритеты, TTLограниченноиз коробки
Сложность эксплуатациивыше (KRaft, партиции)ниже
Типичное применениеevent streaming, аналитика, event sourcing, интеграция потоковзадачи, RPC, фоновые джобы, маршрутизация команд

Практическое правило:

  • Kafka — потоки событий, высокий объём, переигрываемая история, несколько независимых читателей.
  • RabbitMQ — очереди задач, сложная маршрутизация, приоритеты, delayed, небольшой и средний объём.
  • Иногда нужны оба, но не «на всякий случай».

Другие варианты: Redis Streams, NATS/JetStream, Azure Service Bus, AWS SQS/SNS, Pulsar.

Нюансы и подводные камни

  • Kafka не подходит как очередь задач с индивидуальным ack, приоритетами и delay.
  • RabbitMQ не заменяет журнал событий: нельзя «перемотать» историю.
  • Выбор диктуют требования, а не мода: объём, порядок, ретеншн, команда.
  • Абстракции (MassTransit) помогают переключаться, но не скрывают модель брокера.

Практика

  1. Опишите требования вашего проекта и выберите брокер с обоснованием (ADR).
  2. Сравните throughput одинакового сценария в обоих брокерах.
  3. Спроектируйте, что вы делаете, если нужен replay в RabbitMQ.

Вопросы с ответами

Связанные темы