Порівняння
Kafka чи RabbitMQ
Kafka це розподілений журнал подій, RabbitMQ це класичний брокер повідомлень. Різна модель, різні задачі.
| Критерій | Apache Kafka | RabbitMQ |
|---|---|---|
| Модель | Незмінний журнал по партиціях, споживачі читають за offset | Черги й обміни (exchanges), брокер штовхає повідомлення споживачам |
| Зберігання | Повідомлення лишаються за часом або розміром, можна перечитати | Повідомлення зникають після підтвердження (ack), хоча є Streams |
| Пропускна здатність | Дуже висока, сотні тисяч і мільйони подій на секунду на кластері | Десятки тисяч на секунду на вузлі, нижча затримка на одне повідомлення |
| Маршрутизація | Прості топіки й партиції, логіку маршрутів робить застосунок | Гнучка: direct, topic, fanout, headers, пріоритети, TTL, dead letter |
| Складність експлуатації | Вища: кластер, партиції, ребаланс (з KRaft ZooKeeper не потрібен) | Нижча для малих систем, кластер потребує уваги |
| Ліцензія і власник | Apache-2.0, Apache Software Foundation | MPL-2.0, Broadcom (VMware) |
| Екосистема | Kafka Connect, Kafka Streams, Schema Registry, Flink, Spark | Клієнти майже для всіх мов, AMQP, MQTT, STOMP плагіни |
| Найкраще для | Потоки подій, аналітика, event sourcing, інтеграція багатьох систем | Фонові задачі, RPC через черги, складна маршрутизація |
Обирайте Apache Kafka, коли
- Подію треба читати кількома незалежними споживачами і перечитувати.
- Обсяги великі, потрібен потоковий аналіз.
- Будуєте event-driven архітектуру з журналом як джерелом правди.
Обирайте RabbitMQ, коли
- Потрібні черги задач з ack, повторами і dead letter.
- Потрібна гнучка маршрутизація та пріоритети.
- Команда мала, обсяги помірні, хочеться простіше.
Підсумок
Для черги фонових задач беріть RabbitMQ, для потоку подій з перечитуванням беріть Kafka. Kafka як чергу задач використовувати можна, але ви платите складністю за можливості, які не використаєте.
Що порівнюємо
Логотипи належать їхнім власникам і використані лише для ідентифікації. Іконки: Simple Icons (CC0), Devicon (MIT).