Redis и кэширование

01Что такое Redis на самом деле

Представьте Redis как огромный общий словарь, который живёт в оперативной памяти. Чтение из памяти занимает микросекунды, а типичный запрос к базе данных — миллисекунды, поэтому для простых выборок Redis часто в 100 раз быстрее. Но Redis — это не только ключ → строка. Он предлагает структуры данных: строки (и счётчики), хэши (объект с полями), списки (очереди), множества (уникальные элементы), сортированные множества (лидерборды, элементы по времени), стримы (лог только на добавление с группами потребителей), а также битовые карты, HyperLogLog и гео-индексы. Каждая команда выполняется атомарно в одном основном потоке, поэтому INCR на счётчике безопасен даже при множестве клиентов. Заметка о лицензиях на 2026 год: Redis 8 доступен под AGPLv3 (наряду с его source-available лицензиями), а Valkey — это форк под лицензией BSD от Linux Foundation, который большинство облаков предлагают как полноценную замену.

• String: закэшированный JSON, счётчики, флаги
• Hash: пользовательская сессия или объект настроек
• List / Stream: очереди задач и журналы событий
• Sorted set: рейтинги, запланированные элементы, rate limit со скользящим окном

1SET product:42 '{"name":"Latte","price":1500}' EX 300
2GET product:42
3INCR rate:203.0.113.10:2026-11-05T10:01
4HSET session:abc user_id 7 role cashier
5EXPIRE session:abc 1800
6ZADD leaderboard 980 player:1 1200 player:2
7ZREVRANGE leaderboard 0 9 WITHSCORES
8TTL product:42

02Паттерны кэширования: cache-aside, write-through, write-behind

Cache-aside (ленивая загрузка) — вариант по умолчанию: приложение сначала спрашивает Redis; при промахе читает базу данных, сохраняет результат с TTL и возвращает его. Кэшируется только то, что реально запрашивают, а если Redis упадёт, приложение продолжит работать, просто медленнее. Write-through означает, что каждая запись одновременно идёт в базу данных и в кэш, поэтому чтения всегда «тёплые» — хорошо для небольших данных, которые часто читают, например настроек. Write-behind сначала пишет в кэш, а в базу данных сбрасывает позже; это быстро, но может терять данные, поэтому я избегаю его для всего, что связано с деньгами. Каким бы ни был паттерн, источником истины остаётся база данных. Кэш — это копия, и вы должны иметь возможность удалить его целиком, ничего не потеряв.

1async function getMenu(branchId: string) {
2  const key = `menu:v3:${branchId}`;
3  const hit = await redis.get(key);
4  if (hit) return JSON.parse(hit);
5 
6  const menu = await db.menu.findForBranch(branchId);
7  // TTL with jitter so many keys do not expire at the same moment
8  const ttl = 600 + Math.floor(Math.random() * 60);
9  await redis.set(key, JSON.stringify(menu), "EX", ttl);
10  return menu;
11}
12 
13async function updateMenu(branchId: string, data: MenuInput) {
14  await db.menu.update(branchId, data);
15  await redis.del(`menu:v3:${branchId}`); // invalidate after the write commits
16}

03TTL, инвалидация и cache stampede

Закэшированные данные исчезают двумя способами: истекают (TTL) или вы удаляете их намеренно (инвалидация). Используйте оба: инвалидируйте при записях, которые вы контролируете, и держите TTL как страховку для записей, о которых забыли. Добавляйте версию в имена ключей (menu:v3:…), чтобы изменение формы данных никогда не приводило к чтению старых блобов. Удаляйте ключ после коммита транзакции в базе данных, а не до, иначе параллельный читатель может заново наполнить кэш устаревшими данными. Cache stampede (thundering herd) случается, когда горячий ключ истекает, и сотни запросов одновременно получают промах и все идут в базу данных. Решения: добавить к TTL случайный разброс (jitter), позволить пересобирать значение только одному запросу с помощью короткой блокировки (SET key NX EX), отдавать устаревшее значение, пока один воркер его обновляет, или обновлять популярные ключи заранее в фоне, до истечения.

1// One rebuilder per key; others wait briefly or serve stale data
2const lock = await redis.set(`lock:${key}`, "1", "NX", "EX", 10);
3if (lock === "OK") {
4  try {
5    const fresh = await loadFromDb();
6    await redis.set(key, JSON.stringify(fresh), "EX", 600);
7  } finally {
8    await redis.del(`lock:${key}`);
9  }
10}

04Сессии, rate limiting и блокировки

