Средний ~25 мин чтения

Redis: кэширование и структуры данных

Урок 3 из 5 в курсе NoSQL базы данных

Redis: кэширование и структуры данных

Redis — in-memory хранилище с разнообразными структурами данных; используется для кэша, сессий, очередей задач и pub/sub

Почему это важно: Redis — самый популярный инструмент для кэширования в backend. Правильное использование снижает нагрузку на БД в 10-100x

Главная идея

Redis хранит данные в RAM; доступ за микросекунды. Структуры данных (strings, hashes, lists, sets, sorted sets) решают разные задачи

Как это выглядит на практике

  1. Кэш API-ответа: SET post:42 '{...json...}' EX 300 — кэш на 5 минут.
  2. GET post:42 — если есть, возвращаем. Если нет (cache miss) — идём в PostgreSQL, пишем в Redis.
  3. Сессии: SETEX session:abc123 3600 '{user_id: 42}' — сессия на час.
  4. Очередь задач: LPUSH jobs '{send_email: ...}' — Sidekiq/Celery читает через BRPOP.
  5. Leaderboard: ZADD scores 1500 'user:42' — sorted set; ZRANGE scores 0 9 REV — топ-10.

Что происходит под капотом

  • Единый поток (single-threaded): Redis обрабатывает команды последовательно; нет deadlock, но нет параллелизма.
  • Persistence: RDB (снимки) и AOF (log всех команд); можно комбинировать.
  • Redis Cluster: автоматический sharding по 16384 хэш-слотам.
  • Pub/Sub: SUBSCRIBE channel; PUBLISH channel message — message broker без гарантий доставки.
  • Pipelining: отправка нескольких команд без ожидания ответа на каждую; сокращает round-trip latency.

Типичные ошибки и заблуждения

  • Ошибка: Redis — только кэш. Redis — это также сессии, очереди (Sidekiq/Celery/BullMQ), pub/sub, leaderboards, rate limiting.
  • Ошибка: TTL не нужен — сами почистим. Без TTL Redis заполняется и выбрасывает данные по LRU или возвращает OOM.
  • Ошибка: Redis надёжно хранит данные. По умолчанию — только в RAM. Для персистентности нужен AOF или RDB.
  • Ошибка: кэшировать всё — хорошая идея. Невалидированный кэш хуже чем его отсутствие; кэшируй избирательно.

Ключевые выводы

  • TTL обязателен для кэша; иначе Redis переполняется.
  • Cache invalidation — одна из сложнейших задач; продумывай заранее.
  • Redis single-threaded: LRANGE на миллион элементов блокирует весь Redis.
  • AOF + RDB — для надёжного хранения данных в Redis.

Термины урока

TTL (Time To Live): время жизни ключа; после истечения Redis удаляет его автоматически.
Cache hit/miss: ключ найден/не найден в кэше.
AOF (Append Only File): persistence через логирование всех команд.
Pub/Sub: паттерн обмена сообщениями через каналы.
Sorted Set (ZSET): структура данных Redis; элементы с числовым score, автоматически сортированные.
Eviction policy: политика вытеснения ключей при нехватке памяти (LRU, LFU, noeviction).

Связь с работой backend-разработчика

Стек для большинства backend: PostgreSQL (данные) + Redis (кэш + сессии + очереди). Настрой maxmemory и eviction policy (allkeys-lru). Никогда не используй Redis как основное хранилище без AOF.

Мини-разбор реальной ситуации

E-commerce сайт: каждый запрос главной страницы делает 15 SQL-запросов, 800ms. Кэшируем homepage JSON в Redis с TTL 60 секунд: redis SET homepage:v2 ... EX 60. Результат: 8ms для кэшированных запросов, нагрузка на PostgreSQL снижается на 95%.

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

  • TTL на каждый кэш-ключ — обязательно.
  • Кэшируй вычисленные результаты, а не сырые данные из БД.
  • Redis single-threaded: избегай медленных операций на больших структурах.

Итог

Redis — швейцарский нож backend-разработчика. Кэш, сессии, очереди, pub/sub — всё в одном инструменте. Освой 10 основных команд и структуры данных — этого достаточно для 90% задач.