Опыт перехода с RabbitMQ на Kafka и причины замены

Что проверяют

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

Как отвечать

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

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

Про платформу скажите отдельно: вместо RabbitMQ.Client берётся Confluent.Kafka, шина вроде MassTransit прячет транспорт, но модель протекает наружу, и запрос с ответом или отложенную доставку приходится собирать самому. Миграцию описывайте двойной записью: пишем в оба, переводим потребителей по одному, старое гасим, когда отставание нулевое.

Где спотыкаются

Приводят цифры без условий замера. Утверждение о кратном росте пропускной способности ничего не значит без размера сообщения, настроек подтверждения, батча и сжатия; на мелких сообщениях без батчинга разрыв исчезает.

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

Забывают про смещения. Автоматический коммит по таймеру подтверждает ещё не обработанное, и падение теряет сообщения. Ручной коммит после обработки эту дыру закрывает, но гарантия остаётся «не менее одного раза», поэтому обработчик обязан быть идемпотентным.