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

Что мы получаем

• Латентность: 0,3 мс из Redis вместо 10–40 мс из БД, а из локального кэша вообще сотни наносекунд.
• Пропускную способность: БД перестаёт быть узким местом, её можно не масштабировать.
• Защиту источника от пиков: всплеск трафика на популярный контент не доходит до БД.
• Деньги: реплика Postgres дороже, чем нода Redis той же ёмкости.

Чем платим

• Окно рассинхрона. Сколько-то секунд пользователи видят старые данные. Это надо явно согласовать с продуктом, а не решать в коде молча.
• Вторая копия правды. Инвалидация порождает баги, которые воспроизводятся раз в неделю у одного пользователя.
• Точка отказа. Если сервис не умеет работать при недоступном кэше, ты просто добавил в цепочку ещё один компонент, который может её порвать.
• Холодный старт и stampede. Пустой кэш после деплоя отправляет всю нагрузку в БД разом.
• Маскировка. Кэш прячет неоптимизированный запрос до того дня, когда промахнётся.

Сверху вниз

• Клиент / браузер. Управляется заголовками Cache-Control, ETag, Last-Modified. Кэш самый дешёвый: запрос вообще не уходит в сеть. И самый опасный: инвалидировать его нельзя, ты уже отдал ответ, поэтому для изменчивых данных ставят no-store или очень короткий max-age, а для статики «вечный» TTL плюс хеш в имени файла.
• CDN / edge. Тот же HTTP-кэш, но управляемый: есть API для purge. Хорош для статики и публичных GET-ответов, бесполезен для персонализированных.
• Обратный прокси (nginx proxy_cache, Varnish). Кэширует готовые HTTP-ответы внутри твоего периметра. Хорош тем, что не требует ни строчки в приложении.
• Приложение, in-process. Мапа или LRU внутри Go-процесса. Нет ни сети, ни сериализации. Но у каждой реплики своя копия.
• Распределённый кэш (Redis, Memcached). Хранит общее для всех подов состояние: сессии, результаты тяжёлых запросов, счётчики.
• Уровень БД. Буферный пул (shared_buffers, InnoDB buffer pool), кэш планов и prepared statements, материализованные представления. Кэшем это называют реже, но ведёт себя оно ровно так же.
• ОС и железо. Page cache файловой системы, кэш контроллера диска.

Локальный

Обращение к мапе занимает 50–500 наносекунд, и сериализации нет: в кэше лежит готовая Go-структура. Никакой сети, никакой отдельной точки отказа. Минусы: у каждого пода свой кэш и свой момент истечения, поэтому пользователь при обновлении страницы может увидеть то новое значение, то старое. Для инвалидации нужна рассылка на все поды (обычно через Redis pub/sub), и атомарной она не будет. Плюс объём ограничен heap-ом, а миллион живых объектов удлиняет цикл GC.

Распределённый

Копия одна, и один DEL инвалидирует её для всех; объём измеряется десятками гигабайт и не влияет на GC приложения. Платишь сетевым round-trip и сериализацией, которая часто дороже самой сети: json.Marshal большой структуры порой занимает больше времени, чем поход в Redis.

Как отвечать

«Локальный я беру для маленького, редко меняющегося и одинакового для всех: справочники, фичефлаги, конфиги, курсы валют. С TTL в единицы секунд, чтобы рассинхрон был заведомо незаметен. Redis нужен для всего, что должно быть согласовано между репликами, и для больших объёмов. Если нагрузка высокая, ставлю оба: L1 локальный на 1–5 секунд поверх L2 в Redis. L1 снимает с Redis горячий хвост и заодно решает проблему горячего ключа в кластере.»

Эффективная средняя латентность считается как L = L_hit + (1-h) * L_source, потому что промах стоит поход в кэш плюс поход в источник. При L_hit = 0,3 мс, L_source = 20 мс hit rate 90 % даёт 2,3 мс, а 99 % уже 0,5 мс. Последние девять процентов ускоряют ответ почти впятеро: промахов становится вдесятеро меньше.

