Kafka vs RabbitMQ

Kafka — это распределённый журнал (log) для потоков событий с высокой нагрузкой (миллионы/сек), хранением истории и возможностью replay, но без приоритетов и сложной маршрутизации. RabbitMQ — классическая очередь (queue) для задач со сложной маршрутизацией, приоритетами, отложенными сообщениями и RPC, но с удалением сообщений после прочтения и нагрузкой до десятков тысяч/сек. Выбор зависит от задачи: RabbitMQ для обработки заказов и фоновых задач, Kafka для аналитики, CDC и event sourcing.

Введение: Два великих, но разных

Если вы когда-либо выбирали брокер сообщений, вы сталкивались с этой дилеммой: Kafka или RabbitMQ? Оба популярны. Оба надёжны. Оба решают задачи асинхронной передачи данных. Но они решают разные задачи.

Kafka — это не “очередь”. Это распределённый журнал (log). RabbitMQ — это классическая очередь сообщений.

Сравнивать Kafka и RabbitMQ — всё равно что сравнивать грузовик и такси. Оба — транспорт, но один возит тонны угля, другой — пассажиров по городу. Вопрос не “что лучше”, а “что подходит для вашей задачи”.

Для системного аналитика понимание различий между Kafka и RabbitMQ — это ключ к правильному выбору. Ошибка на этом уровне приводит к тому, что система либо не выдерживает нагрузки (выбрали RabbitMQ для high-load), либо неоправданно сложна (выбрали Kafka для очереди задач).

Основное различие: Журнал vs Очередь

Kafka: Журнал (Log)

Модель:
  - Сообщения хранятся в журнале (log)
  - Имеют смещение (offset)
  - Не удаляются после прочтения
  - Могут быть прочитаны снова (replay)

Аналогия: банковская выписка
  - Все операции записаны
  - Можно перечитать с любого места
  - Ничего не удаляется

RabbitMQ: Очередь (Queue)

Модель:
  - Сообщения хранятся в очереди
  - После прочтения удаляются (при ack)
  - Нельзя перечитать

Аналогия: очередь в магазине
  - Клиент подошёл к кассе — ушёл из очереди
  - Нельзя вернуться в очередь после обслуживания

Сравнение по ключевым параметрам

Параметр	Kafka	RabbitMQ
Модель	Журнал (log)	Очередь (queue)
После прочтения	Сообщение остаётся	Сообщение удаляется
Replay	Да (можно перечитать)	Нет
Порядок сообщений	Внутри партиции	Внутри очереди
Маршрутизация	Простая (топики)	Гибкая (exchanges, bindings)
Пропускная способность	Миллионы/сек	Десятки тысяч/сек
Задержка (латентность)	Миллисекунды	Миллисекунды (ниже)
Хранение данных	Длительное (retention)	До подтверждения
Приоритеты	Нет	Да
Отложенные сообщения	Нет	Да (плагин)
RPC	Сложно	Да (reply_to)
Простота	Высокая (настройка)	Средняя
Язык	Scala/Java	Erlang
Типичное применение	Потоки событий, аналитика	Очереди задач, маршрутизация

Модель хранения

Kafka

Структура:
  - Топик → партиции → сообщения с offset
  - Сообщения хранятся на диске (сегменты)
  - Retention: по времени (7 дней) или объёму

После прочтения:
  - Сообщение остаётся в журнале
  - Consumer запоминает свой offset
  - Новый consumer может прочитать всё с начала

RabbitMQ

Структура:
  - Очередь → сообщения
  - Сообщения хранятся в памяти или на диске
  - При подтверждении (ack) удаляются

После прочтения:
  - Сообщение удаляется
  - Другой consumer не может его прочитать
  - Replay невозможен

Порядок сообщений

Kafka

Гарантии:
  - Порядок гарантирован внутри партиции
  - Глобальный порядок только с одной партицией

Пример:
  - Топик: user_events (3 партиции)
  - Ключ: user_id
  - Все события одного пользователя → в одну партицию
  - Порядок для пользователя гарантирован

RabbitMQ

Гарантии:
  - Порядок гарантирован внутри очереди
  - Если несколько потребителей — порядок не гарантирован

