Kafka vs RabbitMQ vs Pulsar¶

Сравнения · Раздел03

Тип материала: инженерное сравнение; выводы зависят от требований и условий эксплуатации. Схемы и примеры иллюстративны.

Версии указаны в заголовках и связанных статьях. Численные показатели производительности не заявляются.

Критерии выбора¶

Критерий	Kafka4.1	RabbitMQ4.1	Pulsar4.0
Workload / architecture	Partitioned log, independent groups/replay	Exchange routing, classic/quorum work queues; streams отдельно	Broker/storage separation, topics/subscriptions
Consistency / transaction boundary	Partition order, transactions within Kafka; external DB отдельно	Confirms и consumer ack отдельно; queue-type guarantees	Subscription-type order; Pulsar transactions external DB не включают
Latency path	Batch/network/partition path; freshness требует измерения	Routing/prefetch/work queue; redelivery влияет на completion	Dispatch/subscription/bookie path; key batching важно
Throughput / scalability	Partitions/hot keys/ISR/disk	Queue leaders, consumers, prefetch и routing	Partitions/bundles/brokers/bookies/quorums
Operational complexity / cost	Logs/replicas/retention/controllers и ops	Queue types/storage/replicas/alarms и retry lifecycle	Brokers/bookies/metadata/offload/ops

flowchart TB
  Producer --> Kafka[Kafka partition log and groups]
  Producer --> Rabbit[RabbitMQ exchange and selected queue type]
  Producer --> Pulsar[Pulsar topic and subscriptions]
  Kafka --> Replay[Retained replay consumers]
  Rabbit --> Work[Confirm and ack work lifecycle]
  Pulsar --> Storage[BookKeeper and cursor lifecycle]

Конкретные сценарии¶

Market-data history с несколькими replay consumers → исследовать Kafka/Pulsar. Task routing и provider work queues → RabbitMQ подходящего queue type. Multi-tenant event platform с выгодой storage separation → Pulsar при готовности обслуживать компоненты. Сравнивать одинаковые durability, retention, ordering и replay requirements.

Ограничения и восстановление¶

Нельзя назвать RabbitMQ просто «без replay», игнорируя streams; Kafka queue-like consumers и Pulsar subscriptions требуют версии/API анализа. Нет универсального winner по latency/throughput без workload и failure testing.

Как проверить выбор¶

Зафиксировать query/event mix, schema/payload, skew, working set/state, retention, target effect и допустимую stale-read policy. Проверять lost ACK, restart/rebalance, poison record, late correction и rebuild generation. Сравнивать TCO с одинаковыми durability/replication требованиями, включая engineering, maintenance и restore. Универсальный winner отсутствует.

Типичные ошибки проектирования¶

Сравнивать разные boundaries как одинаковую гарантию; игнорировать recovery и source retention; публиковать чужие latency/TPS как свои измерения; забывать target operations.

Вопросы на собеседовании¶

Когда стоит сочетать варианты? Когда они отвечают на разные уровни/нагрузки и contracts переходов определены. Дополнительный компонент добавляет ownership, lag, recovery и стоимость, поэтому нужна измеримая польза.

Практические упражнения¶

Составьте ADR для одного сценария: invariant, rejected alternative, failure matrix, recovery evidence и план честных измерений. Укажите, какие guarantees ещё UNKNOWN.