← Данные
11 мин · просто · Урок 4 из 5

Redis: кеш и общее состояние

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

Зачем ещё одно хранилище

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

Второе применение из урока про 12-factor: stateless-приложения выносят общее состояние (сессии) во внешнее хранилище, и Redis для этого удобен.

Базовые операции

Redis работает по ключам. Положить, прочитать, удалить:

SET user:42:name "Ivan"
GET user:42:name        -- "Ivan"
DEL user:42:name
EXISTS user:42:name      -- 0 или 1

Кроме строк есть структуры: списки, множества, хеши, счётчики. Счётчик, например, атомарно увеличивается одной командой, что удобно для лимитов и метрик:

INCR page:views        -- атомарно +1, вернёт новое значение

TTL: данные с истечением

Ключу можно задать время жизни (TTL). По истечении Redis удаляет ключ сам. Это основа кеша: положил результат запроса на пять минут, и дальше он обновится сам.

SET weather:moscow "{...}" EX 300    -- живёт 300 секунд
TTL weather:moscow                   -- сколько осталось

Без TTL кеш разрастается и забивает память. Поэтому у кеш-ключей TTL ставят почти всегда.

Кеш и инвалидация

Типичная схема кеша называется cache-aside:

  1. приложение спрашивает Redis.
  2. есть значение (cache hit) → вернуть его.
  3. нет (cache miss) → сходить в Postgres, положить результат в Redis с TTL, вернуть.
ключ есть · cache hit ключа нет · cache miss читаем Redis: ключ есть? отдать значение Postgres SET ключ · TTL отдать UPDATE DEL ключа либо ничего не делаем и ждём, пока ключ истечёт по TTL
Промах идёт в базу и сам наполняет кеш. Запись в базу оставляет в Redis устаревшее значение.

Главная сложность кеша — инвалидация: данные в базе поменялись, а в кеше лежит старое. Два подхода. Положиться на TTL (старое протухнет само через N секунд, допустимо для не критичных данных) или удалять ключ при изменении (DEL после UPDATE, когда нужна свежесть). Выбор зависит от того, насколько критична свежесть против простоты.

Redis, Valkey и лицензии

Есть ещё одна вещь, из-за которой в вакансиях и облачных консолях всё чаще встречается слово Valkey.

В марте 2024 компания Redis сменила лицензию открытой версии с BSD на пару SSPL / RSAL — лицензии, ограничивающие тех, кто продаёт Redis как услугу. Облачные провайдеры и часть контрибьюторов ответили форком последней открытой версии. Форк назвали Valkey и передали в Linux Foundation. Крупные облака перевели свои managed-сервисы на него, так что «Redis-совместимый кеш» у провайдера сегодня чаще всего Valkey.

В мае 2025 Redis 8 вернулся к открытой лицензии AGPLv3, но Valkey к тому моменту уже закрепился.

Для тебя разница пока чисто номинальная: те же команды, тот же протокол, те же клиентские библиотеки. Всё из этого урока работает в обоих. Знать стоит ровно затем, чтобы не удивляться названию в интерфейсе облака.

Что важно запомнить

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

Кеш-ключам задают TTL, иначе память переполнится. Схема cache-aside: промах идёт в базу и кладёт результат в Redis с TTL.

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

Valkey — форк Redis под Linux Foundation, появившийся после смены лицензии в 2024 году; в managed-сервисах облаков обычно он. Команды и протокол совместимы.

В следующем уроке разберём очереди сообщений: как развязывать сервисы и сглаживать пики.

Прошли материал до конца? Отметьте урок пройденным.