Redis vs RabbitMQ vs Kafka
Кратко
| Характеристика | Redis (Pub/Sub) | RabbitMQ | Kafka |
|---|---|---|---|
| Тип | In-memory хранилище с pub/sub | Message broker (AMQP) | Distributed log (streaming) |
| Хранение сообщений | По минимуму / нет очереди | Очереди, ack/retry | Долгое хранение (дни/недели) |
| Подтверждение (ack) | ❌ Нет | ✅ Да | ✅ Да (на стороне consumer-а) |
| Скалируемость | Ограничена | Хорошая (через federation) | Отличная (шардирование, партиции) |
| Производительность | Очень высокая (ms) | Высокая | Очень высокая (сотни МБ/сек) |
| Надёжность доставки | Минимальная | Надёжная | Очень надёжная |
| Use-case | Простые pub/sub, кеши | Классические очереди задач | Потоковая обработка, логирование, ETL |
Redis (Pub/Sub)
- In-memory key-value store
- Поддерживает publish/subscribe модель
- Нет хранения сообщений: если клиент не подключён — сообщение потеряно
- Быстро, просто, нет подтверждений
- Используется для кешей, простых уведомлений
RabbitMQ
- Message broker, реализующий AMQP
- Поддержка очередей, acknowledge, маршрутизация сообщений
- Позволяет задавать retry-политику, отложенные очереди, dead-letter
- Подходит для задач, требующих гарантированной доставки (например, отправка email)
Kafka
- Распределённый commit log
- Хранит сообщения на диске (по умолчанию — несколько дней или бесконечно)
- Поддерживает множество потребителей, offset-based чтение
- Подходит для обработки больших объёмов данных, аналитики, потоков событий
- Используется в микросервисах, стриминге, логировании, ETL
Когда что использовать?
- Redis: быстро, просто, но без гарантий. Хорошо для pub/sub внутри одного сервиса или простых уведомлений.
- RabbitMQ: хорош для надёжной доставки, очередей заданий, где важны ack и порядок.
- Kafka: нужен, когда важны масштаб, история, скорость обработки и независимость консьюмеров.
Можем добавить примеры кода, схемы архитектур или сравнение latency/throughput — скажи, если надо 👇