Кэширование в Redis на практике: стратегии и инвалидация

Кэш — это ускоритель, а не источник истины

Главный принцип: система должна оставаться корректной даже при полном сбросе кэша. Если данные есть только в кэше, это уже не кэш, а ненадёжное хранилище.

Выбираем паттерн

Чаще всего мы используем cache-aside: приложение сначала смотрит в кэш, при промахе читает из базы и кладёт результат обратно. Для данных, требующих свежести, подходит write-through, когда запись идёт и в базу, и в кэш.

На что обратить внимание

• Осмысленные ключи и пространства имён.
• Разумные TTL под характер данных.
• Теги для групповой инвалидации связанных записей.

Боремся с cache stampede

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

Инвалидация — самая сложная часть

Инвалидацию мы привязываем к доменным событиям: при изменении сущности сбрасываются именно связанные с ней ключи. Это надёжнее, чем полагаться только на TTL, и избавляет от показа устаревших данных.

Итоги

Грамотное кэширование в Redis снимает основную нагрузку с базы и стабилизирует латентность, но требует дисциплины в выборе паттерна и продуманной инвалидации.