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

7.1Зачем кэш и уровни кэширования

Тема базовая, но именно на ней чаще всего сыплются, причём на простом вопросе «а чем ты за кэш платишь?». Сам по себе кэш систему не ускоряет: он меняет одну характеристику на другую, и назвать надо обе.

Что такое кэш на самом деле

Кэш хранит копию данных ближе и дешевле, чем источник правды, и сознательно не гарантирует, что копия актуальна. Всё прочее уже детали реализации. Держится он на двух свойствах реальной нагрузки:

• Временна́я локальность. Если ключ запросили сейчас, скорее всего, его запросят ещё раз в ближайшие секунды. Так ведут себя лента, карточка популярного товара, профиль автора, настройки фичефлагов.
• Перекос распределения (skew). Обращения к ключам почти никогда не бывают равномерными: распределение Zipf-подобное, и 1 % ключей даёт 50–90 % трафика. Поэтому кэша на 2 ГБ и хватает на таблицу в 2 ТБ.

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

Четыре слова, которые дальше встречаются в каждом абзаце

Попадание (hit) значит, что запрошенный ключ нашёлся в кэше и до источника дело не дошло. При промахе (miss) ключа нет: идём в источник правды и обычно кладём результат в кэш. Доля попаданий среди всех обращений называется hit rate. Это главная метрика кэша, и ниже ей отведён отдельный раздел: читают её чаще всего неправильно.

По истечении TTL (time to live, «время жизни») ключ сам исчезает из кэша. Смысл TTL не в экономии памяти: он задаёт верхнюю границу вранья, и TTL 60 секунд означает «мы согласны, что минуту пользователь может видеть устаревшие данные». Выбирают его от допустимого отставания, а не «ну пусть будет пять минут».

Инвалидацией копию объявляют негодной, то есть отвечают на вопрос «когда выбросить из кэша то, что в источнике уже изменилось». Проще всего дождаться истечения TTL; второй способ — явно удалить ключ в момент записи. Как их сочетают и где эта конструкция протекает, разобрано в главе 7.4.

При вытеснении (eviction) ключ выбрасывают принудительно, и не потому, что он устарел, а потому, что кончилась память. Разница принципиальная: истечение TTL ты запланировал сам, а вытеснение случается когда угодно и с чем угодно — в том числе с ключом, который ты положил секунду назад. Отсюда правило, к которому всё в итоге сведётся: код обязан работать корректно, даже если любой ключ пропадёт в любой момент.

Чем платим

Уровни кэширования на пути запроса

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

Локальный in-process кэш против распределённого

С этой развилки проектирование и начинается. Локальный кэш живёт внутри процесса: обычная мапа под RWMutex или готовая библиотека (ristretto, otter, golang-lru). Распределённый работает отдельным сервисом, общим для всех реплик.

В нагруженных сервисах их комбинируют: L1 держат локально на 1–5 секунд, L2 в Redis на минуты. Локальный слой снимает с Redis «горячий хвост» (тот самый 1 % ключей с половиной трафика) и заодно решает проблему горячего ключа в кластере.

// Двухуровневый кэш: L1 в памяти на 2 с, L2 в Redis на 5 мин.
type TwoLevel struct {
    l1  *ristretto.Cache // локальный, TTL 2 с
    rdb *redis.Client
    db  *sql.DB
}

func (c *TwoLevel) User(ctx context.Context, id int64) (*User, error) {
    key := fmt.Sprintf("user:v1:%d", id)

    if v, ok := c.l1.Get(key); ok {            // ~100 нс, без сети
        return v.(*User), nil
    }
    b, err := c.rdb.Get(ctx, key).Bytes()      // ~0,4 мс
    if err == nil {
        u := new(User)
        if json.Unmarshal(b, u) == nil {
            c.l1.SetWithTTL(key, u, 1, 2*time.Second)
            return u, nil
        }
    }
    if err != nil && err != redis.Nil {
        // Redis недоступен: логируем и идём в БД, а не падаем.
        metrics.CacheErrors.Inc()
    }
    u, err := loadFromDB(ctx, c.db, id)        // ~10 мс
    if err != nil {
        return nil, err
    }
    b, _ = json.Marshal(u)
    c.rdb.Set(ctx, key, b, 5*time.Minute)
    c.l1.SetWithTTL(key, u, 1, 2*time.Second)
    return u, nil
}

Метрики: hit rate и что он на самом деле означает

Считают прежде всего hit rate (долю попаданий):

hit_rate = hits / (hits + misses)

На собеседовании часто спрашивают, какой hit rate считается хорошим. Ответ: сам по себе hit rate ничего не значит, значение имеют три производных числа.

1. Эффективная латентность

Промах обходится дороже прямого обращения к БД: сначала мы сходили в кэш за nil и только потом пошли в источник. Формула:

L = h * L_hit + (1 - h) * (L_hit + L_source)

Возьмём L_hit = 0,3 мс и L_source = 20 мс: 90 % попаданий дают 2,3 мс, а 99 % уже 0,5 мс, то есть ответ быстрее почти впятеро. Сама латентность падает по h линейно: каждый процент снимает те же 0,2 мс. Нелинеен выигрыш в разах: при 99 % промахов вдесятеро меньше, чем при 90 %, и каждый следующий процент hit rate даётся дороже предыдущего.

2. Абсолютное число промахов в секунду

В БД попадает именно оно, а не проценты. Hit rate 99 % при 10 000 rps пропускает в источник 100 rps; тот же 99 % при 1 000 000 rps пропускает уже 10 000 rps, и БД от такого ляжет. Поэтому в алертах держат misses_per_second, а не только процент.

3. Хвост латентности

С кэшем медиана падает почти до L_hit, а p99 остаётся равным латентности источника — этот 1 % запросов туда и уходит. Если SLA сформулирован по p99, кэш с hit rate 95 % его почти не улучшит. Аргумент сильный, а в разговоре его почти никто не приводит.

Когда кэш не нужен и когда он вредит

• Нет повторяемости ключей. Каждый запрос уникален (поиск по произвольным фильтрам, выгрузка отчётов по диапазонам). Hit rate будет 5 %, а каждый запрос получит лишний round-trip.
• Источник и так быстрый. Выборка по первичному ключу из прогретого буферного пула занимает 0,2–0,5 мс, столько же, сколько поход в Redis по сети. Выигрыша нет, сложность есть.
• Данные не имеют права быть устаревшими. Баланс перед списанием, остаток товара в момент оформления заказа, права доступа при проверке авторизации, статус блокировки пользователя. Здесь кэш грозит не «немного стухшими данными», а инцидентом безопасности или деньгами.
• Пишут чаще, чем читают. При соотношении 1 read / 1 write кэш инвалидируется быстрее, чем успевает пригодиться: получаем нагрузку и на БД, и на Redis.
• Кэш вместо индекса. Классический анти-паттерн: запрос делает seq scan на 3 секунды, его закрывают кэшем — и живут так, пока однажды кэш не окажется пустым.
• Кэш вместо исправления N+1. Тот же случай: лечат это IN (...) или джойн, а не «закэшируем каждую из 200 подгрузок».

const missMarker = "\x00miss"

v, err := rdb.Get(ctx, key).Result()
switch {
case err == nil && v == missMarker:
    return nil, ErrNotFound            // ключа точно нет, в БД не идём
case err == nil:
    return decode(v)
case err == redis.Nil:
    u, err := loadFromDB(ctx, id)
    if errors.Is(err, sql.ErrNoRows) {
        rdb.Set(ctx, key, missMarker, 60*time.Second)
        return nil, ErrNotFound
    }
    ...
}

7.2Redis: устройство и почему он быстрый

Вопрос «почему Redis быстрый» задают почти всегда. Ответ «потому что в памяти» засчитают только наполовину. Вторую половину дают однопоточная модель выполнения, мультиплексирование сокетов и очень дешёвый протокол — и оттуда же растут все ограничения.

Что такое Redis

Redis (REmote DIctionary Server) — сервер структур данных в памяти. Ключ в нём всегда бинарно-безопасная строка, а значение — одна из встроенных структур: строка, хеш, список, множество, упорядоченное множество, битовая карта, HyperLogLog, поток, geo-индекс, а с Redis 8 ещё vector set, JSON и time series. От «мапы по сети» его отличает главное: сервер выполняет операции над структурой на своей стороне (инкремент, добавление в множество, выборку топ-10 по рангу), поэтому значение не надо тащить к клиенту, менять и класть обратно. Отсюда и производительность, и бесплатная атомарность.

Redis используют как кэш, брокер (pub/sub, Streams), хранилище сессий, счётчик, распределённый лок, лидерборд и очередь. Персистентностью (persistence, «сохраняемость») называют способность пережить перезапуск процесса: данные живут в памяти, но их копия периодически или постоянно уходит на диск. У Redis она есть (два механизма, RDB и AOF), но гарантий уровня СУБД не даёт, подробнее об этом в главе 7.6.

Почему быстрый: пять причин, а не одна

1. Всё в оперативной памяти. На пути запроса нет ни одного обращения к диску. Даже AOF пишется в буфер и сбрасывается фоново (по умолчанию раз в секунду).
2. Команды выполняются в одном потоке. Ни мьютексов, ни атомиков, ни переключений контекста, ни борьбы за строки кэша между ядрами. Каждая команда атомарна просто потому, что во время её выполнения ничего другого не происходит. Заодно исчезает целый класс багов, а такты не уходят на синхронизацию.
3. Мультиплексирование ввода-вывода. Один поток обслуживает десятки тысяч соединений через epoll (Linux), kqueue (BSD/macOS), evport (Solaris) или select как запасной вариант. Никакого «поток на клиента».
4. Дешёвый протокол RESP. Текстово-бинарный, длины передаются явно, парсер линейный, без разбора грамматики и без рефлексии.
5. Специализированные компактные кодировки. Маленький хеш хранится не хеш-таблицей, а listpack: это сплошной кусок памяти, который влезает в кэш процессора. Множество целых чисел лежит отсортированным intset, а короткая строка ложится в embstr одним куском вместе с заголовком объекта.

И отдельно: у Redis нет планировщика запросов, нет MVCC, нет журнала транзакций на пути записи, нет проверки ограничений целостности. Он не делает почти ничего из того, на что тратит время СУБД.

Что именно значит «однопоточный»

Формулировка, которую стоит держать наготове: Redis выполняет команды в один поток; всё остальное может быть многопоточным. По версиям:

Отсюда вывод: чтобы загрузить 16 ядер, одного процесса Redis мало. Масштабируются либо несколькими инстансами на машине (по одному на ядро, разные порты), либо через Redis Cluster. Вертикально Redis растёт в основном по памяти: лишние ядра займут разве что потоки ввода-вывода.

Протокол RESP

RESP (REdis Serialization Protocol) выглядит текстовым, но по сути бинарно-безопасен. Первый байт задаёт тип, \r\n завершает элемент, у строк длина передаётся явно, поэтому в значении могут быть любые байты, включая нули и переводы строк. Клиентские библиотеки всегда шлют команду массивом bulk-строк.

# отправить кадр руками: ровно те байты, что уходят на провод
$ printf '*3\r\n$3\r\nSET\r\n$6\r\nuser:1\r\n$4\r\nIvan\r\n' | nc localhost 6379
+OK
$ printf 'PING\r\n' | nc localhost 6379      # inline-команды тоже принимаются
+PONG

# переключить соединение в RESP3
$ redis-cli HELLO 3

Сложность команд и запрещённые в проде

SCAN: как обходить ключи правильно

SCAN обходит ключи по курсору. Каждый вызов возвращает новый курсор и порцию ключей; обход закончен, когда курсор снова стал 0. Работа идёт маленькими кусками, и между вызовами сервер спокойно обслуживает других клиентов.

# плохо: блокирует сервер целиком
KEYS session:*

# плохо: то же самое из кода
rdb.Keys(ctx, "session:*")

# хорошо: курсор, порциями
SCAN 0 MATCH session:* COUNT 500       # ответ: курсор 17408 и порция ключей
SCAN 17408 MATCH session:* COUNT 500   # ответ: курсор 0, обход завершён

// Итератор go-redis сам крутит курсор и проверяет ctx.
iter := rdb.Scan(ctx, 0, "session:*", 500).Iterator()
var batch []string
for iter.Next(ctx) {
    batch = append(batch, iter.Val())
    if len(batch) == 500 {
        // Удаляем пачками через UNLINK: большие значения освободит фоновый поток.
        if err := rdb.Unlink(ctx, batch...).Err(); err != nil {
            return err
        }
        batch = batch[:0]
    }
}
if err := iter.Err(); err != nil {
    return err
}
if len(batch) > 0 {
    return rdb.Unlink(ctx, batch...).Err()
}
return nil

