Redis: что это, когда нужен и как его используют рядом с приложением

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

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

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

Чаще всего нужны string, hash, list, set и sorted set. У каждой структуры своя роль. String удобен для простого кэша и счётчика. Hash — для набора полей. List и stream — для очередей. Sorted set — для рейтингов и приоритетов. Выбор структуры сильно влияет на дальнейший код вокруг Redis.

Чаще всего команды складывают данные в Redis без ясной схемы ключей и инвалидации. На старте всё быстро. Потом никто не понимает, почему значение устарело, почему память выросла и почему приложение ведёт себя по-разному на разных узлах. Проблема не в Redis, а в плохих правилах работы с ним.

Начните с кэша чтения рядом с обычной базой. Разберите ключ, TTL, сброс и сценарий промаха. Потом добавьте счётчик или rate limit. Только после этого переходите к persistence, replication и более сложным очередям. Так вы сначала увидите роль Redis в приложении, а не просто набор команд.

String — базовый тип: байтовая строка до 512 МБ. Хранит текст, числа, сериализованные объекты. Команды INCR/DECR атомарно меняют числовое значение — на этом строят счётчики и rate limiter. Hash — словарь полей внутри одного ключа: HSET user:1 name «Иван» age 30. Удобен для объектов, которые нужно обновлять по отдельным полям без перезаписи целиком.

List — двусвязный список строк: LPUSH кладёт элемент слева, BRPOP блокируя забирает справа — классическая очередь задач. Set — неупорядоченное множество уникальных строк с поддержкой пересечения и объединения. Sorted Set (ZSet) — каждый элемент имеет числовой score, список автосортируется. На ZSet строят рейтинги, топы и скользящие окна для rate limiting.

Stream — append-only лог событий, появившийся в Redis 5.0. Каждый элемент получает уникальный ID вида timestamp-sequence. Consumer groups дают нескольким воркерам возможность читать разные записи одного потока без дублирования: сообщение доставляется ровно одному воркеру и остаётся pending до явного ACK. Redis Stream занимает нишу между List-очередью и Kafka — когда нужна история сообщений, но не отдельный брокер.

Eviction policy — правило удаления ключей при достижении лимита maxmemory. noeviction: новые записи отклоняются с ошибкой. allkeys-lru: удаляется ключ, к которому дольше всего не обращались. allkeys-lfu: удаляется наименее часто используемый ключ. volatile-ttl: среди ключей с TTL удаляется тот, чей срок истекает раньше всего. Для чистого кэша стандартный выбор — allkeys-lru; для смешанного использования — volatile-lru.

LRU (Least Recently Used) удаляет ключ, к которому дольше всего не обращались — оценка по времени последнего доступа. LFU (Least Frequently Used) считает частоту обращений и удаляет наименее востребованные ключи. LFU точнее при неравномерном трафике: ключ, к которому обращались тысячу раз за час, но не трогали последние пять минут, LRU вытеснит, а LFU оставит в кэше.

Простейший способ: LPUSH tasks '{"job": "send_email"}' кладёт задачу, воркер делает BRPOP tasks 0 — блокируется до появления задачи в очереди. Библиотека Celery (Python) и BullMQ (Node.js) работают поверх Redis именно так. Для надёжности с подтверждением доставки используют Redis Stream с consumer groups: сообщение остаётся в потоке до явного ACK от воркера.

Redis pub/sub — fire-and-forget: PUBLISH channel message доставляет сообщение подписчикам, активным прямо сейчас; история не хранится. Пропустил публикацию — сообщение потеряно. Kafka — персистентный лог: сообщения хранятся на диске, потребитель читает с любого offset и не теряет данные при отключении. Redis pub/sub подходит для live-уведомлений и инвалидации кэша; Kafka — для надёжной передачи событий между сервисами.

Sentinel — набор отдельных процессов, которые следят за Redis-мастером и его репликами. Если мастер недоступен дольше down-after-milliseconds, кворум Sentinel-ов запускает failover: одна из реплик становится новым мастером, остальные переключаются на неё, клиенты получают новый адрес через Sentinel API на порту 26379. Sentinel решает задачу высокой доступности без горизонтального масштабирования.