Пример:
  - Одна очередь, один потребитель → порядок гарантирован
  - Одна очередь, два потребителя → порядок не гарантирован

Маршрутизация

Kafka

Возможности:
  - Простая: топики
  - Фильтрация на стороне потребителя
  - Нет сложных правил

Пример:
  - Топик: user.events
  - Все сообщения в один топик
  - Потребитель сам фильтрует

RabbitMQ

Возможности:
  - Гибкая: exchanges + bindings
  - Типы: direct, topic, fanout, headers
  - Фильтрация на стороне брокера

Пример:
  - Exchange: events.topic
  - Binding: crm.queue ← routing_key "user.*"
  - Binding: billing.queue ← routing_key "order.paid"

Пропускная способность

Kafka

Производительность:
  - Миллионы сообщений в секунду
  - Пакетная обработка
  - Zero-copy
  - Page cache

Пример:
  - 1 миллион сообщений/сек — нормально
  - 100 миллионов/сек — возможно с кластером

RabbitMQ

Производительность:
  - Десятки тысяч сообщений в секунду
  - Поштучная обработка
  - Меньше оптимизаций

Пример:
  - 50 000 сообщений/сек — нормально
  - 200 000 сообщений/сек — предел

Задержка (латентность)

Kafka

Задержка:
  - Может быть выше из-за пакетной обработки
  - batch.size и linger.ms влияют
  - Типично: 5-50 мс

Пример:
  - Настройка: linger.ms=0 → задержка ниже
  - Но: меньше пакетов → ниже пропускная способность

RabbitMQ

Задержка:
  - Очень низкая (миллисекунды)
  - Нет пакетной обработки по умолчанию

Пример:
  - 1-5 мс — типично
  - Подходит для real-time

Хранение истории

Kafka

Возможности:
  - Сообщения хранятся дни, недели, месяцы
  - Можно перечитать историю
  - Можно подключить нового потребителя и прочитать всё

Пример:
  - retention.ms=604800000 (7 дней)
  - Новый сервис читает все события за 7 дней

RabbitMQ

Возможности:
  - Сообщения хранятся только до подтверждения
  - История недоступна

Пример:
  - Новый сервис не может прочитать старые сообщения
  - Нужно хранить историю отдельно

Приоритеты и отложенные сообщения

Kafka

Приоритеты:
  - Нет встроенной поддержки
  - Можно эмулировать через отдельные топики

Отложенные сообщения:
  - Нет встроенной поддержки
  - Нужен отдельный механизм

RabbitMQ

Приоритеты:
  - Да (x-max-priority)
  - Очередь обрабатывает высокий приоритет раньше

Отложенные сообщения:
  - Да (плагин delayed-message-exchange)
  - x-delayed-message

RPC (Remote Procedure Call)

Kafka

Поддержка:
  - Не предназначен для RPC
  - Request-response сложен
  - Нужно два топика и корреляция

Вывод: не использовать для RPC

RabbitMQ

Поддержка:
  - Встроенный паттерн RPC
  - reply_to queue
  - correlation_id

Пример:
  - Клиент: отправляет с reply_to
  - Сервер: отвечает в reply_to

Простота использования

Kafka

Сложность:
  - Требует ZooKeeper (или KRaft)
  - Конфигурация сложнее
  - Понятия: партиции, offset, consumer group

Вывод: крутая кривая обучения

RabbitMQ

Сложность:
  - Проще настройка
  - Меньше концепций
  - Management UI

Вывод: ниже порог входа

Когда использовать Kafka

Признаки:
  - Высокая нагрузка (>100k msg/sec)
  - Нужно хранить историю (replay)
  - Потоковая обработка (Kafka Streams)
  - Событийная архитектура
  - Аналитика на потоковых данных
  - Несколько независимых потребителей

Примеры:
  - Логи и метрики
  - CDC (Change Data Capture)
  - Event sourcing
  - Аналитика реального времени

Когда использовать RabbitMQ

Признаки:
  - Средняя нагрузка (<50k msg/sec)
  - Низкая задержка критична
  - Сложная маршрутизация
  - Приоритеты сообщений
  - Отложенные сообщения
  - RPC
  - Очереди задач (work queues)

