🔴 Вопросы интервью по Redis

Ответ: Redis (Remote Dictionary Server) — это хранилище данных в памяти (in-memory), которое работает по модели ключ-значение (key-value). Благодаря тому, что данные хранятся в оперативной памяти, а не на диске, Redis обеспечивает крайне низкую задержку операций чтения и записи.

• Кэширование данных для снижения нагрузки на основную базу данных
• Хранение сессий пользователей
• Очереди сообщений и обмен событиями через Pub/Sub
• Счётчики, рейтинги и лидерборды (Sorted Set)
• Ограничение частоты запросов (rate limiting)

Ответ: Redis и реляционные СУБД (MySQL, PostgreSQL) решают разные задачи и обычно используются вместе, а не вместо друг друга.

Ответ: Redis — это не просто хранилище строк, он поддерживает несколько встроенных структур данных, каждая со своим набором команд.

• String: Простая строка или число, самый базовый тип (SET key value)
• List: Связный список строк, удобен для очередей (LPUSH, RPUSH, LRANGE)
• Hash: Отображение поле → значение, аналог объекта (HSET, HGET, HGETALL)
• Set: Неупорядоченное множество уникальных строк (SADD, SMEMBERS, SINTER)
• Sorted Set: Множество с весом (score) у каждого элемента, элементы упорядочены по весу (ZADD, ZRANGE) — удобен для рейтингов

Ответ: Хотя Redis хранит данные в памяти, он поддерживает два механизма сохранения данных на диск, чтобы не потерять их при перезапуске.

Ответ: TTL (Time To Live) — это время жизни ключа, после которого Redis автоматически удаляет его. Это ключевой механизм для реализации кэша, чтобы данные не хранились бесконечно.

SET session:123 "userdata"
EXPIRE session:123 3600      // ключ удалится через 3600 секунд

TTL session:123              // вернёт оставшееся время жизни в секундах

PERSIST session:123          // убирает TTL, ключ больше не истечёт

SET session:123 "userdata" EX 3600   // задать значение с TTL сразу
                

Ответ: Ниже приведены самые часто используемые команды для двух базовых типов данных.

SET user:1:name "Alice"
GET user:1:name

INCR page:views              // атомарно увеличивает числовое значение на 1
INCRBY page:views 10

SETNX lock:order:5 "locked"  // установить значение, только если ключа ещё нет
                

HSET user:1 name "Alice" age "30"
HGET user:1 name
HGETALL user:1
HDEL user:1 age
                

Ответ: Pub/Sub (publish/subscribe) — это механизм обмена сообщениями, при котором отправители (publishers) публикуют сообщения в именованные каналы, а получатели (subscribers) подписываются на нужные каналы и получают сообщения в реальном времени.

// Подписчик
SUBSCRIBE notifications

// Издатель (из другого клиента)
PUBLISH notifications "Новый заказ #123"
                

• Сообщения не сохраняются — если подписчика не было онлайн в момент публикации, он не получит сообщение
• Подходит для оповещений в реальном времени, но не для надёжной очереди задач
• Для надёжной доставки сообщений чаще используют Redis Streams или отдельный брокер сообщений (Kafka, RabbitMQ)

Ответ: Cache-aside (он же lazy loading) — самый распространённый паттерн кэширования: приложение само управляет тем, когда читать из кэша, а когда обращаться к основной базе данных.

• При чтении: сначала проверить кэш; если данные есть (cache hit) — вернуть их
• Если данных нет (cache miss) — прочитать из базы данных, записать результат в кэш с TTL, затем вернуть его
• При обновлении данных в базе — удалить (инвалидировать) соответствующий ключ в кэше, а не пытаться обновлять его напрямую

Ответ: Репликация Redis построена по схеме master-replica: один узел (master) принимает все операции записи, а один или несколько узлов-реплик (replica) асинхронно копируют данные с master и могут обслуживать запросы на чтение.

• Повышает доступность на чтение — запросы GET можно распределять между репликами
• Реплики служат резервной копией данных на случай сбоя master
• Репликация асинхронная, поэтому возможна кратковременная задержка (replication lag) между master и репликами
• Сама по себе репликация не обеспечивает автоматический failover — для этого нужен Redis Sentinel

Ответ: Redis Sentinel — это система мониторинга и автоматического failover для конфигурации master-replica. Она следит за состоянием узлов и обеспечивает высокую доступность (high availability) без ручного вмешательства.

• Постоянно проверяет доступность master и реплик
• При обнаружении сбоя master автоматически выбирает одну из реплик и повышает её до нового master (failover)
• Уведомляет клиентские приложения о смене master, чтобы они переключились на новый адрес
• Обычно запускается в виде нескольких процессов Sentinel (кворум), чтобы избежать ложных срабатываний из-за сбоя одного наблюдателя

Ответ: Redis Cluster — это встроенное решение для горизонтального масштабирования, которое распределяет (шардирует) данные между несколькими узлами, каждый из которых хранит только часть всего набора данных.

• Всё пространство ключей делится на 16384 хэш-слота; каждый узел отвечает за часть слотов
• Позволяет хранить данные, которые не поместились бы в память одного сервера
• Каждый шард может иметь свои реплики для отказоустойчивости, аналогично master-replica
• Операции, затрагивающие ключи из разных слотов (например, некоторые multi-key команды), могут быть ограничены — это нужно учитывать при проектировании ключей

Ответ: Redis отлично подходит для одних задач и плохо — для других, поскольку оптимизирован под скорость доступа к данным в памяти, а не под сложные запросы или гарантированную долговременную сохранность.

• Кэширования результатов дорогих вычислений или запросов к базе данных
• Хранения сессий пользователей в веб-приложениях
• Очередей задач и Pub/Sub-уведомлений в реальном времени
• Счётчиков, рейтингов, ограничения частоты запросов (rate limiting)

• Основное хранилище критичных данных без настроенной персистентности (RDB/AOF) и репликации
• Замену реляционной базе данных там, где нужны сложные запросы с JOIN, транзакции между множеством сущностей или строгая консистентность
• Хранилище данных, объём которых значительно превышает доступную оперативную память (без Redis Cluster)