Блокирующие команды: кого они блокируют

BLPOP, BRPOP, BLMOVE, BLMPOP, BZPOPMIN, XREAD BLOCK и WAIT не блокируют сервер. Redis снимает клиента с обработки, записывает его в список ожидающих на конкретный ключ и продолжает крутить цикл событий. Когда кто-то делает LPUSH, сервер будит ожидающих в порядке очереди сразу после выполнения этого LPUSH. Подвох популярный: «блокирующая команда» звучит страшно, но блокируется только соединение клиента.

// Воркер очереди: висим на BRPOP до 5 секунд, потом повторяем.
// Таймаут нужен, чтобы горутина реагировала на отмену контекста.
for {
    res, err := rdb.BRPop(ctx, 5*time.Second, "queue:jobs").Result()
    if err == redis.Nil {
        continue                       // по таймауту просто повторяем
    }
    if err != nil {
        if ctx.Err() != nil {
            return ctx.Err()           // сервис останавливается
        }
        time.Sleep(200 * time.Millisecond)
        continue
    }
    handle(res[1])                     // res[0] - имя ключа, res[1] - значение
}

Redis против Memcached

Короткий ответ на собеседовании: Memcached — это распределённая мапа, Redis — сервер структур данных. Memcached выигрывает ровно в одном сценарии: когда нужна многопоточность на одной машине при предельно простом доступе. Во всех остальных берут Redis, потому что структуры и атомарные операции на сервере закрывают целые классы задач (счётчики, лидерборды, локи, рейт-лимиты).

$ redis-cli SET n 12345
$ redis-cli OBJECT ENCODING n            # "int"
$ redis-cli SET s "короткая строка"
$ redis-cli OBJECT ENCODING s            # "embstr"
$ redis-cli HSET h f1 v1
$ redis-cli OBJECT ENCODING h            # "listpack"
$ redis-cli MEMORY USAGE h               # сколько байт реально занимает ключ

# инструменты диагностики, которые стоит назвать на собесе
$ redis-cli --latency-history            # латентность в динамике
$ redis-cli --bigkeys                    # самые большие ключи каждого типа (через SCAN)
$ redis-cli --hotkeys                    # нужна LFU-политика: allkeys-lfu или volatile-lfu
$ redis-cli SLOWLOG GET 10               # команды дольше slowlog-log-slower-than (10 000 мкс)
$ redis-cli INFO commandstats            # усреднённое время на каждую команду

SCAN 0 MATCH "session:*" COUNT 500
SCAN 17408 MATCH "session:*" COUNT 500
# ... пока не вернётся курсор 0

7.3Структуры данных Redis и сценарии

Перечислить пять типов может кто угодно. Сильный ответ к каждому типу приводит реальную задачу, команду и сложность и объясняет, почему здесь нужен именно он, а не соседний.

Карта типов

string: счётчики и rate limit

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

// Счётчик просмотров: одна команда, атомарно, без гонок.
views, err := rdb.Incr(ctx, "post:42:views").Result()

// Пакетный сброс в БД раз в минуту (write-behind, см. 7.4):
// забираем значение и обнуляем одной атомарной операцией
n, _ := rdb.GetDel(ctx, "post:42:views").Int64()   // до Redis 6.2: GETSET key 0

Rate limit: фиксированное окно

Проще всего устроен лимит «не больше N запросов в минуту»: минута в имени ключа, счётчик растёт, а TTL с запасом ставится вместе с каждым инкрементом.

// Ключ вида rl:user:42:29795911: номер минуты от эпохи, TTL чуть больше окна.
key := fmt.Sprintf("rl:%s:%d", userID, time.Now().Unix()/60)

pipe := rdb.TxPipeline()
incr := pipe.Incr(ctx, key)
pipe.Expire(ctx, key, 70*time.Second)   // TTL с запасом, чтобы ключ точно умер
if _, err := pipe.Exec(ctx); err != nil {
    return false, err                   // Redis лёг: пропускать или резать, решай сам
}
return incr.Val() <= limit, nil

Rate limit: скользящее окно на sorted set

// Один Lua-скрипт вместо четырёх round-trip: удалить старое, посчитать, добавить, продлить.
var slidingWindow = redis.NewScript(`
local key    = KEYS[1]
local now    = tonumber(ARGV[1])   -- текущее время в мс
local window = tonumber(ARGV[2])   -- размер окна в мс
local limit  = tonumber(ARGV[3])
local id     = ARGV[4]             -- уникальный идентификатор запроса

redis.call('ZREMRANGEBYSCORE', key, 0, now - window)
local used = redis.call('ZCARD', key)
if used >= limit then
  return {0, used}
end
redis.call('ZADD', key, now, id)
redis.call('PEXPIRE', key, window)
return {1, used + 1}
`)

res, err := slidingWindow.Run(ctx, rdb,
    []string{"rl:sw:" + userID},
    time.Now().UnixMilli(), 60_000, 100, uuid.NewString(),
).Slice()

За точность платят памятью: в zset лежит запись на каждый запрос в окне. При лимите 100/мин это копейки, при 100 000/мин на каждого пользователя уже нет. Тогда берут token bucket: в хеше лежат tokens и last_refill, Lua-скрипт доливает токены по прошедшему времени, и память на пользователя остаётся постоянной.

hash: сессии и объекты

Хеш выигрывает у «JSON в строке», когда нужно читать или менять отдельные поля. HINCRBY атомарно увеличивает поле, не читая весь объект, а HMGET достаёт три поля из тридцати и не гоняет по сети остальные.

# объект как JSON в строке
SET user:42 '{"name":"Иван","age":30,"visits":7}'
# поменять visits: GET, распарсить,
# изменить, сериализовать, SET
# - два round-trip и гонка между ними

# объект как hash
HSET user:42 name Иван age 30 visits 7
HINCRBY user:42 visits 1     # атомарно, O(1)
HMGET user:42 name age       # только нужные поля
HGET  user:42 name           # без лишнего трафика

list: очередь задач

Список двусвязный (физически это quicklist из listpack-узлов, а маленький — один listpack), поэтому вставка и удаление по краям стоят O(1), а обращение к середине O(N). Отсюда два честных применения: очередь/стек и «последние N».

# Очередь FIFO: кладём слева, забираем справа
LPUSH  queue:jobs '{"id":1,"type":"email"}'
BRPOP  queue:jobs 5              # ждём до 5 с, блокируется только клиент

# «Последние 100 событий» постоянного размера без внешней чистки
LPUSH  user:42:feed "event"
LTRIM  user:42:feed 0 99         # O(N) по числу удалённых, здесь по одному

# Надёжная очередь: атомарно перекладываем в processing
BLMOVE queue:jobs queue:processing RIGHT LEFT 5
# ... обработали ...
LREM   queue:processing 1 '{"id":1,...}'

set: уникальность и множества

SADD  post:42:likes 7 9 13        # идемпотентно: повтор ничего не меняет
SCARD post:42:likes               # O(1): размер не пересчитывается
SISMEMBER post:42:likes 9         # O(1)
SPOP  raffle:participants 3       # розыгрыш: 3 случайных, сразу удаляются

SINTER  user:1:friends user:2:friends       # общие друзья, O(N*M)
SINTERCARD 2 user:1:friends user:2:friends LIMIT 100   # 7.0: только размер, с ограничением
SRANDMEMBER feed:pool 5           # 5 случайных, не удаляя

Пока в множестве только целые и их не больше set-max-intset-entries, оно лежит отсортированным intset: компактно, поиск бинарный. Так дёшево хранить «кому показали баннер» или «какие id уже обработаны», если идентификаторы числовые.

sorted set: лидерборд, отложенные задачи, индекс по времени

Sorted set держит две структуры одновременно: словарь member → score для ZSCORE за O(1) и список с пропусками (skiplist), упорядоченный по score, для диапазонных запросов и рангов за O(log N). Каждый узел skiplist хранит ещё и span — число элементов, которые перепрыгивает ссылка. По нему ранг считается без прохода по списку.

# Лидерборд
ZADD  game:lb 1500 "player:7"          # O(log N)
ZINCRBY game:lb 25 "player:7"          # начислили очки
ZREVRANGE game:lb 0 9 WITHSCORES       # топ-10
ZREVRANK  game:lb "player:7"           # моё место, O(log N)
ZCOUNT    game:lb 1000 2000            # сколько игроков в диапазоне

# Отложенные задачи: score = время запуска в миллисекундах
ZADD  jobs:delayed 1756209600000 "job:991"
ZRANGEBYSCORE jobs:delayed 0 <now> LIMIT 0 100    # что пора выполнить
# забирать надо атомарно, иначе двое воркеров возьмут одну задачу.
# ZPOPMIN не годится: заберёт и задачи из будущего. Нужен Lua-скрипт:
# ZRANGEBYSCORE по now, затем ZREM этих же id — одной операцией

bitmap и HyperLogLog: считать дёшево

# Битовая карта: активность пользователя по дням года
SETBIT   user:42:active:2026 238 1     # в день 238 заходил
BITCOUNT user:42:active:2026           # сколько дней всего был активен
BITPOS   user:42:active:2026 1         # первый день активности

# DAU: бит на каждого пользователя за день
SETBIT   dau:2026-08-26 42 1
BITCOUNT dau:2026-08-26                # уникальные за день, точно
BITOP AND weekly dau:2026-08-20 dau:2026-08-21   # кто был оба дня
# 10 млн пользователей = 10^7 бит = 1,25 МБ на день. Точно и очень дёшево,
# но только если id плотные и числовые.

# HyperLogLog: уникальные без хранения самих значений
PFADD   uv:2026-08-26 "ip:1.2.3.4" "ip:5.6.7.8"
PFCOUNT uv:2026-08-26                  # до 12 КБ на ключ, ошибка ~0,81 %
PFMERGE uv:week uv:2026-08-20 uv:2026-08-21 uv:2026-08-22

Спрашивают про разницу: bitmap точен, но требует плотных числовых идентификаторов и памяти пропорционально максимальному id. HyperLogLog приблизителен (стандартная ошибка 0,81 %), зато занимает не больше 12 КБ, будь там миллион уникальных или миллиард, и принимает любые строки. Сами элементы из HLL не достать, и вычитать HLL нельзя, только объединять через PFMERGE.

stream: лента событий с подтверждениями

Stream устроен как append-only лог. Каждая запись получает монотонно растущий ID вида <миллисекунды>-<порядковый>. В отличие от pub/sub, данные сохраняются, и новый потребитель может прочитать историю. Самое ценное здесь consumer group: группа помнит, до какого ID дошла, и ведёт PEL (Pending Entries List) — список выданных, но ещё не подтверждённых записей.

# Продюсер: добавляем событие, автоматически обрезая старое
XADD events:orders MAXLEN ~ 100000 * type order.paid id 991 amount 1200

# Группу создаём один раз: $ = только новое, 0 = с начала
XGROUP CREATE events:orders workers $ MKSTREAM

# Консьюмер: читаем новые записи (символ > означает «то, что ещё никому не выдавали»)
XREADGROUP GROUP workers worker-1 COUNT 10 BLOCK 5000 STREAMS events:orders >

# Подтверждаем обработку
XACK events:orders workers 1712-1

# Забираем зависшее у мёртвых воркеров: всё, что простаивает дольше 60 с
XAUTOCLAIM events:orders workers worker-3 60000 0 COUNT 10
XPENDING   events:orders workers          # сводка: сколько и у кого

Как выбирать структуру

INCR   rl:user42:202608261431
EXPIRE rl:user42:202608261431 70

HSET   sess:abc123 uid 42 ip 1.2.3.4 csrf xyz
EXPIRE sess:abc123 1800              # скользящий TTL, продлевать при обращении
SADD   user:42:sessions abc123       # обратный индекс для «выйти везде»

LPUSH queue:jobs "{...}"
BRPOP queue:jobs 5

BLMOVE queue:jobs queue:processing RIGHT LEFT 5   # атомарно переложили
# ... обработали ...
LREM   queue:processing 1 "{...}"                 # сняли из обработки

ZINCRBY  game:lb 25 player:7        # начислили очки, O(log N)
ZREVRANGE game:lb 0 9 WITHSCORES    # топ-10
ZREVRANK  game:lb player:7          # место игрока, O(log N)
ZCOUNT    game:lb 1000 2000         # сколько в диапазоне очков

