Часто вижу один и тот же паттерн:
– получили данные из БД,
– положили их в Redis,
– отдали пользователю.
А потом — классический цикл "сначала лезем в кэш, если нет — идём в базу".
На первый взгляд всё красиво, но тут и кроется проблема.
👉 Основное правило при проектировании кэша — учитывать частоту обновления данных и, в зависимости от этого, строить логику инвалидации. Но данные даже внутри одной таблицы редко бывают однородными. Redis — это не просто "хранение JSON".
Например, типовой кейс:
у нас есть сущность *Post*, у неё есть "тяжёлые" атрибуты (текст, автор, дата), а есть счётчики (кол-во просмотров, лайков, комментариев).
Обновляются они с совершенно разной частотой.
Если всё хранить в одном JSON-ключе, то:
- при каждом инкременте счётчика мы будем перезаписывать весь объект,
- рискуем гонками и избыточной нагрузкой,
- теряем смысл "лёгкого" кэша.
🚀 Куда эффективнее хранить две записи:
1. сам объект (Post body),
2. отдельный ключ под счётчики.
Что это даёт:
- быстрые и атомарные обновления через
INCR / HINCRBY, - возможность сбрасывать "тело" поста по TTL, не трогая счётчики,
- гибкость в инвалидации: разные правила для разных типов данных.
А получать данные из кэша в этом случае лучше не "в лоб" (два `GET`), а через pipeline — так мы минимизируем RTT.
Для хранения вместо JSON отлично подходят структуры Redis:
-
HASH (для набора атрибутов), -
STRING + INCR (для простых счётчиков). Итог: кэширование — это не "сложили JSON и забыли". Это проектирование модели данных под конкретный паттерн использования. И чем тоньше вы это сделаете, тем больше выиграете в производительности и стабильности.
💡 А у вас в проектах Redis чаще живёт как "JSON-склад" или как полноценный инструмент с типами и пайплайнами?