> В чем разница между Kafka и RabbitMQ (Go, Python)

Короткий ответ

Kafka - распределённый журнал (log), оптимизированный для высокопроизводительной потоковой передачи событий и их длительного хранения. RabbitMQ - универсальный message broker с поддержкой сложной маршрутизации, очередей с приоритетами, dead-letter exchanges и гарантий доставки. Kafka масштабируется горизонтально за счёт партиционирования и репликации, RabbitMQ - через кластеризацию, но с ограничениями по пропускной способности. Выбор зависит от сценария: Kafka для event streaming и аналитики, RabbitMQ для task distribution и RPC.

Подробное объяснение

Основное различие лежит в модели потребления и внутренней архитектуре.

Kafka:

• работает как распределённый commit log: сообщения хранятся на диске в партициях топика, упорядоченно и с retention-политикой (по времени или размеру);
• потребители работают в pull-режиме: сами читают сообщения с нужной позиции (offset), что позволяет повторно перечитывать данные;
• масштабирование достигается за счёт партиций: каждая партиция обрабатывается одним consumer в группе, что гарантирует порядок внутри партиции;
• гарантии доставки настраиваются через acks (0, 1, all) и enable.idempotence, но по умолчанию - at-least-once;
• поддерживает replay событий, поэтому подходит для event sourcing, CDC, stream processing (Kafka Streams, ksqlDB);
• не имеет встроенной маршрутизации по заголовкам или routing keys - только по ключу партиции.

RabbitMQ:

• работает как классический брокер с очередями: сообщения удаляются после подтверждения (ack) потребителем;
• использует push-модель: брокер сам отправляет сообщения потребителям, что снижает задержку, но требует управления prefetch;
• поддерживает гибкие exchange types: direct, topic, fanout, headers - маршрутизация по routing key и binding rules;
• предоставляет дополнительные механизмы: dead letter queue, priority queues, delayed messages (через плагин), RPC-паттерн;
• гарантии доставки: publisher confirms + consumer acks, но нет встроенного replay;
• кластеризация возможна, но сложнее в горизонтальном масштабировании: очередь живёт на одном узле (или mirror queue с ограничениями).

Ключевой trade-off: Kafka жертвует гибкостью маршрутизации ради пропускной способности и хранения, RabbitMQ - наоборот, даёт богатые возможности доставки, но ограничен в throughput и хранении.

На практике

Для backend-разработчика на Go или Python выбор обычно определяется характером нагрузки:

• если нужен event bus для микросервисов с высокой нагрузкой (сотни тысяч сообщений/сек), replay событий, интеграция с аналитикой - Kafka;
• если нужна надёжная доставка задач воркерам, сложная маршрутизация, RPC, отложенные задачи - RabbitMQ;
• для простого pub/sub с низкой нагрузкой RabbitMQ проще в эксплуатации и отладке;
• Kafka требует более сложной инфраструктуры: ZooKeeper (или KRaft), управление партициями, мониторинг lag.

На практике часто используют оба: RabbitMQ для команд и задач, Kafka для событий домена и потоковых данных.

Пример кода

Не требуется для ответа на этот вопрос, но можно упомянуть, что в Go для Kafka используется segmentio/kafka-go или confluent-kafka-go, для RabbitMQ - amqp091-go. В Python - confluent-kafka и pika соответственно. Если интервьюер попросит - показать простой producer/consumer.

Как отвечать на собеседовании

Начни с краткого определения, затем переходи к ключевым различиям по осям: модель хранения, модель потребления, маршрутизация, масштабирование, гарантии доставки. Приведи примеры сценариев, где каждый из них уместен. Упомяни trade-off между throughput и гибкостью. Если спросят про конкретный стек - скажи, как подключаешься и какие библиотеки используешь. Не углубляйся в детали реализации, если не спрашивают.

Что проверяет интервьюер

• понимание фундаментальных различий между log-based и queue-based системами;
• знание паттернов потребления: pull vs push;
• умение обосновать выбор инструмента под конкретную задачу;
• понимание гарантий доставки и их практических последствий;
• осведомлённость о масштабировании и ограничениях обоих брокеров.

Типичные ошибки

• утверждение, что Kafka "быстрее" RabbitMQ без контекста - это зависит от сценария и конфигурации;
• игнорирование того, что RabbitMQ тоже поддерживает кластеризацию и высокую доступность;
• смешение понятий "очередь" и "топик": в Kafka нет очередей в классическом смысле, есть партиции;
• забывание про replay-возможность Kafka, которая критична для event-driven архитектур;
• утверждение, что RabbitMQ не масштабируется - он масштабируется, но иначе и с ограничениями;
• неупоминание про ordering: в Kafka порядок гарантирован только внутри партиции, в RabbitMQ - в пределах очереди.