SETBIT   dau:2026-08-26 42 1
BITCOUNT dau:2026-08-26                       # точное число уникальных
BITOP AND both dau:2026-08-25 dau:2026-08-26  # кто был оба дня
BITCOUNT both

PFADD   uv:2026-08-26 user:42 ip:1.2.3.4 fp:abcdef
PFCOUNT uv:2026-08-26
PFMERGE uv:week uv:2026-08-20 uv:2026-08-21   # объединение без потери точности

7.4Стратегии кэширования и инвалидация

Знать слова «cache-aside» и «write-through» мало. Проверяют понимание: кто в каждой схеме ходит в БД, что будет при сбое каждого из двух хранилищ и какая именно гонка ломает консистентность. Лучше всего в этой секции работает разбор гонки на оси времени.

Пять стратегий: кто ходит в источник правды

Все стратегии отличаются ровно двумя вещами: кто ходит в БД при промахе и когда запись доезжает до БД. Всё остальное из этого следует.

Cache-aside (lazy loading) по шагам

Эта схема стоит в 90 % продакшенов: ей не нужно ничего, кроме клиента Redis.

1. Чтение. GET key. Есть значение — отдали, конец.
2. Промах. Клиент возвращает redis.Nil. Идём в БД, к источнику правды.
3. Заполнение. Сериализуем и SET key value EX ttl. Ошибку записи в кэш глотаем: не закэшировали — просто будет ещё один промах.
4. Запись. Сначала UPDATE в БД. Только после успеха делаем DEL key.

func (r *UserRepo) Get(ctx context.Context, id int64) (User, error) {
    key := fmt.Sprintf("user:v3:%d", id)

    // 1. Пробуем кэш.
    b, err := r.rdb.Get(ctx, key).Bytes()
    switch {
    case err == nil:
        var u User
        if json.Unmarshal(b, &u) == nil {
            r.m.Hit()
            return u, nil                 // попадание
        }
        // Битые данные в кэше лечим как промах, а не как ошибку.
    case errors.Is(err, redis.Nil):
        r.m.Miss()                        // честный промах
    default:
        // Redis недоступен или таймаут. Это не ошибка запроса:
        // кэш лишь ускоряет, деградируем до чтения из БД.
        r.m.CacheError()
    }

    // 2. Идём в источник правды.
    u, err := r.db.LoadUser(ctx, id)
    if err != nil {
        return User{}, err                // вот это уже настоящая ошибка
    }

    // 3. Заполняем кэш. Ошибку намеренно игнорируем.
    if raw, e := json.Marshal(u); e == nil {
        _ = r.rdb.Set(ctx, key, raw, jitter(5*time.Minute)).Err()
    }
    return u, nil
}

func (r *UserRepo) Rename(ctx context.Context, id int64, name string) error {
    if err := r.db.UpdateName(ctx, id, name); err != nil {
        return err                        // 1. источник правды первым
    }
    // 2. Инвалидация. Ошибку логируем, но пользователю не возвращаем:
    // запись уже зафиксирована, откатывать нечего. Спасёт TTL.
    if err := r.rdb.Del(ctx, fmt.Sprintf("user:v3:%d", id)).Err(); err != nil {
        r.log.Warn("cache invalidate failed", "key", id, "err", err)
    }
    return nil
}

Что происходит при сбоях

Read-through, write-through, write-behind, refresh-ahead

Read-through

Приложение видит один метод cache.Get(key); за промах отвечает сам слой кэша, который вызывает зарегистрированный loader. Redis из коробки так не умеет, этим занимается библиотека или твоя собственная обёртка. Зато логика «промах → загрузка → запись» живёт в одном месте, и туда же удобно повесить singleflight, метрики, ограничение конкурентности и негативное кэширование.

// Минимальный read-through поверх go-redis.
type Cache[T any] struct {
    rdb    *redis.Client
    ttl    time.Duration
    group  singleflight.Group
}

func (c *Cache[T]) GetOrLoad(ctx context.Context, key string,
    load func(context.Context) (T, error)) (T, error) {

    var zero T
    if b, err := c.rdb.Get(ctx, key).Bytes(); err == nil {
        var v T
        if json.Unmarshal(b, &v) == nil {
            return v, nil
        }
    }
    // Промах: ровно один поход в БД на ключ (см. 7.5).
    v, err, _ := c.group.Do(key, func() (any, error) {
        val, err := load(ctx)
        if err != nil {
            return zero, err
        }
        if raw, e := json.Marshal(val); e == nil {
            _ = c.rdb.Set(ctx, key, raw, jitter(c.ttl)).Err()
        }
        return val, nil
    })
    if err != nil {
        return zero, err
    }
    return v.(T), nil
}

Write-through

Запись идёт в кэш, кэш синхронно пишет в БД, и только потом клиенту отвечают «ок». Кэш и БД никогда не расходятся по содержимому, но за это платим латентностью: время записи = время Redis + время БД, и появляется вопрос атомарности (записали в Redis, БД упала — надо откатывать Redis, а транзакции между ними нет). Схема окупается там, где записанное почти наверняка сразу прочитают: профиль пользователя, корзина, настройки. На write-heavy таблицах, которые читают редко, write-through просто тратит память.

Write-behind (write-back)

Клиенту отвечают сразу после записи в кэш, а в БД изменения уезжают асинхронно — пачками и с дедупликацией. Только эта схема пишет быстрее, чем умеет сама БД: тысяча инкрементов счётчика превращается в один UPDATE ... SET n = n + 1000. Цена прямая: подтверждённая пользователю запись может быть потеряна, если кэш умрёт до слива. Плюс в БД временно лежит старое значение, а значит любой сторонний потребитель (аналитика, репликация, другой сервис) читает неправду.

Refresh-ahead

Значение обновляют до истечения TTL: либо по расписанию для заранее известного списка горячих ключей, либо при обращении, по правилу «если до истечения осталось меньше 20 %, отдай текущее значение и запусти фоновое обновление». Пользователь никогда не платит за промах, а stampede на истечении просто не возникает. Платим за это прогревом того, что может больше не понадобиться, а если горячее множество угадали плохо, БД получает лишнюю постоянную нагрузку.

// Refresh-ahead поверх обычного значения: храним рядом отметку "пора обновлять".
type entry struct {
    Val       json.RawMessage `json:"v"`
    RefreshAt int64           `json:"r"` // unix-время раннего обновления
}

func (c *Cache[T]) getAhead(ctx context.Context, key string, load loader[T]) (T, error) {
    e, err := c.read(ctx, key)
    if err == nil {
        if time.Now().Unix() > e.RefreshAt {
            // Старое отдаём сразу, обновляем в фоне ровно одним потоком.
            go func() {
                bg, cancel := context.WithTimeout(context.Background(), 3*time.Second)
                defer cancel()
                _, _, _ = c.group.Do("refresh:"+key, func() (any, error) {
                    return nil, c.reload(bg, key, load)
                })
            }()
        }
        var v T
        return v, json.Unmarshal(e.Val, &v)
    }
    return c.GetOrLoad(ctx, key, load)
}

Инвалидация: TTL, событие, версия ключа

Инвалидация решает, когда копия перестаёт считаться годной. Способов ровно три, и в живой системе обычно работают все сразу.

1. По TTL

Самый надёжный и самый тупой способ: ключ живёт N секунд и умирает. Не требует ничего от кода записи, переживает пропущенные события, чинит рассинхрон после любого сбоя. Но данные могут устаревать на весь TTL. TTL берут не «по вкусу», а из бизнес-требования: если «карточка товара может отставать на минуту», ставят TTL 60 секунд. Если допустимое отставание сформулировать не могут, кэшировать эту сущность пока рано.

2. По событию

При изменении сущности удаляем ключ явно: DEL user:42. Данные становятся свежими почти сразу. Сложность в полноте: изменение одной строки часто должно инвалидировать несколько производных ключей — карточку, список, агрегат, счётчик, — и забытый среди них ключ неделями живёт со старыми данными. Плюс события теряются: сеть, рестарт, ошибка в ветке кода.

3. Версионирование ключей вместо удаления

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

• Версия схемы в префиксе: user:v3:42. Поменяли формат структуры или добавили поле — подняли v3 на v4, и весь старый кэш стал недостижим сам собой, без единого DEL и без KEYS. Старые ключи умрут по TTL. При деплое без этого не обойтись: иначе новый код десериализует старый JSON и получит нули в новых полях.
• Версия сущности: держим user:42:ver = счётчик, а данные — в user:42:v{N}. На запись делаем атомарный INCR user:42:ver за O(1), и все производные ключи этой сущности сразу становятся недостижимыми, даже если их сотня. На чтение нужно два обращения: имя ключа данных зависит от ответа на GET версии, и пайплайном их не склеить. В одно обращение укладывается только Lua. Так удобно закрывать «список постов пользователя», «агрегаты», «рендер страницы».

// Версия сущности: одна атомарная команда сбрасывает сколько угодно
// производных ключей.
func (r *Repo) userView(ctx context.Context, id int64) (View, error) {
    ver, err := r.rdb.Get(ctx, verKey(id)).Int64()
    switch {
    case errors.Is(err, redis.Nil):
        ver = 0 // версии ещё нет, это нормально
    case err != nil:
        return r.loadView(ctx, id) // Redis не ответил: мимо кэша, а не в v0
    }
    key := fmt.Sprintf("uview:%d:v%d", id, ver)
    // ... обычный cache-aside по key ...
}

func (r *Repo) invalidateUser(ctx context.Context, id int64) error {
    // Ни DEL, ни SCAN: старые ключи просто становятся недостижимы и уходят по TTL.
    return r.rdb.Incr(ctx, verKey(id)).Err()
}

Консистентность кэша и БД: порядок операций и гонки

Большинство валится на двух вопросах: что трогать первым (БД или кэш) и что делать с ключом (удалять или перезаписывать). Ответ короткий: сначала БД, потом удалить ключ. Но и при таком порядке одна дырка остаётся.

Вариант «сначала кэш, потом БД» — сломан

Удаляем ключ, потом делаем UPDATE. Между этими двумя шагами есть окно, в которое влезает читатель: он видит промах, идёт в БД, читает там ещё старое значение и кладёт его в кэш. Наш UPDATE отрабатывает позже, а устаревшее остаётся в кэше навсегда (до TTL). Окно тут широкое: оно длится весь запрос к БД, десятки миллисекунд. А если UPDATE упадёт, валидный кэш мы выбросили зря.

Вариант «сначала БД, потом удалить» — правильный, но не идеальный

Сначала фиксируем истину, потом сбрасываем копию. Окно, в котором кэш отдаёт старое, сжимается до промежутка между коммитом и DEL, а это доли миллисекунды. Но одна гонка остаётся, и именно её просят разобрать на доске.

Почему удалять ключ, а не перезаписывать его новым значением

Соблазн понятен: раз мы уже знаем новое значение, положим его в кэш сразу — и промаха не будет. Три причины так не делать.

1. Гонка двух писателей. Порядок применения в БД и порядок записи в кэш не совпадают, потому что это две независимые операции по сети. В итоге в кэше остаётся значение проигравшего.
2. Кэшируем то, что не читают. Когда пишут больше, чем читают, мы забиваем память значениями, которые могут не понадобиться ни разу.
3. Значение в кэше часто не равно строке в БД. Там лежит агрегат, join, отрендеренный кусок, и писатель просто не знает, что именно туда положить. Удаление корректно всегда.

Delayed double delete и его ограничения

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

func (r *Repo) Update(ctx context.Context, id int64, v Value) error {
    if err := r.db.Update(ctx, id, v); err != nil {
        return err
    }
    key := keyOf(id)
    _ = r.rdb.Del(ctx, key).Err()          // 1. немедленно

    // 2. Второе удаление через задержку снесёт значение, которое медленный
    //    читатель успел положить уже после первого DEL.
    //    Задержку берут больше p99 времени чтения из БД, обычно 300-800 мс.
    r.delayed.After(500*time.Millisecond, func(bg context.Context) {
        _ = r.rdb.Del(bg, key).Err()
    })
    return nil
}

Приём работает — но только вероятностно, гарантии он не даёт. На собесе стоит назвать все четыре ограничения:

• Задержку невозможно выбрать корректно. Она должна быть больше самого медленного чтения из БД, а хвост распределения не ограничен: GC-пауза, ретрай, залипшая реплика. Ставим больше — дольше держим лишний промах и грузим БД.
• Второе удаление само может не выполниться. Под упал, Redis моргнул, таймер жил в памяти процесса — и всё. Для надёжности нужна очередь или отдельный планировщик, то есть новая инфраструктура ради заплатки на гонку.
• Не спасает от репликации БД. Если читатель ходит на реплику, старое значение он может прочитать и через секунду после коммита. Тогда задержку надо брать больше лага репликации, а он не ограничен.
• Второй DEL бьёт по свежему значению. Между первым и вторым удалением ключ мог быть корректно заполнен уже новыми данными — а мы его выбросим и получим лишний промах на горячем ключе. На пике это ощутимо.