Почему процент сам по себе бесполезен

• 99 % при 10 000 rps пропускают в БД 100 запросов в секунду, ерунда. 99 % при миллионе rps пропускают уже 10 000 rps, и БД ляжет. В алертах должно быть misses_per_second.
• Если источник отвечает за 0,3 мс, то и hit rate 50 % никого не беспокоит.
• Высокий hit rate бывает и у бесполезного кэша: если кэшируется только один горячий ключ, процент будет 99, а тяжёлые запросы всё равно уходят в БД.

Что ещё важно проговорить

Кэш почти не улучшает p99. Медиана падает до латентности кэша, а хвост остаётся равным латентности источника - туда как раз и уходят промахи. Если SLA сформулирован по p99, кэш с hit rate 95 % его практически не сдвинет, и надо либо чинить источник, либо доводить hit rate до 99,9 %, либо ставить refresh-ahead, чтобы промахов на пользовательском пути не было вообще.

Ориентиры из практики: для кэша объектов по идентификатору нормально 90–99 %; ниже 70 % уже повод проверить, есть ли вообще перекос в ключах; ниже 50 % кэш обычно только добавляет round-trip. Отдельно смотрят evicted_keys: если ключи вытесняются по maxmemory, а не по TTL, значит рабочее множество больше кэша и hit rate будет деградировать.

• Нет локальности. Аналитика по произвольным диапазонам, поиск по свободным фильтрам: каждый ключ уникален, hit rate около нуля, а лишний round-trip платят все.
• Источник быстрее или сопоставим. Чтение по первичному ключу из прогретого буферного пула занимает те же 0,3 мс, что и Redis по сети. Кэш добавит только сложность и рассинхрон.
• Данные критичны к свежести. Баланс перед списанием, остаток товара при оформлении, проверка прав и статуса блокировки. Здесь устаревшее значение означает не «чуть-чуть неточно», а списанные лишние деньги или доступ у уволенного сотрудника. Такие чтения идут в БД, при необходимости под SELECT ... FOR UPDATE.
• Запись сравнима с чтением по частоте. Ключ инвалидируется раньше, чем его успевают прочитать: платим и за БД, и за Redis.
• Кэш как замена оптимизации. Медленный запрос надо чинить планом и индексом. Кэш поверх него превращается в отложенный инцидент: рванёт он в момент, когда кэш окажется пуст, то есть при рестарте, деплое или всплеске новых ключей.
• Данные слишком большие. Мегабайтный JSON в Redis ради одного поля тратит сеть и блокирует однопоточный сервер (см. большие ключи в 7.5).

Penetration - «пробой»

Запрашивают ключ, которого нет в БД. Кэш промахивается, источник возвращает пусто, класть нечего, и каждый следующий такой запрос снова идёт в БД. Если кто-то перебирает идентификаторы, кэш просто перестаёт существовать как защита.

Лечение:

• Negative caching - кладём маркер «нет такого» с коротким TTL (30–60 с). TTL короткий, чтобы вновь созданная сущность быстро стала видна.
• Фильтр Блума перед кэшем для больших пространств ключей: даёт достоверное «точно нет» и вероятностное «может быть», при этом занимает биты на ключ.
• Проверка формата идентификатора на входе отсекает мусорный перебор без похода в БД.

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
    }
    ...
}

Breakdown - «прорыв» одного горячего ключа

У очень популярного ключа истёк TTL, и все запросы к нему одновременно ушли в БД. Это частный случай stampede, подробно он разобран в главе 7.5. Лечится singleflight, «вечным» ключом с фоновым обновлением или вероятностным ранним обновлением.

Avalanche - «лавина»

Протухло сразу много ключей (кэш прогрели одним циклом с одинаковым TTL) или упал сам Redis. В БД приходит вся нагрузка целиком. Лечение: jitter в TTL, чтобы истечения размазались во времени; circuit breaker и лимит одновременных запросов к БД; деградированный ответ вместо полного отказа.