Какие модели взаимодействия существуют у брокеров сообщений и к каким относятся RabbitMQ и Kafka

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

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

Как отвечать

Базовых моделей две, иногда добавляют третью:

• point-to-point (очередь): сообщение получает один потребитель из нескольких, конкурирующих за очередь. Обработал, подтвердил, сообщение удалено. Так раздают задачи;
• publish-subscribe: каждое сообщение получает каждый подписчик. Так рассылают события, о которых должны узнать несколько систем;
• request-reply: запрос в одну очередь, ответ в другую, связанные идентификатором корреляции. Асинхронная замена синхронного вызова.

Второе измерение: брокер доставляет сам (push) или потребитель забирает (pull).

RabbitMQ это классический брокер очередей, доставка в основном push. Он умеет обе модели через обменники: direct и topic маршрутизируют по ключу, fanout копирует во все привязанные очереди. Сообщение после подтверждения удаляется, есть повторы и dead letter exchange для необработанных.

Kafka это распределённый журнал с pull-доставкой. Основная модель pub/sub: каждая группа потребителей читает топик независимо. Внутри группы каждую партицию читает один потребитель, это даёт распределение нагрузки, похожее на очередь. Сообщения хранятся по retention (по умолчанию 7 дней), а не до прочтения, поэтому их можно перечитать с нужного offset. Порядок гарантируется только внутри партиции.

Аналитику важно перенести это в требования: гарантия доставки (почти везде at-least-once, значит обработчик должен быть идемпотентным), ключ упорядочивания, схема сообщения, например в AsyncAPI, поведение при ошибке и срок хранения.

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

Говорят «RabbitMQ это point-to-point, Kafka это pub/sub». Оба умеют обе модели, а отличаются устройством: очередь с удалением против журнала с хранением.

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

Не думают про повторную доставку. При at-least-once дубли будут, и идемпотентность потребителя должна быть в постановке.