Kafka и RabbitMQ: выбор под задачу

Первый кейс: платежный сервис обработал событие и что дальше. В RabbitMQ путь короткий: консьюмер вызвал Ack — брокер удалил сообщение из очереди, и система вернулась к состоянию «до события». Это идеально для задач в духе «отправить письмо и забыть»: очередь — журнал незавершённой работы, а не архив. В Kafka сообщение после обработки никуда не девается: WriteMessages положил его в партицию, консьюмер сдвинул коммит офсета, но запись живёт до истечения retention. Любой новый читатель начинает с StartOffset и видит те же байты, что видели первые. Отсюда практическое следствие для выбора: если ценность сообщения умирает в момент обработки — это очередь; если событие остаётся фактом, который завтра понадобится новому подписчику, аналитике или отладке, — это лог. Ошибка выбора всплывает не сразу: очередь с задачами на Kafka заставит городить удаление и компакцию из семнадцатого урока, а аудит событий на RabbitMQ потребует отдельного хранилища, потому что брокер ничего не помнит. Отметьте для себя асимметрию хранения: Kafka расходует диск всегда, RabbitMQ — только на незавершённую работу, и в мирном режиме очередь выглядит экономнее ровно до момента, когда понадобится история.

Второй кейс: обработчик упал на конкретном сообщении. В RabbitMQ вся механика повтора встроена: nack с requeue возвращает сообщение в очередь, а связка с dead-letter exchange собирает отказавшие письма в отдельную очередь, где их ретраят по расписанию или разбирает человек. Консьюмер только честно сообщает результат. В Kafka повторов из коробки нет: consumer-протокол не умеет «отклонить» одно сообщение, потому что офсет — позиция в логе, а не номер задачи. Стандартный паттерн — сделать всё самому: отказавшее сообщение уводим в отдельный dead-letter топик с заголовком-причиной и коммитим оригинал, иначе группа застрянет на этой позиции навсегда. Такой паттерн разобран построчно в девятнадцатом уроке; здесь важно другое — сравнить трудозатраты. На RabbitMQ retry-политика — настройка, на Kafka — собственный код, тесты и мониторинг DLT-топика. Зато ваш DLQ описан на Go, а не в терминах чужого плагина.

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

Четвёртый кейс: одно событие заказа нужно биллингу, аудиту и уведомлениям. В RabbitMQ это работа exchanges: публикуете в fanout-обменник, он копирует письмо во все привязанные очереди, и каждая команда читает свою копию. В Kafka той же служит структура консьюмер-групп: лог один, а независимые читатели — это группы с разными GroupID. Каждая группа ведёт собственные коммиты офсетов и получает весь поток целиком; внутри группы партиции делятся между членами, между группами — никогда. Это механика седьмого урока, и на сравнении она даёт Kafka ощутимое преимущество: добавить нового подписчика к существующему потоку — значит запустить ещё одну группу, без изменения продюсера и без новых очередей в топологии. В RabbitMQ каждая новая команда — это новая очередь и новая привязка на обменнике, то есть правка конфигурации брокера. Для Go-кода разница тоже на поверхности: Reader с другим GroupID — четыре строки, тогда как топология exchanges — команда или консоль брокера. Обратная сторона: группа в Kafka читает лог с той позиции, где договорились, а обменник RabbitMQ раздаёт только то, что опубликовано после привязки.

Пятый кейс — следствие первого: что делать, когда нужно перечитывание. Kafka хранит лог заданный срок или объём, и новый консьюмер с StartOffset равным kafka.FirstOffset начинает с самого старого живого сообщения: отладка инцидента недели назад, восстановление проекции, подключение нового сервиса к старому потоку — всё это replay без дополнительной инфраструктуры, детали в семнадцатом уроке. RabbitMQ не хранит обработанное в принципе: ack стёр сообщение, и «перечитать неделю» на очереди означает, что неделю назад кто-то обязан был скопировать поток в архив — отдельное хранилище, отдельный код. В копилку RabbitMQ честно запишем обратное: лог, который растёт семь дней, требует диска и внимания к retention, тогда как очередь сама освобождается по мере разбора. Выбор, таким образом, снова о модели данных: архив за подписку или почтовый ящик без архива.