Cache penetration и кэширование отрицательных ответов

Три похожих слова, которые постоянно путают. Разведём их сразу — на собесе это ценят.

Отрицательное кэширование

Ответ БД «такой сущности нет» тоже результат, и его надо запомнить. Кладём маркер-заглушку с коротким TTL: 10–60 секунд вместо обычных пяти минут.

const missMarker = "__miss__" // маркер отрицательного результата

func (r *Repo) Get(ctx context.Context, id int64) (User, error) {
    key := keyOf(id)
    b, err := r.rdb.Get(ctx, key).Bytes()
    switch {
    case err == nil && string(b) == missMarker:
        return User{}, ErrNotFound          // попадание в "отрицательный" кэш
    case err == nil:
        return decode(b)
    }

    u, err := r.db.LoadUser(ctx, id)
    if errors.Is(err, sql.ErrNoRows) {
        // Короткий TTL: если сущность появится, мы отдадим 404 максимум 30 секунд.
        _ = r.rdb.Set(ctx, key, missMarker, 30*time.Second).Err()
        return User{}, ErrNotFound
    }
    if err != nil {
        return User{}, err                  // ошибку БД не кэшируем никогда
    }
    ...
}

Когда ключей слишком много и заглушками их не закрыть (например, поиск по произвольным строкам), перед кэшем ставят Bloom-фильтр, компактную битовую структуру, которая отвечает «точно нет» или «возможно есть». На «точно нет» отказываем сразу, не трогая ни кэш, ни БД. Ложноположительные срабатывания просто пропускают запрос дальше, и это безопасно. Правда, фильтр надо строить и поддерживать, а удалить из классического Bloom ничего нельзя (нужен counting или периодическая перестройка). В Redis 8 Bloom-фильтр встроен (BF.ADD, BF.EXISTS), в старых версиях это модуль RedisBloom либо своя реализация на SETBIT.

b, err := r.rdb.Get(ctx, key).Bytes()
switch {
case err == nil:
    return decode(b)
case errors.Is(err, redis.Nil):
    // промах, идём в БД
case err != nil:
    // ошибка кэша тоже ведёт в БД, а не наверх
    r.metrics.CacheErrors.Inc()
    slog.Warn("cache down, falling back to db", "err", err)
}
return r.loadFromDB(ctx, id)   // единственный источник правды

// Инкремент в Redis и запись id в set "грязных" ключей.
pipe := rdb.TxPipeline()
pipe.HIncrBy(ctx, "views", postID, 1)
pipe.SAdd(ctx, "views:dirty", postID)
_, err := pipe.Exec(ctx)

// Флашер раз в 10 секунд: забрать грязные id, прочитать значения, записать в БД.
// SPOP/HGETDEL атомарно "вынимает" накопленное, чтобы не потерять инкременты,
// пришедшие во время флаша.

func (r *Repo) Update(ctx context.Context, u User) error {
    tx, err := r.db.BeginTx(ctx, nil)
    if err != nil { return err }
    defer tx.Rollback()

    if err := updateUserTx(ctx, tx, u); err != nil { return err }
    if err := tx.Commit(); err != nil { return err }   // только после успешного коммита

    // Инвалидация вне транзакции. Ошибку не возвращаем наверх: данные уже записаны,
    // операция успешна. Логируем и полагаемся на TTL.
    if err := r.rdb.Del(ctx, keyOf(u.ID)).Err(); err != nil {
        slog.Warn("cache invalidation failed", "key", keyOf(u.ID), "err", err)
        r.metrics.InvalidateErrors.Inc()
    }
    return nil
}

// Ключи собираются из версии сущности:
//   v = GET product:7:ver          -> "12"
//   ключи: p:7:v12:card, p:7:v12:list:top, p:7:v12:reviews:page1
//
// Всё, что зависит от товара 7, инвалидирует одна команда:
func (r *Repo) BumpProduct(ctx context.Context, id int64) error {
    return r.rdb.Incr(ctx, fmt.Sprintf("product:%d:ver", id)).Err()
}

7.5Cache stampede, горячие и большие ключи

Три способа уронить систему кэшем, а не спасти её. Stampede превращает истечение одного ключа в залп запросов к БД. Горячий ключ загоняет весь трафик в один поток одной ноды. Большой ключ останавливает однопоточный Redis целиком — иногда прямо в момент удаления. Эти три вопроса любят задавать подряд, и проверяют они одно: понимаешь ли ты, что у Redis один поток и одна очередь команд.

Что такое cache stampede (dog-pile)

Ключ, который читают 5000 раз в секунду, истёк. Пока первый запрос идёт в БД, сотни горутин одновременно получают nil, одновременно решают «надо сходить в БД» и одновременно выполняют один и тот же SELECT. На БД обрушивается залп одинаковых запросов, её латентность растёт, из-за этого запросы идут дольше, а залп за это время успевает вырасти ещё. Классическая положительная обратная связь: в конце пул соединений исчерпан, а отказы идут каскадом. Причём падает БД, та самая, которую кэш должен был защищать.

Чем популярнее ключ, тем сильнее удар. Редко читаемый ключ при истечении даст один-два лишних запроса, ключ с главной страницы даст тысячу. Выходит, stampede бьёт ровно туда, где кэш приносил больше всего пользы.

Когда случается

• Истечение популярного ключа: базовый сценарий, он же cache breakdown.
• Холодный старт. Подняли новый под или новый инстанс Redis, восстановились после аварии, а кэш пуст, и весь трафик идёт в БД. Промахиваются уже все ключи сразу (avalanche).
• Деплой со сменой префикса версии. На бумаге операция «безопасная», а на деле она мгновенно сбрасывает весь кэш.
• Синхронное истечение. Прогрели кэш скриптом с одинаковым TTL — и ровно через N минут всё истекает в одну секунду. Самый обидный вариант: его создают своими руками.
• Failover Redis. Реплика стала мастером с отставанием или пустой — эффект тот же, что при холодном старте.
• Массовое вытеснение, когда память упёрлась в maxmemory и политика начинает выбрасывать ключи пачками.

Приёмов защиты дальше будет пять. Диаграмма ниже сразу показывает главный из них — singleflight, который «схлопывает» одновременные одинаковые запросы в один. Как он устроен, разберём в следующем разделе.

Решения: пять приёмов от простого к сложному

1. Блокировка на перестроение

Первый, кто получил промах, берёт блокировку и идёт в БД; остальные либо ждут её, либо сразу отдают устаревшее/деградированное значение. Внутри одного процесса хватает sync.Mutex на ключ, между процессами нужна распределённая блокировка на Redis (SET lock:key NX PX, подробности в главе 7.7).

Приём рабочий, но цену стоит назвать сразу. Блокировка на весь кластер добавляет round-trip к Redis на каждый промах, может залипнуть, если держатель упал (лечится TTL), и оставляет вопрос, что делают остальные, пока лидер работает: ждут (и упираются в его латентность и таймауты) или получают ошибку. На практике внутрипроцессный singleflight даёт 95 % пользы за 5 % сложности: при 20 подах залп из 200 запросов схлопывается до 20, а такого БД уже не замечает.

2. Singleflight — стандартный ответ для Go

Singleflight (дословно «один полёт») отвечает за дедупликацию конкурентных вызовов: из N одновременных запросов одной и той же работы выполняется один, остальные подписываются на его результат. При stampede не хватает ровно этого. Скорость похода в БД тут ни при чём — беда в том, что туда ходят двести раз подряд за одним и тем же ответом. Пакет golang.org/x/sync/singleflight так и работает: первый вызов по ключу выполняет функцию, остальные с тем же ключом ждут и получают тот же самый результат.

Тут же напрашивается вопрос: почему не обойтись обычным мьютексом? Один общий sync.Mutex отпадает сразу: он выстроит в очередь запросы к разным ключам и превратит параллельный сервис в последовательный. Мьютекс на каждый ключ уже ближе к делу, но за ним тянутся три вещи, и из них состоит почти весь код singleflight.

• Мапу «ключ → мьютекс» кто-то должен чистить, иначе она растёт вместе с числом когда-либо запрошенных ключей. И выбросить запись можно не в любой момент: пока на мьютексе кто-то стоит, удалять его нельзя.
• Мьютекс ничего не возвращает. Каждый, кто дождался очереди, должен сам перепроверить кэш. Забыли перепроверку или значение в кэш не легло (Redis моргнул, запись упала), и все двести запросов всё равно уйдут в БД — только теперь по очереди, а для клиентов это даже хуже залпа. Singleflight раздаёт готовый ответ, забыть тут нечего.
• Ждать мьютекс с таймаутом или по контексту нельзя: Lock() не умеет отменяться. У singleflight для этого есть DoChan, он возвращает канал.

Если совсем коротко, singleflight устроен как «мьютекс на ключ плюс место, куда лидер кладёт ответ для всех ждущих», и в нём аккуратно решено, сколько живёт эта пара.

import "golang.org/x/sync/singleflight"

type Repo struct {
    rdb *redis.Client
    db  *sql.DB
    sf  singleflight.Group   // один на репозиторий, не создавать на каждый запрос
    metrics *repoMetrics     // счётчики Prometheus
}

func (r *Repo) GetUser(ctx context.Context, id int64) (User, error) {
    key := fmt.Sprintf("user:%d", id)

    // 1. Быстрый путь: при попадании в кэш singleflight не нужен.
    if b, err := r.rdb.Get(ctx, key).Bytes(); err == nil {
        return decodeUser(b)
    } else if !errors.Is(err, redis.Nil) {
        slog.Warn("cache get failed", "err", err) // ошибка кэша == промах
    }

    // 2. Медленный путь: только один поход в БД на ключ.
    v, err, shared := r.sf.Do(key, func() (any, error) {
        // Внутрь не передаём ctx конкретного запроса, см. ловушки ниже.
        cctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
        defer cancel()

        u, err := r.loadUserFromDB(cctx, id)
        if err != nil {
            return nil, err
        }
        b, _ := encodeUser(u)
        ttl := 5*time.Minute + time.Duration(rand.Int63n(int64(60*time.Second))) // jitter
        if err := r.rdb.Set(cctx, key, b, ttl).Err(); err != nil {
            slog.Warn("cache set failed", "err", err) // не роняем запрос из-за кэша
        }
        return u, nil
    })
    if shared {
        r.metrics.SingleflightShared.Inc() // по этой метрике видно силу stampede
    }
    if err != nil {
        return User{}, err
    }
    return v.(User), nil
}

Как singleflight устроен внутри

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

type call struct {
    wg  sync.WaitGroup   // на нём ждут все дубликаты
    val any              // результат лидера
    err error
    dups int             // сколько вызовов схлопнулось (отсюда shared)
}

type Group struct {
    mu sync.Mutex        // защищает только мапу, не вызов fn
    m  map[string]*call
}

func (g *Group) Do(key string, fn func() (any, error)) (v any, err error, shared bool) {
    g.mu.Lock()
    if g.m == nil {
        g.m = make(map[string]*call)
    }
    if c, ok := g.m[key]; ok {      // полёт уже идёт, присоединяемся
        c.dups++
        g.mu.Unlock()
        c.wg.Wait()                 // ждём, пока лидер закончит
        return c.val, c.err, true
    }
    c := new(call)                  // мы лидер
    c.wg.Add(1)                     // поднимаем, пока держим мьютекс
    g.m[key] = c
    g.mu.Unlock()

    c.val, c.err = fn()             // тяжёлая работа вне мьютекса

    g.mu.Lock()
    delete(g.m, key)                // ключ убираем после вызова
    g.mu.Unlock()
    c.wg.Done()                     // будим всех ждущих

    return c.val, c.err, c.dups > 0
}

Три момента, которые стоит проговорить вслух:

• Мьютекс защищает только мапу, а не выполнение fn. Иначе конструкция сериализовала бы запросы к разным ключам и стала бы хуже, чем ничего.
• wg.Add(1) вызывается до g.mu.Unlock(). Если поднять счётчик после, присоединившийся дубликат может позвать Wait() на нулевом WaitGroup и пройти сквозь него, прочитав пустой c.val.
• Ключ удаляется из мапы после вызова. Значит, singleflight не кэширует: как только лидер завершился, следующий вызов снова пойдёт в БД. Это дедупликатор конкурентных вызовов, и за слой кэша его часто принимают по ошибке.

