Подготовка к интервью
319 вопросов по Redis с технических собеседований
Что проверяют на интервью
На странице собраны вопросы по Redis — от проверки базовых принципов до практического применения и архитектурных решений. В подборке чаще встречаются темы: redis, database, backend.
Каталог
Используйте ограниченный локальный кеш ещё действующего токена и singleflight для его обновления, чтобы запросы не штормовали Auth Service. Истёкший или недопустимый токен нельзя принимать ради доступности.
Читать ответZSET хранит уникальных участников с числовыми score и поддерживает порядок и диапазоны; Hash хранит пары полей и значений без такой сортировки. Внутреннее представление ZSET зависит от размера.
Читать ответРаспространённые стратегии — cache-aside, read-through, write-through, write-behind и обновление или удаление кеша при записи. Redis хранит значения, но выбранную согласованность обеспечивает вся схема.
Читать ответВ коде синхронный Redis блокирует async-обработчик, запросы к БД выполняются по одному ID, а отсутствие продукта приводит к ошибке. Нужны валидация входа, пакетное чтение и контролируемый кеш.
Читать ответBGSAVE создаёт дочерний процесс через fork: ребёнок записывает снимок, а родитель продолжает обслуживать клиентов. Copy-on-Write позволяет сначала разделять страницы памяти и копировать их при изменении.
Читать ответКлючи и узлы отображаются на хеш-кольцо; ключ обслуживает следующий узел по кольцу. При изменении состава переносится часть диапазонов, а не почти все ключи, как при hash(key) % N.
Читать ответТиповой поток: склад публикует изменения в Kafka, каталог обновляет модель чтения и кеш Redis, а frontend получает данные через API. Реальная схема и формула популярности зависят от проекта.
Читать ответGossip в Redis Cluster распространяет сведения об узлах, но сам по себе не является алгоритмом консенсуса. Отдельные правила определяют подтверждение отказа и выбор новой primary-реплики.
Читать ответLua-скрипт выполняет проверку и изменение данных без вклинивания других команд Redis. Поэтому счётчик, лимит и TTL можно согласованно обновить одним вызовом вместо гонки между GET и SET.
Читать ответRedis применяют для счётчиков, ограничения частоты, рейтингов, временного состояния, очередей и потоков событий. Выбор структуры зависит от требуемых операций и гарантий сохранности.
Читать ответВ gossip узлы периодически обмениваются сведениями с частью соседей, распространяя состояние по кластеру. Отсутствие ответа вызывает подозрение в отказе, но не доказывает физическую смерть узла.
Читать ответRedis может атомарно проверить остаток и создать резерв через Lua-скрипт, не выполняя отдельные read и write. Но защита от overselling требует согласования долговечного учёта и отказов.
Читать ответ