Что такое cache stampede и почему он делает всё хуже

Flash sale стартует в полдень. Главная страница закешировалась 30 секунд назад. В 12:00:30 TTL срабатывает — и 10 000 покупателей бьют в БД одновременно. Кеш должен был это предотвратить.

Форма сбоя

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

При низком трафике это не страшно — один запрос промахивается, перестраивает, сохраняет новое значение, следующий запрос попадает в кеш. При высоком трафике граница TTL уничтожается. Все N параллельных запросов попадают в промежуток между моментом истечения ключа и моментом, когда любой из них запишет новое значение. Каждый из них независимо запускает rebuild. БД — которую кеш прятал — теперь получает N параллельных запросов.

Общее число пользовательских запросов невелико — кеш поглощал их 60 с. Но пиковая параллельность на истечении равна полной нефильтрованной ставке трафика в эту одну секунду. БД была рассчитана на steady-state за кешем, а не на односекундный бёрст у потолка трафика.

Почему длинный TTL не помогает

Интуитивный фикс — «установить длинный TTL». Это не лечит stampede, только переносит его. TTL=1 час означает, что стадо приходит раз в час вместо раза в минуту. Каждый часовой stampede тяжелее, потому что больше cache-writes накапливается за одним истечением. Правильный фикс меняет то, что происходит на истечении, а не когда оно происходит.

Взрывная форма трафика — сама по себе проблема

Без кеша БД видит стабильные 5 000 RPS. С кешем и TTL=60 с БД видит почти 0 RPS 59 секунд, затем 5 000 RPS за одну секунду. Общая работа намного меньше — но пик идентичен работе без кеша. Кеш переформирует трафик из ровного в взрывной, и именно бёрст, а не объём, вызывает сбои.

Конкретный таймлайн

1. T=0 с — homepage:v1 закеширована с TTL=60 с. Трафик: 5 000 RPS.
2. T=0–59.9 с — cache hits. БД видит ~10 QPS (проверки здоровья).
3. T=60.0 с — ключ истекает.
4. T=60.0–60.4 с — 2 000 запросов приходят (5 000 RPS × 0.4 с = время rebuild). Каждый делает GET homepage:v1, получает nil, запускает 400-мс rebuild. 2 000 параллельных запросов к БД.
5. T=60.4 с — все 2 000 rebuild завершаются. Каждый пишет новое значение. CPU БД падает.
6. T=60.4–120.0 с — снова cache hits. Цикл повторяется в T=120.