Настоящий код в x/sync сверх этого обрабатывает панику (её оборачивают в panicError и пробрасывают всем ждущим, чтобы они не зависли навсегда), корректно обрабатывает runtime.Goexit и держит список каналов chans для DoChan.

DoChan и Forget

Do блокирует, и в этом его главная проблема: ждущая горутина не может бросить ожидание по своему контексту. DoChan возвращает канал, а его уже можно слушать в select вместе с ctx.Done():

ch := r.sf.DoChan(key, func() (any, error) { return r.loadUserFromDB(bgCtx, id) })
select {
case res := <-ch:
    if res.Err != nil {
        return User{}, res.Err
    }
    return res.Val.(User), nil
case <-ctx.Done():
    // Наш HTTP-запрос отменили. Лидер доработает в фоне, и остальные
    // ждущие получат результат без второго похода в БД.
    return User{}, ctx.Err()
}

Forget(key) досрочно убирает ключ из мапы: следующий вызов не присоединится к текущему полёту, а начнёт свой. Нужен он в двух случаях: лидер завис, и ты не хочешь, чтобы новые запросы унаследовали его зависание, или результат лидера заведомо устарел (например, пока он работал, пришла инвалидация). Обычно из этого делают «одноразовый» singleflight:

v, err, _ := g.Do(key, func() (any, error) {
    // Отпускаем ключ через 100 мс после старта: те, кто пришёл позже,
    // начнут свой полёт, а не будут ждать зависшего лидера.
    t := time.AfterFunc(100*time.Millisecond, func() { g.Forget(key) })
    defer t.Stop() // иначе таймер отпустит уже следующий полёт
    return load(key)
})

Об одном ограничении спрашивают почти всегда: singleflight работает внутри одного процесса. При 20 подах 200 запросов схлопнутся до 20, а не до одного. Обычно этого хватает. Если нет, сверху добавляют распределённую блокировку или берут приёмы 3 и 5, которые вообще не дают ключу истечь.

3. Вероятностное раннее обновление (XFetch)

После singleflight одно остаётся нерешённым: кто-то всё равно ждёт. Лидер честно стоит свои 40 мс в БД, и все, кто к нему присоединился, стоят те же 40 мс. На горячем ключе это значит, что раз в TTL сотня пользователей получает ответ в сотню раз медленнее обычного: залпа в БД уже нет, а провал в p99 есть. И чем дороже пересчёт, тем провал глубже. XFetch убирает как раз его.

Идея в том, чтобы не ждать истечения, а обновлять значение заранее и вероятностно. Пока ключ ещё жив, каждый читатель сам бросает монетку: обновить кэш прямо сейчас или отдать то, что есть. Чем ближе истечение и чем дороже обошёлся прошлый пересчёт, тем чаще монетка выпадает в пользу обновления. В итоге обновляет кто-то один и заранее, а остальные по-прежнему получают попадание. Момент, когда ключа нет, просто не наступает — залп невозможен по построению, и сдерживать его не нужно.

Приём описан в работе Vattani, Chierichetti, Lowenstein «Optimal Probabilistic Cache Stampede Prevention» (VLDB 2015). Вместе со значением хранят delta — сколько заняло его вычисление — и абсолютный момент истечения expiry. Обновление запускают, если

now - delta * beta * ln(rand())  >=  expiry

где rand() ~ U(0,1],  ln(rand()) ≤ 0,  beta > 0 (обычно 1)

Читается так: -ln(rand()) даёт экспоненциальную случайную величину со средним 1. Её умножают на стоимость пересчёта, и чем дороже был пересчёт, тем раньше и охотнее начинается обновление. beta крутит агрессивность: при значении больше единицы обновляемся раньше и чаще (меньше промахов, больше фоновой нагрузки), при меньшем — позже.

type entry struct {
    Value  []byte
    Delta  time.Duration // сколько занял пересчёт в прошлый раз
    Expiry time.Time     // абсолютный момент истечения
}

// beta = 1.0 по умолчанию
func shouldRefreshEarly(e entry, beta float64) bool {
    // -math.Log(u) для u из (0,1] распределён экспоненциально
    u := rand.Float64()
    if u == 0 {
        u = math.SmallestNonzeroFloat64
    }
    gap := time.Duration(float64(e.Delta) * beta * -math.Log(u))
    return time.Now().Add(gap).After(e.Expiry)
}

func (r *Repo) Get(ctx context.Context, id int64) (User, error) {
    e, ok := r.readEntry(ctx, id)
    if ok && !shouldRefreshEarly(e, 1.0) {
        return decodeUser(e.Value)          // обычное попадание
    }
    if ok {
        // Значение ещё живое: обновляем в фоне и отвечаем сразу, латентность не страдает.
        go r.refresh(context.WithoutCancel(ctx), id)
        return decodeUser(e.Value)
    }
    return r.loadAndStore(ctx, id)          // настоящий промах
}

4. Jitter в TTL

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

// По умолчанию хватает ±20 %
func jitter(base time.Duration) time.Duration {
    spread := int64(base / 5)                   // 20 %
    return base + time.Duration(rand.Int63n(2*spread)-spread)
}

_ = rdb.Set(ctx, key, val, jitter(5*time.Minute)).Err()

Jitter не решает проблему одного горячего ключа. Он лечит массовое синхронное истечение (avalanche). Эти вещи часто путают, а они разные: против breakdown нужен singleflight, против avalanche — jitter. Отвечать надо обоими.

5. «Вечный» ключ с фоновым обновлением

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

• Логический TTL внутри значения. В Redis ключ живёт без TTL (или с огромным), а внутри значения лежит поле fresh_until. Если читатель видит, что логический срок вышел, он отдаёт устаревшее значение сразу и запускает фоновое обновление под singleflight. БД не ждёт никто и никогда: промахов по этому ключу просто нет. Цена в том, что читатели какое-то время сознательно получают устаревшие данные (это тот самый паттерн stale-while-revalidate из HTTP).
• Внешний прогреватель. Отдельный воркер или cron обновляет список известных горячих ключей по расписанию. Это просто и предсказуемо, но заранее надо знать, что горячее, а БД получает постоянную фоновую нагрузку, в том числе от ключей, которые уже никто не читает.

Сравнение подходов

Горячие ключи

Горячим (hot key) называют ключ, на который приходится непропорционально большая доля обращений: баннер на главной, товар из рассылки, конфиг фичефлагов, счётчик лайков у поста блогера-миллионника. На одиночном Redis это просто нагрузка, а в кластере уже архитектурная проблема.

Чем плох в кластере

Redis Cluster не держит карту «ключ → нода» (ключей миллионы), а вводит промежуточный уровень: фиксированные 16384 корзины, они называются хеш-слотами (hash slots). Номер слота считается прямо из имени ключа по формуле slot = CRC16(key) mod 16384, а «какой слот на какой ноде» хранит уже маленькая табличка, которую раздают всем клиентам. (Со «слотами» хеш-таблицы, о которых шла речь в SCAN, они никак не связаны, слово просто совпало.) В итоге ключ детерминированно попадает в один слот, слот живёт на одной ноде, а нода обрабатывает команды одним потоком. Значит:

• Масштабирование не работает. Добавили нод — трафик по горячему ключу не размазался ни на процент: как шёл в один поток, так и идёт.
• Перекос загрузки. Одна нода на 100 % CPU, остальные на 5 %. По средним метрикам кластер «недогружен», хотя на деле он в отказе. Классическая ловушка мониторинга: смотреть надо p99 по каждой ноде отдельно, а не среднее по кластеру.
• Сеть. Значение в 20 КБ при 50 000 запросах в секунду даёт гигабайт в секунду с одного сетевого интерфейса. В NIC упереться проще, чем в CPU.
• Взрывной эффект при потере. Если горячий ключ истёк или вытеснен, получаешь тот самый stampede, только в максимальном масштабе.

Как размазывать

