Как реализовать кеширование часто используемых данных?

Кеширование — это не “положить в Redis и забыть”, а набор решений: что кешируем, как называем ключи, как долго живут данные и как не сломать консистентность.

Определение

Кеширование — это хранение копии часто запрашиваемых данных в более быстром месте, чтобы уменьшить задержки и нагрузку на основной источник.

Базовый паттерн: cache-aside (ленивый кеш)

1. Пробуем прочитать из кеша по ключу.

2. Если ключ есть — возвращаем данные.

3. Если ключа нет — читаем из БД/сервиса, сохраняем в кеш с TTL, возвращаем.

Небольшой пример:

import json

def get_user_profile(user_id, redis, db):
    key = f"user:{user_id}:profile:v1"

    cached = redis.get(key)
    if cached:
        return json.loads(cached)

    data = db.load_user_profile(user_id)  # запрос в БД
    redis.setex(key, 300, json.dumps(data))  # TTL 5 минут
    return data

Как выбрать, что кешировать

• Частые чтения и редкие изменения (справочники, профили, настройки).

• Тяжёлые вычисления (агрегации, отчёты), если допустима небольшая задержка актуальности.

• Внешние API, где дорого или медленно ходить.

Как управлять актуальностью данных

1) TTL (протухание)

• Просто и надёжно.

• Подходит, если допустима “примерная актуальность”.

2) Явная инвалидация при изменении

• При обновлении записи в БД удаляем/обновляем ключ кеша.

• Важно обеспечить, чтобы это было сделано всегда (иначе “вечная” устаревшая копия).

3) Комбинация TTL + инвалидация

• Часто лучший практический вариант: TTL как страховка, инвалидация как основной механизм.

Частые проблемы и как их решать

1) Cache stampede (толпа запросов при промахе)

Ситуация: TTL истёк, много запросов одновременно пошли в БД.

Решения:

• Лок/“одиночный пересчёт” (один запрос строит кеш, остальные ждут или получают старое).

• “Мягкий TTL”: заранее обновлять кеш до полного истечения.

• Джиттер: добавлять случайность к TTL, чтобы ключи не истекали одновременно.

2) Cache penetration (запросы по несуществующим данным)

Ситуация: ключа нет и в БД тоже нет → каждый раз промах.

Решения:

• Кешировать “пустой результат” на короткий TTL.

• Проверять валидность входных данных раньше.

3) Cache inconsistency (устаревшие данные)

Решения:

• Чётко определить SLA актуальности (например, “данные могут отставать до 5 минут”).

• Для критичных данных не кешировать, либо использовать короткий TTL/явную инвалидацию.

Вывод

Хороший кеш строится вокруг паттерна cache-aside, понятных ключей, TTL и продуманной инвалидации, а также защиты от массовых промахов и устаревания.