Примеры:
  - Обработка заказов
  - Отправка email
  - Фоновые задачи
  - Веб-сокеты (через STOMP)

Пример: Интернет-магазин

Сценарий 1: Обработка заказов

Требования:
  - Заказ не должен потеряться
  - Несколько воркеров обрабатывают заказы
  - VIP-заказы с приоритетом
  - При ошибке повтор через 5 минут

Выбор: RabbitMQ

Почему:
  - Очередь задач
  - Приоритеты
  - Отложенные сообщения
  - Подтверждения (ack)

Сценарий 2: Аналитика действий пользователей

Требования:
  - 1 млн событий в секунду
  - Хранить события 30 дней
  - Несколько систем анализируют события
  - Новый сервис может прочитать историю

Выбор: Kafka

Почему:
  - Высокая нагрузка
  - Хранение истории
  - Replay
  - Потоковая обработка

Гибридный подход

Часто используют оба брокера вместе.

Архитектура:
  - RabbitMQ: очереди задач, RPC, приоритеты
  - Kafka: потоки событий, аналитика, хранение

Пример:
  - Заказ пришёл → RabbitMQ (обработка)
  - Заказ обработан → Kafka (событие для аналитики)
  - Kafka → аналитика, CRM, биллинг

Распространённые ошибки

Ошибка 1: Kafka для очереди задач

Используют Kafka для обработки заказов. Сообщения не удаляются, offset управлять сложно.

Решение: RabbitMQ.

Ошибка 2: RabbitMQ для high-load

Пытаются обрабатывать миллионы сообщений/сек через RabbitMQ.

Решение: Kafka.

Ошибка 3: Kafka для низкой задержки

Нужна задержка <1 мс. Kafka не гарантирует.

Решение: RabbitMQ или NATS.

Ошибка 4: RabbitMQ для replay

Нужно перечитать историю сообщений. RabbitMQ не хранит.

Решение: Kafka.

Ошибка 5: Неправильный выбор подхода

Выбирают Kafka, потому что “это модно”. Или RabbitMQ, потому что “знаком”.

Решение: Анализировать требования: нагрузка, история, задержка, маршрутизация.

Резюме

Kafka и RabbitMQ решают разные задачи. Kafka — для потоков событий и высокой нагрузки. RabbitMQ — для очередей задач и сложной маршрутизации.
Kafka — журнал (log). Сообщения остаются, можно перечитать. Миллионы сообщений/сек. Нет приоритетов, отложенных сообщений, сложной маршрутизации.
RabbitMQ — очередь (queue). Сообщения удаляются после прочтения. Десятки тысяч сообщений/сек. Приоритеты, отложенные сообщения, RPC.
Выбирайте Kafka для: высокой нагрузки, хранения истории, потоковой обработки, аналитики.
Выбирайте RabbitMQ для: очередей задач, сложной маршрутизации, приоритетов, RPC, низкой задержки.
Не бойтесь гибридных подходов. Оба брокера могут жить вместе.

Kafka vs RabbitMQ

Введение: Два великих, но разных

Основное различие: Журнал vs Очередь

Kafka: Журнал (Log)

RabbitMQ: Очередь (Queue)

Сравнение по ключевым параметрам

Модель хранения

Kafka

RabbitMQ

Порядок сообщений

Kafka

RabbitMQ

Маршрутизация

Kafka

RabbitMQ

Пропускная способность

Kafka

RabbitMQ

Задержка (латентность)

Kafka

RabbitMQ

Хранение истории

Kafka

RabbitMQ

Приоритеты и отложенные сообщения

Kafka

RabbitMQ

RPC (Remote Procedure Call)

Kafka

RabbitMQ

Простота использования

Kafka

RabbitMQ

Когда использовать Kafka

Когда использовать RabbitMQ

Пример: Интернет-магазин

Сценарий 1: Обработка заказов

Сценарий 2: Аналитика действий пользователей

Гибридный подход

Распространённые ошибки

Ошибка 1: Kafka для очереди задач

Ошибка 2: RabbitMQ для high-load

Ошибка 3: Kafka для низкой задержки

Ошибка 4: RabbitMQ для replay

Ошибка 5: Неправильный выбор подхода

Резюме

Проверка знаний

Вопросы, где были ошибки