1. Локальный кэш поверх Redis — первое и лучшее. Держим значение в памяти процесса 1–3 секунды. При 20 подах и TTL в секунду до Redis доходит 20 запросов в секунду вместо 50 000, то есть в тысячи раз меньше. Платишь окном рассинхрона длиной с локальный TTL, но для баннера или фичефлага это допустимо ровно всегда. Взять можно ristretto, otter, hashicorp/golang-lru или просто мапу под RWMutex с полем времени.
2. Чтение с реплик. В Redis Cluster клиент может читать со слейвов (READONLY, в go-redis это RouteRandomly / ReadOnly: true). Нагрузка на чтение делится на число реплик слота. Реплика асинхронна, так что можно прочитать чуть устаревшее значение, но для горячего кэша это обычно не проблема.
3. Реплики ключа с суффиксом. Пишем N копий (banner:main#0 … banner:main#15), читаем случайную. Разные суффиксы дают разные слоты и разные ноды. Это работает всегда, но платить придётся памятью (×N) и инвалидацией: удалять надо все N копий, пайплайном по нодам: Lua-скрипт в кластере работает только с ключами одного слота. И осторожно: если сделать наоборот и загнать копии в один слот через hash tag, приём теряет смысл целиком.
4. Client-side caching Redis 6+ (CLIENT TRACKING, RESP3): сервер сам присылает инвалидацию по ключам, которые клиент читал. По сути это локальный кэш с автоматической инвалидацией — самый аккуратный вариант, если клиент и версия сервера позволяют.

Как найти горячий ключ

• redis-cli --hotkeys работает только при maxmemory-policy семейства LFU: он опирается на счётчик обращений в объекте.
• redis-cli monitor показывает все команды в реальном времени. Мощно и опасно: сильно грузит сервер, так что включают его на секунды и только под нагрузкой, а оставлять нельзя.
• OBJECT FREQ key при LFU отдаёт счётчик частоты конкретного ключа.
• Лучше всего работают метрики на стороне приложения: считай обращения по префиксу ключа прямо в репозитории. От Redis ничего не требуется, всё видно в Grafana, и работает это постоянно.

Большие ключи (big keys)

Большим называют ключ со строкой в мегабайты или с коллекцией (hash, list, set, zset) на сотни тысяч элементов. Опасен он из-за однопоточности: пока идёт любая операция над большим ключом, сервер больше никого не обслуживает.

Чем именно плохи

• Блокировка на чтении. HGETALL по хешу из миллиона полей или LRANGE 0 -1 стоят O(N) в одном потоке, а потом сервер ещё собирает ответ на десятки мегабайт. Остальные клиенты всё это время ждут: head-of-line blocking на весь инстанс.
• Блокировка на удалении. Самое неочевидное. DEL большой коллекции освобождает память поэлементно, и это тоже O(N) в главном потоке. Ключ, который «просто удалили», может остановить сервер на сотни миллисекунд. Истечение TTL у большого ключа делает то же самое, причём удаление случится само и в самый неудобный момент.
• Сеть и латентность. Значение в 10 МБ при 100 rps даёт гигабайт в секунду. А на стороне Go такой ответ означает большой буфер в куче, работу GC и рост p99 у всего сервиса.
• Проблемы в кластере. При классическом решардинге ключи переезжают по одному и атомарно, поэтому большой ключ на время переноса блокирует и источник, и приёмник (с Redis 8.4 слот можно перенести целиком, командой CLUSTER MIGRATION). Ребалансировка кластера с большими ключами превращается в серию микро-аварий.
• Перекос памяти и вытеснение. С ключом на гигабайт шард на 4 ГБ упрётся в maxmemory раньше остальных и начнёт вытеснять чужие полезные данные.
• Персистентность. Большой ключ раздувает RDB-снимок и AOF-перезапись, а копирование при записи (copy-on-write) во время BGSAVE может удвоить потребление памяти.

Как искать

# 1. Обзорный проход: SCAN изнутри, безопасно для прода, но всё же I/O.
#    Показывает самый большой ключ каждого типа. Учти: у коллекций --bigkeys
#    считает число элементов, а не байты (у строк — байты).
redis-cli --bigkeys

# 2. Оценка в байтах (Redis 5+). Точнее, но дороже: считает реальный размер.
redis-cli --memkeys

# 3. Точный размер одного ключа со всеми накладными расходами структуры.
redis-cli MEMORY USAGE user:42:feed
redis-cli MEMORY USAGE user:42:feed SAMPLES 0   # 0 = не сэмплировать, точно

# 4. Число элементов, не вытягивая значение: O(1) для всех типов.
redis-cli STRLEN key ; redis-cli HLEN key ; redis-cli LLEN key
redis-cli SCARD  key ; redis-cli ZCARD key ; redis-cli XLEN key

# 5. Свой обход: SCAN курсором + MEMORY USAGE. Даёт полную картину,
#    не блокирует сервер, можно гонять по расписанию из джобы.
redis-cli --scan --pattern 'user:*' | head -100000

# 6. Оффлайн-анализ дампа: никакой нагрузки на прод вообще.
rdb --command memory dump.rdb --bytes 10240   # redis-rdb-tools, дампы до Redis 6.x

Что делать

1. Удалять через UNLINK, а не DEL. UNLINK мгновенно отцепляет ключ от пространства имён, а память освобождает фоновый поток (lazy free). Для больших коллекций это разница между «сервер встал на 300 мс» и «не заметили». Заодно включают lazyfree-lazy-expire yes, lazyfree-lazy-eviction yes и lazyfree-lazy-server-del yes, чтобы то же самое происходило при истечении TTL и при вытеснении.
2. Не читать целиком. Вместо HGETALL бери HMGET нужных полей или HSCAN порциями, вместо LRANGE 0 -1 листай постранично через LRANGE start stop, а вместо SMEMBERS используй SSCAN или SISMEMBER, если нужен только факт наличия.
3. Разбивать на части (шардировать ключ). Хеш из миллиона полей превращают в 100 хешей по 10 000: obj:{42}:part:0 … obj:{42}:part:99, номер части считают как hash(field) mod 100. Фигурные скобки здесь задают hash tag: он держит все части в одном слоте, если над ними нужны мультиключевые операции. Если же цель в том, чтобы размазать нагрузку, hash tag не ставят.
4. Ограничивать рост на входе. Список обрезают: LPUSH + LTRIM key 0 999 одной транзакцией. Stream ограничивают через XADD ... MAXLEN ~ 10000. Sorted set периодически чистят ZREMRANGEBYRANK. Это дешевле, чем потом чинить разросшийся ключ.
5. Пересмотреть модель. Большой ключ часто выдаёт, что в Redis положили то, что должно лежать в БД или в объектном хранилище: полный фид пользователя, вложение, сериализованный отчёт. В кэше держат идентификаторы и небольшие горячие срезы, а не всё целиком.

type call struct {
    wg   sync.WaitGroup
    val  any
    err  error
    dups int          // сколько вызовов схлопнулось
}

type Group struct {
    mu sync.Mutex     // защищает только мапу
    m  map[string]*call
}

func (g *Group) Do(key string, fn func() (any, error)) (any, error, bool) {
    g.mu.Lock()
    if g.m == nil { g.m = make(map[string]*call) }
    if c, ok := g.m[key]; ok {   // полёт уже идёт
        c.dups++
        g.mu.Unlock()
        c.wg.Wait()              // ждём лидера
        return c.val, c.err, true
    }
    c := new(call)               // мы лидер
    c.wg.Add(1)                  // пока мьютекс ещё взят
    g.m[key] = c
    g.mu.Unlock()

    c.val, c.err = fn()          // работа вне мьютекса

    g.mu.Lock()
    delete(g.m, key)             // ключ снимаем после вызова
    g.mu.Unlock()
    c.wg.Done()                  // будим всех

    return c.val, c.err, c.dups > 0
}

ch := g.DoChan(key, func() (any, error) {
    ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
    defer cancel()
    return load(ctx, key)
})

select {
case res := <-ch:
    if res.Err != nil { return zero, res.Err }
    return res.Val.(User), nil
case <-ctx.Done():
    // клиент ушёл; лидер доработает, результат достанется остальным
    return zero, ctx.Err()
}

v, err, _ := g.Do(key, func() (any, error) {
    t := time.AfterFunc(100*time.Millisecond, func() { g.Forget(key) })
    defer t.Stop() // лидер уже вернулся — чужой полёт не трогаем
    return load(key)
})

обновляем, если:   now - delta * beta * ln(rand())  >=  expiry

delta   — сколько занял прошлый пересчёт значения
expiry  — абсолютный момент истечения ключа
rand()  — равномерное из (0,1], значит ln(rand()) ≤ 0
beta    — агрессивность, обычно 1.0

type entry struct {
    Value  []byte
    Delta  time.Duration
    Expiry time.Time
}

func shouldRefreshEarly(e entry, beta float64) bool {
    u := rand.Float64()
    if u == 0 { u = math.SmallestNonzeroFloat64 }
    gap := time.Duration(float64(e.Delta) * beta * -math.Log(u))
    return time.Now().Add(gap).After(e.Expiry)
}

// В обработчике: если сработало и значение ещё живое, обновляем в фоне,
// а клиенту сразу отдаём то, что есть.
if ok && shouldRefreshEarly(e, 1.0) {
    go r.refresh(context.WithoutCancel(ctx), id)
}
return decode(e.Value)

// Рабочий диапазон: ±20 %
func jitter(base time.Duration) time.Duration {
    spread := int64(base / 5)
    return base + time.Duration(rand.Int63n(2*spread)-spread)
}

_ = rdb.Set(ctx, key, val, jitter(5*time.Minute)).Err()

redis-cli --bigkeys      # обход SCAN-ом; у коллекций элементы, не байты
redis-cli --memkeys      # оценка в байтах (Redis 5+), дороже
redis-cli MEMORY USAGE key SAMPLES 0     # точный размер одного ключа
redis-cli STRLEN/HLEN/LLEN/SCARD/ZCARD key   # число элементов, O(1)
redis-cli --scan --pattern 'user:*'      # курсорный обход, не блокирует
rdb --command memory dump.rdb --bytes 10240  # оффлайн по дампу (до Redis 6.x), без нагрузки

7.6Вытеснение, персистентность, отказоустойчивость

У трёх тем один общий вывод: Redis не даёт строгих гарантий. Он может выбросить твой ключ, при падении потерять последнюю секунду записей, а при failover даже подтверждённую запись. Это не баги, а заявленное поведение. Кандидату уровня middle мало знать названия политик: он должен уметь сказать, что именно теряется в каждом сценарии и как приложению к этому подготовиться.

maxmemory и политики вытеснения

maxmemory задаёт верхнюю границу памяти под данные. Что делать, когда она достигнута, решает maxmemory-policy. Её восемь классических вариантов делятся на три семейства (с Redis 8.6 добавились ещё allkeys-lrm и volatile-lrm, они вытесняют по давности последней записи): ничего не выбрасывать, выбрасывать из всех ключей (allkeys-*) или только из тех, у кого выставлен TTL (volatile-*).

LRU против LFU

LRU выбрасывает то, к чему дольше всего не обращались, а LFU то, к чему обращались реже всего. Разница видна на конкретном профиле нагрузки: LRU ломается на «сканирующем» трафике, когда поток разовых обращений вытесняет устойчиво горячие ключи.

Как Redis приближает LRU

Настоящий LRU требует двусвязного списка всех ключей: при каждом обращении элемент переносится в голову. Это два указателя на объект (16 байт на ключ только под учёт) плюс работа на каждом GET. Для базы на десятки миллионов ключей такое неприемлемо, поэтому Redis реализует не LRU, а его аппроксимацию.

• В заголовке каждого объекта есть 24-битное поле lru с «часами»: временем последнего обращения с грубым разрешением. Никакого списка, никаких указателей.
• Когда нужно вытеснять, Redis берёт случайную выборку из maxmemory-samples ключей (по умолчанию 5) и выбрасывает лучшего кандидата в ней.
• С Redis 3.0 есть ещё пул кандидатов на 16 элементов: лучшие жертвы из разных выборок копятся между вызовами, и при той же цене результат заметно ближе к идеальному LRU.
• maxmemory-samples 10 даёт результат, практически неотличимый от точного LRU, но ест больше CPU; 3 работает быстрее и грубее.

LFU устроен похоже, только в тех же 24 битах вместо часов лежат 8-битный логарифмический счётчик и 16 бит времени последнего затухания. Инкремент вероятностный: чем больше счётчик, тем реже он растёт (этим управляет lfu-log-factor), поэтому 8 бит хватает на диапазон до миллионов обращений. Со временем счётчик затухает — lfu-decay-time задаёт, за сколько минут простоя он уменьшается на единицу. Без затухания LFU был бы фатально консервативным: вчерашний хит вечно вытеснял бы сегодняшний.

Персистентность: RDB и AOF

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

RDB (Redis Database) делает снимок: всё содержимое памяти целиком сбрасывается в один компактный бинарный файл, как фотография состояния на конкретный момент. AOF (Append Only File, «файл только для дописывания») ведёт журнал: каждая изменяющая команда дописывается в конец файла, а при восстановлении журнал проигрывается с начала. Вся дальнейшая разница между ними вытекает из этих двух слов, «снимок» и «журнал».

appendfsync — где именно теряются данные

Запись в AOF мгновенно попадает в буфер ядра, а на диск данные уходят только при fsync. Как часто он вызывается, определяет appendfsync, и она же задаёт размер окна потери.

Гибридный режим

С Redis 4.0 есть aof-use-rdb-preamble yes (в современных версиях включён по умолчанию): при перезаписи AOF в начало файла кладётся RDB-снимок, а за ним дописываются команды, пришедшие позже. От RDB берутся компактность и быстрый старт, от AOF минимальная потеря. Поэтому на «что выбрать» правильно отвечать так: оба, в гибридном режиме.

Есть ещё AOF rewrite. Журнал растёт бесконечно (миллион INCR даёт миллион строк), поэтому Redis периодически перезаписывает его в компактную форму, отражающую текущее состояние. Rewrite идёт через fork(), с тем же copy-on-write и тем же риском скачка памяти, что и BGSAVE. Настраивают его через auto-aof-rewrite-percentage и auto-aof-rewrite-min-size.

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

Репликация — асинхронная

Мастер принимает записи и потоком отправляет их репликам, причём асинхронно: клиенту он отвечает OK, не дожидаясь подтверждения от реплик. Отсюда прямое следствие, которое и хотят услышать: подтверждённая запись может быть потеряна, если мастер упадёт до того, как реплика её получит, а failover поднимет эту реплику.

• Начальная синхронизация: BGSAVE на мастере, передача RDB, затем поток команд. После разрыва, если реплика отстала не слишком сильно, хватает частичной ресинхронизации по буферу repl-backlog.
• Реплики по умолчанию доступны только на чтение (replica-read-only yes). Данные на них отстают на величину лага, так что read-your-writes не гарантирован.
• Команда WAIT numreplicas timeout блокирует до подтверждения записи N репликами. Это не синхронная репликация и не транзакционная гарантия: она не откатывает запись при неуспехе, а лишь сообщает, сколько реплик подтвердили. Полезна как «барьер» перед критичным действием, но строгой durability не даёт.
• Настройки min-replicas-to-write / min-replicas-max-lag заставляют мастера отказывать в записи, если у него меньше N живых реплик. Так доступность меняют на меньший риск потери, то есть сдвигаются в сторону CP.

Sentinel — автоматический failover

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

1. Мониторинг. Каждый sentinel пингует мастера и, если тот молчит дольше down-after-milliseconds, помечает его субъективно недоступным (SDOWN).
2. Кворум. Кворумом называют минимальное число голосов, при котором решение считается принятым от имени всего кластера. Он нужен, чтобы один потерявший сеть наблюдатель не мог единолично объявить мастера мёртвым. Sentinel опрашивает остальных, и если о недоступности заявили не меньше quorum из них, статус повышается до объективно недоступного (ODOWN).
3. Выборы лидера. Sentinel-ы выбирают среди себя лидера (вариант Raft), который проведёт failover. Для выборов нужно большинство sentinel-ов — и это важнее кворума: при трёх sentinel-ах нужны два живых.
4. Промоушен. Лидер выбирает лучшую реплику (по приоритету, объёму полученных данных, run id), делает ей REPLICAOF NO ONE, перенастраивает остальные реплики на неё и обновляет конфигурацию.
5. Уведомление клиентов. Клиенты спрашивают у Sentinel адрес текущего мастера, а команды шлют уже ему напрямую. В go-redis для этого есть NewFailoverClient.

Redis Cluster и 16384 слота

Sentinel даёт отказоустойчивость, но не горизонтальное масштабирование: весь датасет всё равно лежит на одном мастере. Cluster шардирует данные между несколькими мастерами, у каждого из которых свои реплики.

• Пространство ключей разбито на 16384 слота. Слот ключа считается как CRC16(key) mod 16384. Каждый мастер владеет диапазоном слотов.
• Почему 16384, а не 65536: карта слотов входит в каждое сообщение протокола gossip как битовая маска. 16384 бита занимают 2 КБ на сообщение, а 65536 заняли бы уже 8 КБ. При типичном размере кластера в десятки нод такой размер избыточен, а 16384 хватает с запасом.
• Клиент сам знает карту слотов и ходит сразу на нужную ноду. Прокси нет: шардинг клиентский, и протокол его поддерживает.

Ограничения кластера

• Мультиключевые операции только внутри слота. MGET, MSET, SUNION, ZUNIONSTORE, транзакции и Lua-скрипты требуют, чтобы все ключи хешировались в один слот, иначе CROSSSLOT. Клиенты вроде go-redis умеют разбивать MGET на несколько запросов по нодам, но атомарности при этом нет.
• Hash tag режет в обе стороны. {userID} в ключе сводит все данные пользователя в один слот и делает возможными транзакции и Lua. Но если тег выбран неудачно (например, {tenant} у крупного клиента), весь его объём и трафик приземляются на одну ноду, то есть ты своими руками создал горячий слот.
• Нет баз данных. В кластере доступна только db 0, SELECT не работает.
• Pub/sub. Классический pub/sub в кластере рассылается по всем нодам (что дорого); с Redis 7 есть шардированный pub/sub SPUBLISH/SSUBSCRIBE, привязанный к слоту канала.
• Failover внутри кластера обходится без Sentinel: реплики сами инициируют выборы, решение принимает большинство мастеров. Если мастер потерял свои слоты и реплики нет, кластер по умолчанию (cluster-require-full-coverage yes) перестаёт обслуживать все запросы, а не только этот диапазон.

Почему Redis не даёт строгих гарантий

Сведём всё вместе: ради этого вывода и задают вопросы по всей секции.

1. Данные могут исчезнуть по политике вытеснения. При allkeys-* Redis имеет полное право выбросить любой твой ключ до истечения TTL. Значит, приложение обязано корректно работать без ключа в любой момент.
2. Данные могут потеряться при падении. При everysec пропадёт до секунды записей, без AOF всё с последнего снимка.
3. Подтверждённая запись может потеряться при failover. Репликация асинхронная; окно между ответом клиенту и доставкой реплике не защищено ничем.
4. Возможен split brain. Старый мастер в изолированном сегменте продолжает принимать записи, которые потом будут отброшены.
5. Транзакции не такие, как в БД. MULTI/EXEC даёт атомарность выполнения и изоляцию (команды идут подряд без чужих между ними), но не даёт отката: если одна команда упала на этапе выполнения, остальные всё равно выполнятся.

> MGET user:42:profile user:43:profile
(error) CROSSSLOT Keys in request don't hash to the same slot

# Без тега слоты разные:
user:42:profile   -> CRC16("user:42:profile") mod 16384
user:42:orders    -> CRC16("user:42:orders")  mod 16384

# С тегом CRC16 берётся только от того, что внутри первых фигурных скобок:
user:{42}:profile -> CRC16("42") mod 16384
user:{42}:orders  -> CRC16("42") mod 16384      # тот же слот
> MGET user:{42}:profile user:{42}:orders       # работает
> EVAL "..." 2 user:{42}:profile user:{42}:orders   # тоже работает

7.7Распределённые блокировки и Redis из Go

Здесь неправильный ответ стоит дороже всего. Распределённую блокировку на Redis напишет почти каждый, а понимают, что она не даёт корректности, и могут объяснить почему — единицы. Вторая половина главы прикладная: go-redis, пул, таймауты, пайплайнинг, Lua и redis.Nil. Если позиция подразумевает реальный код, спросят как раз это.

Блокировка на Redis: SET NX PX

Хватает одной команды:

SET lock:job:42 <уникальное-значение> NX PX 10000

• NX — установить, только если ключа нет. Это и есть атомарный захват: команда либо создаёт ключ и возвращает OK, либо возвращает nil. Однопоточный сервер выполняет проверку и установку как одну операцию, так что гонке между ними взяться неоткуда.
• PX 10000 — TTL в миллисекундах.
• В значение кладут случайный UUID держателя.

Зачем TTL

Без TTL блокировка упавшего держателя остаётся навсегда. Процесс убили OOM-killer-ом, под выселили, машина отключилась — defer unlock() не выполнится, потому что выполнять его некому. Ключ висит, работа стоит, чинят руками в три часа ночи. Освободить блокировку без участия упавшего процесса умеет только TTL. Из него же растёт главная проблема таких блокировок, о ней ниже.

Зачем уникальное значение

Чтобы снять свою блокировку, а не чужую. Сценарий: A взял блокировку с TTL 10 секунд, работа затянулась на 12; на десятой секунде ключ истёк, B тут же его взял; на двенадцатой A заканчивает и делает DEL lock:job:42, то есть удаляет блокировку B. Дальше блокировку берёт C, и теперь B и C работают параллельно. Забыл одну деталь, и взаимного исключения больше нет. С уникальным значением блокировку можно снимать с проверкой: «удали, только если там всё ещё моё значение».

Освобождение через Lua

«Проверить и удалить» состоит из двух операций, и между ними ключ может истечь. Классическая гонка check-then-act: GET вернул моё значение, в этот момент TTL истёк, B захватил блокировку, и мой DEL сносит уже его ключ. Атомарность даёт Lua-скрипт: Redis выполняет его целиком, не вклинивая чужие команды.

-- unlock.lua: удалить ключ, только если значение совпадает
if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
else
    return 0
end

var unlockScript = redis.NewScript(`
if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
else
    return 0
end`)

type Lock struct {
    rdb   *redis.Client
    key   string
    value string        // уникальный идентификатор владения
}

func Acquire(ctx context.Context, rdb *redis.Client, key string, ttl time.Duration) (*Lock, error) {
    val := uuid.NewString()
    ok, err := rdb.SetNX(ctx, key, val, ttl).Result()   // SET key val NX PX ttl
    if err != nil {
        return nil, err
    }
    if !ok {
        return nil, ErrLockBusy                          // занято кем-то другим
    }
    return &Lock{rdb: rdb, key: key, value: val}, nil
}

func (l *Lock) Release(ctx context.Context) error {
    // NewScript.Run сначала пробует EVALSHA, а при NOSCRIPT переходит на EVAL.
    n, err := unlockScript.Run(ctx, l.rdb, []string{l.key}, l.value).Int64()
    if err != nil {
        return err
    }
    if n == 0 {
        // Ключа нет или он уже не наш: TTL истёк, пока мы работали.
        // Это не безобидно: значит, кто-то мог работать параллельно с нами.
        return ErrLockLost
    }
    return nil
}

Главная проблема: TTL истёк, а работа идёт

Блокировка с TTL держится ровно TTL — и ни микросекундой больше. А задержать держателя дольше могут пауза GC (в Go редко, но stop-the-world есть), вытеснение потока планировщиком ОС, залипший сетевой вызов, «замороженный» контейнер, миграция виртуальной машины или просто медленный запрос в БД. В любой из этих ситуаций два клиента одновременно считают себя держателями блокировки, и оба уверены, что имеют право писать.

Watchdog — продление TTL

Обычно делают так: пока работа идёт, фоновая горутина периодически продлевает TTL (в Redisson это называется watchdog, отсюда термин). Продлевают тем же скриптом с проверкой значения — иначе продлишь чужую блокировку.

var extendScript = redis.NewScript(`
if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("PEXPIRE", KEYS[1], ARGV[2])
else
    return 0
end`)

// Запускается сразу после захвата, останавливается через cancel при Release.
func (l *Lock) keepAlive(ctx context.Context, ttl time.Duration) {
    t := time.NewTicker(ttl / 3)      // продлеваем втрое чаще, чем истекает
    defer t.Stop()
    for {
        select {
        case <-ctx.Done():
            return
        case <-t.C:
            ok, err := extendScript.Run(ctx, l.rdb, []string{l.key}, l.value,
                ttl.Milliseconds()).Int64()
            if err != nil || ok == 0 {
                // Блокировку потеряли, значит работу надо прервать, а не продолжать:
                // параллельно с нами уже может идти другой держатель.
                l.lost()          // закрывает канал, по которому работа отменяется
                return
            }
        }
    }
}

Fencing token

Идея из статьи Клеппмана. При каждом захвате блокировки выдаётся монотонно растущее число (в Redis это INCR lock:{job:42}:fence: в Cluster фигурные скобки сводят лок и счётчик в один слот, иначе скрипт захвата упадёт с CROSSSLOT). Клиент передаёт этот токен в каждый запрос к защищаемому ресурсу, а ресурс помнит самый большой токен, какой видел, и отвергает всё, что меньше. Тогда «воскресший» старый держатель с токеном 33 физически не сможет испортить работу нового с токеном 34. Оговорка: счётчик в Redis монотонен, пока Redis не теряет записи. После failover с асинхронной репликацией он может откатиться назад, поэтому для строгих гарантий токен берут из хранилища с консенсусом или из той же БД, что защищает ресурс.

-- захват с выдачей токена, одним скриптом
if redis.call("SET", KEYS[1], ARGV[1], "NX", "PX", ARGV[2]) then
    return redis.call("INCR", KEYS[2])   -- монотонный счётчик поколений
else
    return 0
end

Redlock и критика Клеппмана

Алгоритм Redlock Сальваторе Санфилиппо (автор Redis) предложил для блокировки поверх N независимых мастеров Redis (обычно 5), не связанных репликацией. Клиент:

1. берёт текущее время и последовательно пытается захватить ключ на всех N инстансах с малым таймаутом на каждый;
2. считает блокировку взятой, если получил её на большинстве (N/2+1) и суммарно потратил меньше TTL;
3. владеет ею TTL минус потраченное время минус поправка на дрейф часов;
4. при неуспехе снимает блокировку со всех инстансов, где успел взять.

Смысл: пережить падение отдельных инстансов без Sentinel и без потери блокировки при failover.

Критика Мартина Клеппмана (2016)

Разбор «How to do distributed locking» и ответ Санфилиппо давно стали классикой, их стоит знать по пунктам.

1. Разделение целей. Клеппман начинает с вопроса, зачем вообще нужна блокировка: для эффективности (не делать одну работу дважды) или для корректности (двойное выполнение недопустимо). Для эффективности сгодится и одиночный Redis. Для корректности Redlock не подходит, и дальше Клеппман объясняет почему.
2. Опора на часы. Redlock считает истечение по времени, предполагая ограниченный дрейф часов. Но время может скакнуть: NTP-коррекция, живая миграция ВМ, переустановка часов администратором. Время на одном узле прыгнуло вперёд, и блокировка «истекает» раньше, чем думает держатель. Если корректность системы зависит от синхронности часов, в асинхронной модели она небезопасна.
3. Паузы процесса. Даже с идеальными часами держателя может остановить STW-пауза, своп, вытеснение планировщиком или заморозка контейнера. После паузы он не знает, что блокировку потерял, — и продолжает работать. Никакой алгоритм захвата это не ловит.
4. Fencing token как единственное лекарство. Отсюда вывод: нужен монотонный токен, проверяемый ресурсом. Redlock не выдаёт такого токена: у него N независимых инстансов, и получить из них согласованно возрастающее число нельзя. А системы с настоящим консенсусом (ZooKeeper с zxid, etcd с revision, Consul) его выдают.
5. Ответ Санфилиппо. Он возразил, что предположения о часах ограничены и практичны, а про паузы сказал, что fencing token нужен любой блокировке, включая ZooKeeper, так что это не претензия именно к Redlock. Обе стороны частично правы; консенсуса в сообществе нет.

Pub/Sub, Streams и полноценный брокер

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

Что именно теряется в pub/sub

• Нет персистентности. PUBLISH доставляет только тем, кто подписан прямо сейчас. Подписчик отвалился на две секунды, пока переподключался, и сообщений за эти две секунды он не увидит и никогда не узнает об этом.
• Нет подтверждений. PUBLISH возвращает число подписчиков, которым сообщение отправлено, а не число обработавших. Обработал ли кто-то, отправитель не узнает.
• Медленный подписчик отбрасывается. Если он не успевает вычитывать, у него растёт output buffer, и когда тот упрётся в client-output-buffer-limit pubsub, Redis рвёт соединение. Для приложения это происходит тихо.
• В кластере рассылается по всем нодам — это дорого. С Redis 7 есть шардированный SPUBLISH/SSUBSCRIBE, привязанный к слоту канала.

Отсюда единственно корректное применение pub/sub: сигналы-ускорители, потеря которых безопасна. Сюда хорошо ложится инвалидация локальных кэшей: если сигнал не дошёл, ключ всё равно протухнет по TTL через секунду. А бизнес-события («заказ оплачен») на pub/sub гарантированно потеряются, причём тихо и в первый же деплой.

Когда Streams достаточно

• Умеренный объём, который помещается в память с запасом, и есть MAXLEN.
• Retention нужен часами, а не неделями: перечитать вчерашний день не потребуется.
• Redis уже есть в инфраструктуре, и заводить Kafka ради одной очереди задач избыточно.
• Нужны подтверждения и повторная выдача зависших сообщений — PEL и XAUTOCLAIM это дают.

Когда нужен настоящий брокер

• Retention днями и неделями, replay. В Redis лог живёт в памяти — терабайт истории там никто держать не станет.
• Много независимых потребителей одного потока. В Kafka это естественно: каждая consumer group читает свой offset по одному и тому же логу.
• Строгие требования к durability. Kafka пишет на диск и реплицирует с acks=all; Redis теряет до секунды при everysec и подтверждённые записи при failover.
• Экосистема: Kafka Connect, Streams/Flink, схемы (Avro/Protobuf + registry), compaction, транзакции. Ничего этого в Redis нет.
• Сложная маршрутизация уже по части RabbitMQ: exchange, routing key, TTL очередей, DLQ из коробки.

Redis из Go: go-redis

github.com/redis/go-redis/v9 стал стандартом де-факто (второй вариант, rueidis, быстрее за счёт автопайплайнинга по умолчанию, но встречается реже; RESP3 go-redis v9 включает и сам). Клиент потокобезопасен, держит внутри пул соединений и создаётся один на приложение.

rdb := redis.NewClient(&redis.Options{
    Addr:     "redis:6379",
    Password: os.Getenv("REDIS_PASSWORD"),
    DB:       0,

    // --- пул соединений ---
    PoolSize:        50,               // максимум сокетов; по умолчанию 10 * GOMAXPROCS
    MinIdleConns:    10,               // держать прогретыми, чтобы не платить за dial в пике
    MaxIdleConns:    20,
    ConnMaxIdleTime: 30 * time.Minute, // закрывать простаивающие
    ConnMaxLifetime: 0,                // 0 = не пересоздавать по возрасту
    PoolTimeout:     4 * time.Second,  // сколько ждать свободное соединение из пула

    // --- таймауты ---
    DialTimeout:  2 * time.Second,
    ReadTimeout:  500 * time.Millisecond,   // Redis быстрый: секунды тут не нужны
    WriteTimeout: 500 * time.Millisecond,

    // --- ретраи ---
    MaxRetries:      3,
    MinRetryBackoff: 8 * time.Millisecond,
    MaxRetryBackoff: 512 * time.Millisecond,
})

Про пул — то, что спрашивают

• Одна команда занимает одно соединение на время round-trip. Значит, нужный размер пула ≈ пиковая конкурентность обращений к Redis, а не число ядер. При латентности 0,3 мс одно соединение выдаёт ~3000 команд в секунду — 50 соединений закрывают 150 000 rps.
• Исчерпание пула даёт не отказ, а ожидание: горутина ждёт свободное соединение до PoolTimeout, потом получает redis: connection pool timeout. Это главный симптом: либо пул мал, либо Redis отвечает медленно (большие ключи, медленные команды). Поэтому метрики rdb.PoolStats() (Timeouts, TotalConns, IdleConns) надо снимать в Prometheus.
• Блокирующие команды съедают соединение целиком. BLPOP, XREAD BLOCK, подписка pub/sub держат сокет всё время ожидания. Их нельзя гонять через общий пул в большом количестве: заведи для них отдельный клиент или хотя бы помни, что N воркеров навсегда съедят N соединений.
• MaxRetries и идемпотентность. Ретраи включены по умолчанию. Для GET это безопасно, для INCR уже нет: команда могла выполниться, а ответ потеряться, и повтор посчитает второй раз. Для неидемпотентных операций либо MaxRetries: -1 (выключить), либо операция, устойчивая к повтору.

Контекст и таймауты

Каждая команда принимает ctx, но по умолчанию go-redis v9 его дедлайн на сокет не переносит (ContextTimeoutEnabled: false): контекст учитывается, пока ждёшь соединение из пула и между ретраями, а ответ ждут по ReadTimeout. С ContextTimeoutEnabled: true дедлайн контекста становится дедлайном чтения; оборванное посреди ответа соединение go-redis закрывает, так что массовые таймауты выглядят как шторм переподключений. И в любом случае уже отправленная команда в Redis выполнится. На практике ставят короткий ReadTimeout (порядка сотен миллисекунд) и не рассчитывают, что отмена «остановит работу в Redis».

redis.Nil — не ошибка, а результат

val, err := rdb.Get(ctx, key).Result()
switch {
case errors.Is(err, redis.Nil):
    // Ключа нет. Это штатная ветка, а не сбой: промах кэша.
    return loadFromDB(ctx, key)
case err != nil:
    // Настоящая ошибка: сеть, таймаут, пул. Тоже обычно ведёт в БД,
    // но с метрикой и логом, иначе не заметишь, что Redis лежит.
    metrics.CacheErrors.Inc()
    return loadFromDB(ctx, key)
default:
    return val, nil
}

Отдельно: redis.Nil прилетает не только из GET. Пустой результат BLPOP по таймауту, ZSCORE несуществующего элемента, HGET отсутствующего поля — всё это redis.Nil. А вот Exists и SetNX возвращают ноль/false без ошибки, и на этом тоже часто путаются.

Пайплайнинг

Пайплайн отправляет N команд одним пакетом и читает N ответов, экономя N−1 round-trip. Это самый дешёвый способ ускорить работу с Redis: при RTT 0,3 мс сто последовательных GET займут 30 мс, а пайплайном — 0,4 мс.

// Pipeline не атомарен: просто пакет команд, между ними могут выполниться чужие.
pipe := rdb.Pipeline()
cmds := make([]*redis.StringCmd, 0, len(ids))
for _, id := range ids {
    cmds = append(cmds, pipe.Get(ctx, keyOf(id)))
}
_, err := pipe.Exec(ctx)
// Exec возвращает ошибку, если упала хотя бы одна команда, включая redis.Nil.
// Результаты всё равно надо разбирать по каждой команде отдельно.
if err != nil && !errors.Is(err, redis.Nil) {
    return nil, err
}
for i, c := range cmds {
    v, err := c.Result()
    if errors.Is(err, redis.Nil) {
        continue                 // ключа нет: промах, не ошибка
    }
    ...
}

// TxPipeline: то же самое, но обёрнуто в MULTI ... EXEC.
// Все команды выполнятся подряд, без чужих между ними.
pipe := rdb.TxPipeline()
incr := pipe.Incr(ctx, "counter")
pipe.Expire(ctx, "counter", time.Hour)
_, err := pipe.Exec(ctx)          // MULTI, INCR, EXPIRE, EXEC одним round-trip
fmt.Println(incr.Val())           // 1 — счётчик после первого INCR
// До Exec поля команд пустые: incr.Val() вернул бы 0. Заполняются они
// в момент Exec, поэтому читать результат раньше — типичная ошибка.

Lua: EVAL, EVALSHA и redis.NewScript

Lua-скрипт выполняется на сервере атомарно: пока он работает, ни одна другая команда не выполнится. Только так в Redis получается настоящее «прочитать-проверить-записать». EVAL отправляет текст скрипта каждый раз, EVALSHA — только SHA1-хеш, экономя трафик. go-redis прячет оба за одним вызовом:

// Скрипт объявляется один раз как переменная пакета.
var rateLimit = redis.NewScript(`
local current = redis.call("INCR", KEYS[1])
if current == 1 then
    redis.call("PEXPIRE", KEYS[1], ARGV[1])
end
if current > tonumber(ARGV[2]) then
    return 0
end
return 1`)

// Run сначала пробует EVALSHA; если сервер ответил NOSCRIPT
// (перезапуск, SCRIPT FLUSH), сам переключается на EVAL и кеширует скрипт заново.
allowed, err := rateLimit.Run(ctx, rdb,
    []string{"rl:" + userID},                 // KEYS
    int64(time.Minute/time.Millisecond), 100, // ARGV: окно и лимит
).Int64()

if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
else
    return 0
end

var unlockScript = redis.NewScript(`
if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
else
    return 0
end`)

func (l *Lock) Release(ctx context.Context) error {
    n, err := unlockScript.Run(ctx, l.rdb, []string{l.key}, l.value).Int64()
    if err != nil {
        return err
    }
    if n == 0 {
        // Ключа уже нет или он не наш: TTL истёк, пока мы работали.
        // Это сигнал, что параллельно с нами кто-то мог работать.
        return ErrLockLost
    }
    return nil
}

var extendScript = redis.NewScript(`
if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("PEXPIRE", KEYS[1], ARGV[2])
else
    return 0
end`)

t := time.NewTicker(ttl / 3)            // продлеваем втрое чаще, чем истекает
for {
    select {
    case <-ctx.Done():
        return
    case <-t.C:
        ok, err := extendScript.Run(ctx, rdb, []string{key}, val, ttl.Milliseconds()).Int64()
        if err != nil || ok == 0 {
            l.lost()   // прервать работу, а не продолжать: рядом уже может идти другой
            return
        }
    }
}

-- захват с выдачей токена
if redis.call("SET", KEYS[1], ARGV[1], "NX", "PX", ARGV[2]) then
    return redis.call("INCR", KEYS[2])
else
    return 0
end

-- проверка на стороне ресурса, например в Postgres
UPDATE jobs SET result = $1, fence = $2 WHERE id = $3 AND fence <= $2;
-- 0 строк --> наш токен устарел, мы больше не держатель, результат отбрасываем

rdb := redis.NewClient(&redis.Options{
    Addr: "redis:6379",

    PoolSize:        50,               // дефолт: 10 * GOMAXPROCS
    MinIdleConns:    10,               // прогретые соединения, чтобы не платить за dial в пике
    ConnMaxIdleTime: 30 * time.Minute,
    ConnMaxLifetime: 0,                // 0 = не пересоздавать по возрасту
    PoolTimeout:     4 * time.Second,  // сколько ждать свободное соединение

    DialTimeout:  2 * time.Second,
    ReadTimeout:  500 * time.Millisecond,   // Redis быстрый, секунды тут не нужны
    WriteTimeout: 500 * time.Millisecond,

    MaxRetries:      3,
    MinRetryBackoff: 8 * time.Millisecond,
    MaxRetryBackoff: 512 * time.Millisecond,
})

pipe := rdb.Pipeline()
cmds := make([]*redis.StringCmd, 0, len(ids))
for _, id := range ids {
    cmds = append(cmds, pipe.Get(ctx, keyOf(id)))
}
_, err := pipe.Exec(ctx)
// Exec вернёт ошибку, если упала хотя бы одна команда, включая redis.Nil.
if err != nil && !errors.Is(err, redis.Nil) {
    return nil, err
}
for _, c := range cmds {
    v, err := c.Result()
    if errors.Is(err, redis.Nil) {
        continue          // просто нет ключа
    }
    ...
}

pipe := rdb.TxPipeline()          // MULTI ... EXEC
incr := pipe.Incr(ctx, "counter")
pipe.Expire(ctx, "counter", time.Hour)
_, err := pipe.Exec(ctx)
fmt.Println(incr.Val())           // 1 — счётчик после первого INCR
                                  // (до Exec было бы 0: результаты приезжают в Exec)

// Объявляется один раз, на уровне пакета.
var rateLimit = redis.NewScript(`
local current = redis.call("INCR", KEYS[1])
if current == 1 then
    redis.call("PEXPIRE", KEYS[1], ARGV[1])
end
if current > tonumber(ARGV[2]) then
    return 0
end
return 1`)

// Run: сначала EVALSHA, при NOSCRIPT сам вызывает EVAL и снова кеширует скрипт.
allowed, err := rateLimit.Run(ctx, rdb,
    []string{"rl:" + userID},                  // KEYS
    int64(time.Minute/time.Millisecond), 100,  // ARGV
).Int64()

val, err := rdb.Get(ctx, key).Result()
switch {
case errors.Is(err, redis.Nil):
    // Ключа нет: штатный промах.
    metrics.CacheMiss.Inc()
    return loadFromDB(ctx, key)
case err != nil:
    // Настоящая ошибка: сеть, таймаут, пул. Мы не знаем, есть ключ или нет.
    metrics.CacheErrors.Inc()
    slog.Warn("cache unavailable", "err", err)
    return loadFromDB(ctx, key)     // деградация, а не отказ
default:
    metrics.CacheHit.Inc()
    return val, nil
}