> Что выбрать для кэша рядом с базой данных: Redis, RabbitMQ или Kafka? (Python)

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

Для кэша рядом с базой данных выбирайте Redis. RabbitMQ и Kafka - это брокеры сообщений, они решают задачи асинхронной коммуникации, а не хранения данных с быстрым доступом. Redis - in-memory key-value store с поддержкой TTL, который идеально подходит для кэширования: низкая задержка, простота, встроенные структуры данных. RabbitMQ и Kafka можно использовать для инвалидации кэша, но не как сам кэш.

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

Redis - это база данных в памяти, спроектированная для операций чтения/записи с микросекундной задержкой. Она поддерживает строки, хэши, списки, множества и sorted sets, а также TTL для автоматического удаления ключей. Это делает её естественным выбором для кэша: вы храните результат запроса к БД под ключом и задаёте время жизни.

RabbitMQ - это message broker, реализующий протокол AMQP. Его основная задача - надёжная доставка сообщений между сервисами через очереди и exchanges. Он не предназначен для хранения произвольных данных с быстрым доступом по ключу. Попытка использовать RabbitMQ как кэш приведёт к необходимости писать обёртки над очередями, что даст худшую производительность и сложную модель данных.

Kafka - это distributed log, оптимизированный для потоковой обработки больших объёмов событий. Он хранит данные на диске с репликацией и позволяет перечитывать их с любого offset. Kafka отлично подходит для event streaming, но не для кэша: latency выше, чем у Redis, нет простого API для get/set по ключу, а хранение требует настройки retention и compaction.

Ключевое различие: Redis - это хранилище с прямым доступом по ключу, RabbitMQ и Kafka - системы передачи сообщений. Кэш требует быстрого чтения и записи по ключу, что Redis делает нативно. Брокеры же решают задачу decoupling и асинхронности, и их использование для кэша - антипаттерн.

На практике

В реальном проекте вы используете Redis для кэширования результатов запросов к PostgreSQL или MySQL. Например, при GET /users/{id} вы сначала проверяете Redis, и только при miss идёте в БД. TTL задаётся в зависимости от частоты обновления данных - от секунд до часов.

RabbitMQ или Kafka появляются рядом, когда нужно инвалидировать кэш при изменении данных. Например, сервис обновляет запись в БД и публикует событие в Kafka. Другой сервис слушает это событие и удаляет соответствующий ключ из Redis. Это позволяет держать кэш согласованным без прямых вызовов между сервисами.

Если вы видите вопрос "что выбрать для кэша" - это проверка понимания различий между хранилищами и брокерами. Redis - единственный разумный вариант. RabbitMQ и Kafka могут быть частью архитектуры вокруг кэша, но не заменой ему.

Пример кода

PYTHON
import redis
import psycopg2

r = redis.Redis(host='localhost', port=6379, decode_responses=True)

def get_user(user_id: int) -> dict:
    cache_key = f"user:{user_id}"
    
    # Пытаемся получить из кэша
    cached = r.hgetall(cache_key)
    if cached:
        return cached
    
    # Miss - идём в БД
    conn = psycopg2.connect("dbname=app user=postgres")
    cur = conn.cursor()
    cur.execute("SELECT id, name, email FROM users WHERE id = %s", (user_id,))
    row = cur.fetchone()
    conn.close()
    
    if not row:
        return None
    
    user = {"id": row[0], "name": row[1], "email": row[2]}
    
    # Записываем в кэш на 60 секунд
    r.hset(cache_key, mapping=user)
    r.expire(cache_key, 60)
    
    return user

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

Начните с прямого ответа: Redis. Затем кратко объясните, почему RabbitMQ и Kafka не подходят - они для сообщений, а не для хранения. Подчеркните, что Redis даёт низкую задержку и TTL. Если интервьюер спрашивает про инвалидацию - упомяните паттерн с публикацией событий в Kafka и удалением ключей. Не углубляйтесь в детали реализации брокеров, если не спрашивают.

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

Интервьюер оценивает, понимаете ли вы разницу между классами систем: хранилище данных vs message broker. Также проверяется знание Redis как инструмента кэширования: TTL, структуры данных, паттерны cache-aside. Важно показать, что вы умеете проектировать систему с учётом согласованности данных и не путаете инструменты по назначению.

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

• Выбор Kafka из-за "масштабируемости" - это не аргумент для кэша, Kafka хранит данные на диске и имеет высокую задержку.
• Утверждение, что RabbitMQ можно использовать как кэш через queues - это антипаттерн, очередь не даёт произвольного доступа по ключу.
• Игнорирование TTL - без него кэш будет расти бесконечно, что приведёт к переполнению памяти Redis.
• Смешивание ролей: использование Redis для очередей задач (это возможно, но не оптимально) и брокеров для кэша - в обоих случаях инструмент используется не по назначению.