Cluster — режим горизонтального масштабирования: пространство ключей делится на 16 384 хэш-слота, распределённых между несколькими мастер-нодами. Каждый мастер имеет реплики и самостоятельно выполняет failover без Sentinel-процессов. Sentinel наблюдает за одним мастером и отвечает за failover; Cluster — за группой мастеров и масштабирует объём данных. Cluster выбирают, когда данные или нагрузка не умещаются в одну ноду.

Типовые сценарии: превышение maxmemory без eviction policy → OOM-killer убивает процесс; потеря всех данных при рестарте без включённого AOF; блокировка однопоточного event loop командами KEYS * или SMEMBERS на большом множестве. Профилактика: установить maxmemory + allkeys-lru, включить AOF fsync everysec, заменить KEYS * на итеративный SCAN, вынести тяжёлые read-операции на реплику.

RDB — периодический снимок (snapshot) всей базы на диск. Быстро восстанавливается, занимает мало места, но при сбое теряются данные с момента последнего снимка — иногда это минуты. AOF (Append Only File) — лог каждой команды записи; с настройкой fsync everysec теряется не более одной секунды данных. На продакшне часто включают оба режима: RDB для быстрого восстановления, AOF для минимальных потерь.

RedisSearch — модуль (входит в Redis Stack), добавляющий полнотекстовый поиск прямо внутри Redis. Индексирует поля Hash или JSON-документов, поддерживает нечёткий поиск, фильтрацию по числовым диапазонам, агрегации и векторный поиск для RAG-паттернов с эмбеддингами. Подходит для автодополнения, каталогов товаров и семантического поиска — без отдельного поискового движка.

RedisJSON — модуль для хранения JSON-документов как нативного типа данных Redis. Вместо сериализации объекта в строку RedisJSON хранит дерево JSON и обновляет отдельные пути командой JSON.SET path — без перезаписи всего значения. Совместим с RedisSearch: можно индексировать поля JSON и делать полнотекстовые запросы по вложенным структурам.

В московских вакансиях доля джун-позиций с Redis — всего 5,7%, skew 9,9 фиксирует жёсткий перекос в сторону middle и senior. На junior-позициях Redis чаще упоминается как плюс, а не требование. Для старта достаточно понимать паттерн Read-Through, команды SET/GET/EXPIRE и хранение сессий. Redis входит в стек вместе с PostgreSQL, Docker и Git — именно эти инструменты проверяют на junior-собеседованиях.

Go-разработчики — одна из самых частых ролей в Redis-вакансиях московских компаний. Зарплату определяют роль и уровень, а не сам навык; актуальные данные — в рыночном блоке этой страницы. Вилку поднимают смежные навыки: TypeScript и ClickHouse в стеке ценятся выше, а senior Go с Kubernetes и Kafka уходит в верхнюю часть рынка.

Python — одна из самых частых ролей в Redis-вакансиях московского рынка. Зарплату задают грейд и роль, а не сам навык — актуальные цифры смотрите в рыночном блоке этой страницы. Связка Celery + Redis для фоновых задач встречается почти в каждой Python-вакансии уровня middle. Kubernetes в стеке дополнительно поднимает вилку.

Простейший вариант — счётчик с TTL: INCR rate:user:123 + EXPIRE rate:user:123 60. Если счётчик превысил лимит — запрос отклоняется. Для скользящего окна используют Sorted Set: записывают запрос с timestamp как score (ZADD), удаляют устаревшие (ZREMRANGEBYSCORE), считают оставшиеся (ZCARD). Lua-скрипт делает эти операции атомарно — без гонки состояний при высоком RPS.

Сессия пишется как Hash или строка с ключом session:{token} и TTL, равным времени жизни сессии. При каждом запросе бэкенд делает HGETALL по токену из cookie — это O(1), на порядок быстрее чтения из PostgreSQL. При включённом AOF сессии переживают рестарт Redis. Все инстансы приложения ходят в один Redis — это центральное хранилище состояния при горизонтальном масштабировании.

Pipeline — механизм пакетной отправки нескольких команд за один TCP round-trip без ожидания ответа на каждую. Клиент буферизует команды, отправляет пакетом, Redis выполняет последовательно и возвращает все ответы вместе. Ускоряет пакетные операции в 5–10 раз при высокой сетевой задержке. В отличие от MULTI/EXEC pipeline не гарантирует атомарность: другие клиенты могут выполнять команды между вашими.