Redis — естественное место для короткоживущего общего состояния. Сессии: храните сессию в хэше с TTL, тогда любой сервер приложения может её прочитать, а выход из аккаунта — это один DEL. Rate limiting: фиксированное окно — это INCR по ключу вида rate:{ip}:{minute} с EXPIRE; просто, но допускает всплески на границах окна. Скользящее окно использует сортированное множество временных меток или token bucket в небольшом Lua-скрипте и даёт более плавные лимиты. Используйте ту же идею, чтобы ограничивать попытки OTP и неудачные входы по телефону или аккаунту, а не только по IP. Блокировки: SET lock:order:42 token NX EX 30 даёт одному воркеру эксклюзивную работу на 30 секунд; освобождайте блокировку, только если токен всё ещё совпадает, иначе можно удалить чужую блокировку. Когда речь о реальных деньгах, последней защитой всё равно остаются ограничение в базе данных или ключ идемпотентности.

1-- Fixed-window limit: 100 requests per 60 s, atomic in one call
2-- KEYS[1] = rate key, ARGV[1] = limit, ARGV[2] = window seconds
3local n = redis.call("INCR", KEYS[1])
4if n == 1 then
5  redis.call("EXPIRE", KEYS[1], ARGV[2])
6end
7if n > tonumber(ARGV[1]) then
8  return 0
9end
10return 1

05Очереди и pub/sub

Списки и стримы делают Redis полноценным брокером задач. Библиотеки вроде BullMQ (Node) и очередей Laravel (PHP) хранят задачи в Redis и дают повторы с backoff, задержки, приоритеты и обработку dead-letter. Веб-запрос остаётся быстрым, потому что отправка письма или синхронизация с ERP происходит в воркере. Pub/sub устроен иначе: сообщение рассылается всем, кто подписан прямо сейчас, и нигде не хранится. Это идеально для веерной рассылки real-time событий по нескольким WebSocket-серверам (Redis-адаптер socket.io делает именно это), но если никто не слушает, сообщение пропадает. Когда нужны гарантии доставки или повторное воспроизведение, используйте Streams с группами потребителей или настоящую очередь. Эмпирическое правило: pub/sub — чтобы «сказать всем сейчас», очереди — чтобы «точно убедиться, что это произойдёт».

06Персистентность, память и вытеснение

Redis хранит данные в RAM, но умеет сохранять их на диск. RDB периодически пишет снимки: компактно и быстро восстанавливается, но теряются записи с момента последнего снимка. AOF (append-only file) логирует каждую запись; с appendfsync everysec вы теряете максимум около секунды. Во многих конфигурациях используют оба. Для чистого кэша персистентность можно выключить. Для очередей и сессий включайте AOF. Всегда задавайте maxmemory и политику вытеснения: allkeys-lru или allkeys-lfu для кэша, noeviction для очереди (вам нужны ошибки, а не молча удалённые задачи). В идеале держите кэш и очередь на разных инстансах или базах с разными политиками. Никогда не открывайте порт 6379 в интернет: привязывайтесь к localhost или приватной сети, требуйте пароль или пользователей ACL и используйте TLS между сетями.

1# /etc/redis/redis.conf (cache + small queue on a private host)
2bind 127.0.0.1
3protected-mode yes
4requirepass change_me_long_random
5maxmemory 1gb
6maxmemory-policy allkeys-lfu
7appendonly yes
8appendfsync everysec
9save 900 1

07Когда не стоит кэшировать

Кэширование добавляет вторую копию истины, а каждая копия может ошибаться. Не кэшируйте, пока не измерили: часто индекс или исправленный N+1 запрос решает проблему без новых движущихся частей. Избегайте кэширования данных, которые должны быть точными в момент чтения, — остатков на checkout, балансов кошельков, статуса платежа, — или кэшируйте их только для отображения и перепроверяйте по базе данных внутри транзакции. Не кэшируйте ответы для конкретного пользователя под общим ключом (классическая утечка данных одного клиента другому). Осторожнее с кэшированием того, что меняется почти при каждом запросе: hit rate будет близок к нулю, а за записи вы всё равно платите. Наконец, если набор данных крошечный, а база данных простаивает, вам может хватить кэша в памяти процесса или HTTP-заголовков кэширования.

08Один поток: почему одна медленная команда вредит всем

Redis выполняет команды по одной в главном потоке. Начиная с Redis 6, опциональные I/O-потоки (io-threads) параллельно читают и пишут сетевые сокеты, но сами команды по-прежнему выполняются последовательно. Именно поэтому каждая команда атомарна — и именно поэтому одна O(N)-команда останавливает всех остальных клиентов. KEYS * на десяти миллионах ключей, SMEMBERS на огромном множестве, LRANGE 0 -1 на длинном списке или DEL на большом хэше могут блокировать Redis на сотни миллисекунд, а для приложения это выглядит как падение Redis. Перебирайте ключи через SCAN, HSCAN и SSCAN небольшими порциями. Большие ключи удаляйте через UNLINK — он освобождает память в фоновом потоке. Находите нарушителей заранее: SLOWLOG записывает команды дольше заданного порога, LATENCY DOCTOR объясняет всплески задержки, а redis-cli --bigkeys и --memkeys сэмплируют keyspace, не блокируя его.

