Redis и хранилища «ключ–значение» в оперативной памяти

Коротко: Redis хранит данные как пары «ключ–значение» в оперативной памяти и потому отвечает за доли миллисекунды; типичен для кэшей, сеансов и счётчиков.

Подробнее: Хранилище «ключ–значение» — простейшая форма базы данных: у ключа есть значение. Redis держит данные в RAM (по желанию с резервированием на диск) и помимо строк предлагает списки, множества, хэши, упорядоченные множества и потоки. Очень быстро, но память ограничена и дороже дисков.

Подробности

Типичное применение

• Кэш: хранить результаты дорогих запросов к базе данных от секунд до часов.
• Сеансы: состояние входа пользователей.
• Счётчики и ограничение частоты запросов: INCR атомарно считает обращения за временное окно.
• Таблицы лидеров: упорядоченные множества (ZADD, ZRANGE).
• Очереди и pub/sub: простое распределение сообщений.
• Распределённые блокировки.

Примеры

SET user:42:name "Mia" EX 3600   # истекает через 1 час
GET user:42:name
INCR views:homepage
LPUSH tasks "send-mail"
ZADD leaderboard 150 "Mia"

EX задаёт срок действия (TTL), после которого ключ автоматически исчезает; идеально для кэшей.

Персистентность и эксплуатация

Без мер данные теряются при перезапуске. Redis может записывать снимки (RDB) или журнал только добавления (AOF). Для отказоустойчивости используют репликацию и Redis Sentinel/Cluster. Как кэш потеря данных обычно допустима; как единственный источник данных Redis подходит редко. Управляемые сервисы (например, Upstash, ElastiCache) берут эксплуатацию на себя.

Замечания

Выбирайте осмысленные имена ключей (область:id:поле), всегда задавайте сроки действия для данных кэша, учитывайте инвалидацию кэша и защищайте сервер (пароль, не открывайте в интернет). Альтернативы: Memcached (только простые значения), Valkey (бесплатный форк Redis), Dragonfly.

См. также: Upstash Redis, Стратегии кэширования, Ограничение частоты запросов, Базы данных NoSQL