Что такое cache stampede — и почему кэш может уронить твою базу

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

59 минут всё идеально. На 60-й минуте ключ протухает. И в эту же секунду на главную заходят 300 человек.

Каждый из них видит: в кэше пусто. Каждый идёт в базу за тем же самым двухсекундным запросом. База получает 300 тяжёлых запросов одновременно и ложится. Сайт падает — и падает из-за кэша, который ты ставил, чтобы он не падал.

У этого есть имя: cache stampede, «паническое бегство стада».

Что такое cache stampede простыми словами

Cache stampede — ситуация, когда популярная запись в кэше пропадает, и много запросов одновременно бросаются пересчитывать одно и то же.

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

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

Почему это коварно

Пока трафик маленький, проблемы нет вообще. Ты не увидишь её локально и не поймаешь тестом. Она появляется ровно тогда, когда приложение стало популярным. То есть в самый неудачный момент.

И у неё есть усилитель. После перезапуска все ключи создаются почти одновременно. Если у всех срок жизни ровно 3600 секунд, то и протухнут они почти одновременно. Через час база получит не одну давку, а сразу все.

Эта механика может уронить и гиганта. В 2010 году Facebook лежал около двух с половиной часов. В хранилище записали значение настройки, которое система сочла ошибочным. Каждый сервер увидел «плохое» значение в кэше, выбросил его и пошёл за правильным в базу данных. Сотни тысяч запросов в секунду. Ошибки базы только подливали масла: на них клиенты снова сносили значение и снова шли за ним. Пришлось отключить сайт целиком, чтобы толпа разошлась.

Три способа не устроить давку

1. Пусть считает только один. Первый запрос ставит отметку «я пересчитываю» — блокировку в Redis или флажок в памяти. Остальные не идут в базу, а ждут пару сотен миллисекунд и снова смотрят в кэш. Внутри одного процесса Node это делается проще: храни не результат, а сам промис пересчёта. Все, кто пришёл, ждут один и тот же промис.

const inFlight = new Map()

async function getHome() {
  const cached = await cache.get("home")
  if (cached) return cached
  if (!inFlight.has("home")) {
    inFlight.set("home", buildHome().finally(() => inFlight.delete("home")))
  }
  return inFlight.get("home") // все 300 ждут один запрос к базе
}

2. Отдавай старое, пока готовится новое. Это называется stale-while-revalidate. Ключ «протух», но не удалён. Пользователь сразу получает вчерашнюю версию, а одно обновление идёт в фоне. Для главной страницы данные на минуту старше — не беда. Беда — когда она не открывается. Тот же приём умеют CDN и HTTP-заголовок Cache-Control: stale-while-revalidate=60.

3. Разброс сроков. Не ставь всем ключам ровно час. Ставь час плюс случайные 0–5 минут. Ключи, созданные вместе, протухнут вразнобой, и база получит ровный ручеёк вместо цунами. Есть и вариант хитрее — обновлять ключ чуть раньше срока с некоторой вероятностью. Он описан в статье 2015 года с прямым названием «Optimal Probabilistic Cache Stampede Prevention».

Как понять, что это твой случай

Посмотри на график нагрузки базы. Ровная линия с острыми пиками через равные промежутки — почти всегда давка. Особенно если период совпадает со сроком жизни кэша: час, пять минут, сутки. Если ИИ писал тебе кэширование, проверь его код на одну вещь. Что происходит, когда два запроса одновременно видят пустой кэш? Если ответ «оба идут в базу» — допиши один из трёх способов выше.

Cache stampede и thundering herd — это одно и то же?

Почти. Thundering herd («грохочущее стадо») — общее название: много участников разом бросаются на один ресурс. Cache stampede — его частный случай, когда толпу выпускает протухший ключ кэша.

Нужно ли это маленькому проекту?

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

Можно просто сделать кэш вечным?

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