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

Сравни стратегии cache-aside, read/write-through и write-behind по тому, кто читает и пишет источник истины. Разбери гонку между медленным чтением и инвалидацией и выбери способ ограничить устаревание с учётом допустимого окна.

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

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

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()
}

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

• В cache-aside приложение читает кэш, при промахе загружает источник и заполняет кэш.
• При update обычно сначала фиксируют БД, затем удаляют ключ; обратный порядок может вернуть старое значение в кэш.
• Двойное удаление после задержки закрывает часть гонки с медленным читателем, но требует обоснованного интервала и устойчивого планировщика.

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

• Не возвращай ошибку Redis после уже успешного commit БД так, будто сама запись не состоялась; иначе клиент может повторить операцию.
• Write-behind требует durable очереди/журнала, иначе сбой до flush теряет данные.
• Фоновое обновление с request context может отмениться вместе с клиентом; дай ему контролируемый срок жизни и owner.

v, _ := db.Load(ctx, id)       // slow reader
_ = db.Update(ctx, id, newer)  // writer commits
_ = rdb.Del(ctx, key).Err()    // invalidation
_ = rdb.Set(ctx, key, v, ttl).Err() // stale fill

b, err := rdb.Get(ctx, key).Bytes()
if err != nil {
    return loadFromDB(ctx, key) // every request fans out
}
return decode(b)