1# Find big keys and memory hogs (samples with SCAN, safe in production)
2redis-cli --bigkeys
3redis-cli --memkeys
4 
5# Commands slower than slowlog-log-slower-than (microseconds)
6redis-cli SLOWLOG GET 10
7redis-cli LATENCY DOCTOR
8 
9# Memory health and cache efficiency
10redis-cli INFO memory | grep -E 'used_memory_human|mem_fragmentation_ratio'
11redis-cli INFO stats  | grep -E 'keyspace_hits|keyspace_misses|evicted_keys'
12 
13# Remove one big key without blocking the main thread
14redis-cli UNLINK report:2026:full

09Репликация, Sentinel и Cluster

Реплика копирует primary асинхронно: primary сначала отвечает клиенту, а запись отправляет потом. Если primary падает сразу после подтверждения записи, failover может повысить реплику, которая эту запись так и не получила. Команда WAIT блокирует до тех пор, пока N реплик не подтвердят запись: это сужает окно, но не превращает Redis в строго консистентную базу данных. Sentinel следит за primary и его репликами, голосует при сбое и повышает реплику; клиенты спрашивают у Sentinel, где сейчас primary. Cluster решает другую задачу — данные, которые не помещаются на одну машину: keyspace делится на 16,384 hash slot, распределённых по нескольким primary. Команды с несколькими ключами, транзакции и Lua-скрипты работают, только если все ключи попадают в один slot, иначе вы получите ошибку CROSSSLOT. Это решают hash tag: хэшируется только часть внутри {фигурных скобок}, поэтому связанные ключи оказываются вместе.

1# Only "user:42" inside the braces is hashed -> same slot
2SET {user:42}:profile '{"name":"Ana"}'
3SET {user:42}:cart '{"items":3}'
4MGET {user:42}:profile {user:42}:cart
5 
6CLUSTER KEYSLOT {user:42}:cart
7# Without a shared hash tag, MGET across slots returns CROSSSLOT

10Гонка, которая есть в любой системе cache-aside

У cache-aside есть классическая гонка. Читатель A промахивается мимо кэша и читает старую строку. Писатель B обновляет строку и удаляет ключ. Читатель A, чуть замешкавшись, записывает старое значение обратно в кэш, и оно живёт там до истечения TTL. Удаление после commit делает окно маленьким, но не нулевым. Защиты — от дешёвых к надёжным: короткие TTL для данных, где устаревание критично; повторное удаление чуть позже (delayed double delete) из job в очереди; хранение версии или updated_at вместе со значением в кэше и отказ перезаписывать более новое значение с помощью небольшого Lua-скрипта; или инвалидация, которую запускает сама база данных — через transactional outbox или change data capture, чтобы ни один участок кода не мог о ней забыть. Для очень горячих чтений client-side caching в Redis (CLIENT TRACKING, начиная с Redis 6) позволяет серверу отправлять сообщения об инвалидации в near-кэши на уровне приложения.

11Устройство памяти: eviction, кодировки и TTL для отдельных полей

Eviction приблизительный. Вместо того чтобы отслеживать идеальный порядок LRU, Redis сэмплирует несколько ключей (maxmemory-samples, по умолчанию 5) и вытесняет лучшего кандидата; увеличение выборки приближает поведение к настоящему LRU ценой некоторой нагрузки на CPU. LFU хранит для каждого ключа небольшой логарифмический счётчик обращений, который со временем затухает, поэтому ключ, популярный вчера, со временем становится кандидатом на вытеснение. Небольшие хэши, списки, множества и sorted set хранятся в компактной кодировке listpack, поэтому много маленьких хэшей часто занимают меньше памяти, чем много отдельных строковых ключей. Проверяйте отдельный ключ через MEMORY USAGE и следите за mem_fragmentation_ratio; активная дефрагментация (activedefrag yes) может возвращать фрагментированную память на лету. Начиная с Redis 7.4 поля хэша могут истекать по отдельности с помощью HEXPIRE — это удобно для сессий, где поле OTP должно исчезнуть через 60 секунд, а сама сессия продолжает жить. TTL на уровне ключа всё равно удаляет весь хэш, какими бы ни были TTL полей.