Redis как кэш
Тема дорожной карты · Backend разработчик
Кеширование с Redis — один из наиболее эффективных способов повышения производительности в бэкенд-разработке: Redis является хранилищем данных в памяти, обеспечивающим чтение кеша с субмиллисекундной задержкой и резко снижающим нагрузку на PostgreSQL, MySQL и другие основные базы данных. Redis поддерживает богатые структуры данных — строки (SET key value EX 300), хэши, упорядоченные множества, списки и HyperLogLog, — что позволяет использовать его не только для простых кешей ключ-значение, но и для лидербордов, счётчиков ограничения частоты запросов, каналов pub/sub и хранилищ сессий в сессионной аутентификации. Распространённые паттерны кеширования с Redis: Cache-Aside (приложение проверяет Redis перед запросом к базе данных и заполняет кеш при промахе), Write-Through (каждая запись в базу данных одновременно производится в Redis) и Read-Through (слой кеша прозрачно обращается к базе данных). В Node.js пакеты ioredis или redis предоставляют полнофункциональный клиент с поддержкой конвейеризации и Lua-скриптов; в Python стандартной является библиотека redis-py; Spring Boot интегрируется с Redis через spring-boot-starter-data-redis с аннотациями @Cacheable и @CacheEvict. Кеширование с Redis в продакшене требует тщательной настройки TTL, конфигурации политики вытеснения (allkeys-lru наиболее распространена), Redis Sentinel или Redis Cluster для высокой доступности, а также мониторинга hit rate кеша через Prometheus и Grafana для проверки прироста производительности.
Как это работает
Redis как кэш использует кеши (Redis, Memcached, in-process LRU) чтобы избежать дорогого DB или compute, и очереди (Redis Streams, RabbitMQ, Kafka, SQS) чтобы развязать медленную async-работу от request-пути. Стратегии инвалидации кеша: TTL (истечение по времени), write-through (обновлять кеш на запись), event-driven (инвалидация на связанное изменение), cache-aside (читаем кеш, fallback на БД). Паттерны очередей: work queues, pub/sub, exactly-once vs at-least-once.
Когда применять
Кеш — когда замер показывает повтор дорогого compute; никогда "превентивно". TTL-кеш — для данных с допустимой staleness (5-60 секунд закрывает большинство кейсов). Очереди — когда запрос триггерит работу, не помещающуюся в response window (отправка email, обработка файлов, вызовы third-party): возвращайте 202 Accepted + status URL. Consumers очередей — это сервисы со своим мониторингом + репликами.
Типичные ошибки
Ловушки Redis как кэш: stale-кеш, потому что забыли инвалидировать на связанном пути (знаменитая "две сложные проблемы"); cache stampede, когда ключ протух и N запросов одновременно бьют в БД (stale-while-revalidate или singleflight); at-least-once очереди без идемпотентных consumer (дубль emails/charges); не мониторите lag очереди (тихий backlog растёт, потом взрывается).