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

Разбери, как истечение одного ключа может превратиться в stampede, а одна горячая команда или большой ключ - задержать весь Redis. Сопоставь singleflight, jitter, раннее обновление, разбиение данных и репликацию по их разным целям.

Что такое 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 обновляет список известных горячих ключей по расписанию. Это просто и предсказуемо, но заранее надо знать, что горячее, а БД получает постоянную фоновую нагрузку, в том числе от ключей, которые уже никто не читает.

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

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

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

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

В Redis Cluster ключ детерминированно попадает в один хеш-слот (slot = CRC16(key) mod 16384), слот живёт на одной ноде, а нода обрабатывает команды одним потоком. Значит:

• Масштабирование не работает. Добавили нод - трафик по горячему ключу не размазался ни на процент: как шёл в один поток, так и идёт.
• Перекос загрузки. Одна нода на 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-перезапись, а копирование при записи во время 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), без нагрузки

Что стоит запомнить

• singleflight схлопывает конкурентные загрузки одного ключа внутри одного процесса.
• Jitter размазывает сроки истечения разных ключей, а не объединяет запросы к одному ключу.
• Redis hot key и big key требуют разных решений: распределение чтений против уменьшения размера/работы одной команды.

Частые ошибки

• Локальный singleflight на каждой реплике не гарантирует один запрос к БД глобально.
• Не ставь одинаковый TTL на большой набор ключей: синхронное истечение создаёт волну промахов.
• Репликация горячего чтения не помогает командам-записям, которые требуют единого значения.

// Each of 3 pods has its own singleflight.Group.
result, err, _ := sf.Do(userKey, func() (any, error) {
    return db.LoadUser(ctx, userID)
})

func jitter(base time.Duration) time.Duration {
    spread := int64(base / 5)
    return base + time.Duration(rand.Int63n(spread))
}