Kafka или RabbitMQ: пропускная способность не заменяет схему доставки

15 октября 2026 г. в 13:00|Автор: Редакция QUASA|5 мин чтения| 3

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

Поэтому решение зависит от судьбы сообщения после обработки: нужно ли сохранить историю для других читателей, удалить завершённое задание или изменить его маршрут при сбое. Пропускная способность измеряет работу выбранной схемы, но сама схему не определяет. Сравнивать скорость имеет смысл после выбора требований к подтверждениям, порядку и сроку хранения.

Журнал событий и очередь задач

Kafka записывает события в упорядоченные разделы журнала — партиции. Потребитель хранит позицию чтения и может вернуться к более ранним записям, пока они доступны по политике хранения. Разные группы читают одну тему независимо: отставание одной группы само по себе не передвигает позицию другой. Такая модель подходит, когда одни и те же изменения нужны, например, поисковому индексу и аналитике.

В обычной группе потребителей партиция закрепляется за одним участником группы. Это помогает сохранять порядок связанных записей внутри партиции, но ограничивает число исполнителей количеством партиций. Документация Kafka описывает и группы совместного потребления: в них записи подтверждаются по отдельности, а участников может быть больше, чем партиций. При таком распределении обработка отдельных записей уже не обязана следовать порядку журнала.

В RabbitMQ очередь и поток решают разные задачи. В очереди подтверждённое задание завершает свой жизненный цикл; поток сохраняет запись для чтения с выбранной позиции. Поэтому сравнение «Kafka против RabbitMQ» без указания типа хранения смешивает журнал с очередью и скрывает требования, ради которых выбирают брокер.

Что меняется при сбое исполнителя

Для фоновой задачи важно управлять каждой попыткой отдельно. Условный пример: исполнитель создал отчёт, но отключился до подтверждения задания. Брокер может доставить его снова, поэтому приложение должно распознавать повторное выполнение. Подтверждение потребителя говорит брокеру, что задание обработано; подтверждение публикации решает другой вопрос — принято ли сообщение брокером.

Кворумная очередь RabbitMQ предназначена для сохраняемой, реплицируемой работы. Неудачное задание можно вернуть исполнителям или направить по отдельному маршруту, не превращая весь поток задач в повторное чтение журнала. При выборе такой очереди существенны не только скорость публикации, но и допустимое время ожидания задания, поведение при отказе исполнителя и требования к сохранности.

Группа совместного потребления Kafka тоже позволяет разделять задания и учитывать попытки доставки. При этом подтверждение записи не удаляет её из темы: место освобождается по политике хранения. Если задания должны ждать индивидуального срока, менять маршрут после ошибки или освобождать хранилище по завершении, эти различия определяют объём логики вокруг брокера.

Повторное чтение и медленный потребитель

В партиции Apache Kafka медленный потребитель отстаёт от новых событий и приближается к границе хранения истории.

Повторная обработка требует доступной истории. Документация потоков RabbitMQ описывает чтение с выбранного смещения или времени и хранение записей с ограничением по возрасту либо объёму. Значит, само требование перечитать событие не исключает RabbitMQ: для него нужен поток, а не очередь завершённых заданий.

Граница повторного чтения проходит по сохранённой истории. Если потребитель Kafka или потока RabbitMQ отстаёт дольше заданного окна хранения, удалённые записи уже нельзя получить обычным возвратом позиции. Размер хранилища следует соотносить не только со скоростью публикации, но и с допустимым отставанием читателей и глубиной возможного перерасчёта.

У очереди медленный исполнитель создаёт другую проблему: растёт запас ожидающих заданий и время до начала работы. Добавление исполнителей может сократить ожидание, если узкое место находится в них; при замедлении внешнего сервиса оно может лишь увеличить число одновременных обращений к нему. Для журнала отдельно оценивают, успеет ли отставший читатель догнать новые записи до удаления старых.

Если историю используют для восстановления последнего состояния по ключу, у Kafka есть уплотнение журнала: старые значения ключа могут удаляться с сохранением последнего. Хранение потоков RabbitMQ ограничивается возрастом или объёмом записей. Это отдельное различие от обычного повторного чтения всех событий за заданный период.

Маршрутизация и порядок

Обменник RabbitMQ направляет сообщение в разные очереди и поток по правилам привязки.

RabbitMQ удобен, когда адрес сообщения определяется правилами брокера. Документация обменников RabbitMQ описывает привязки к очередям и потокам: маршрутизация возможна по точному ключу, шаблону, а также с отправкой копии каждому связанному получателю. Правила доставки находятся в топологии брокера, а издателю достаточно отправить сообщение с подходящим ключом или свойствами.

В Kafka издатель выбирает партицию, часто по ключу записи, а группа потребителей подписывается на темы. События одного ключа можно направить в одну партицию, чтобы читать их последовательно. Если адресатов выбирают по множеству меняющихся условий, эту логику придётся выразить через темы, издателей, потребителей или дополнительный слой обработки.

Порядок записи и порядок завершения работы — разные гарантии. Kafka упорядочивает записи внутри партиции, но несколько партиций не образуют единую последовательность обработки всей темы. Несколько исполнителей очереди тоже могут завершать задания в ином порядке, особенно если одно из них отправлено на повторную попытку. Требование следует формулировать для конкретного объекта: например, сохранять последовательность изменений одного счёта, а не неопределённый «порядок сообщений».

Как сравнивать скорость выбранной схемы

Сначала нужно зафиксировать одинаковые условия: размер сообщения, число производителей и потребителей, пакетирование, сжатие, подтверждения и способ сохранения данных. Открытый набор нагрузок Kafka и RabbitMQ предусматривает сценарии с разным размером сообщений, конкуренцией производителей и потребителей, измерением задержки и использования ресурсов. Его описание указывает на испытания на одном узле; такие результаты нельзя переносить на реплицируемый кластер без отдельного измерения.

Даже одинаковое число сообщений в секунду может описывать разные гарантии. Конфигурация, которая ждёт подтверждения записи и репликации, выполняет больше работы до ответа издателю, чем конфигурация с более ранним подтверждением. На задержку и пропускную способность также влияют размер пакета, настройки диска и сети. Поэтому результат следует привязывать к конкретной конфигурации Kafka, очереди RabbitMQ или потока RabbitMQ.

Для потока событий с независимыми читателями исходный вариант — Kafka либо поток RabbitMQ; различие проявится в требованиях к хранению истории, обработке по ключу и окружению приложения. Для заданий с индивидуальным подтверждением и изменяемыми правилами доставки исходный вариант — очередь RabbitMQ, хотя группа совместного потребления Kafka покрывает часть таких сценариев. После выбора модели скорости можно задать полезный вопрос: выдерживает ли именно она ожидаемую нагрузку при нужных гарантиях и отставании потребителей.