Детектирование stampede и дизайн TTL для продакшена

Команда деплоит single-flight и локи. Три недели спустя срабатывает on-call алерт: CPU БД спайкует каждые 5 минут. Защита на месте — но она защищает не те ключи. Спайк идёт от другого ключа с TTL=300 с, который никто не инструментировал.

Observability-отпечаток

Cache stampede оставляет характерную сигнатуру в метриках:

• Ставка запросов к БД: пилообразный паттерн — почти нуль между TTL-границами, резкий спайк на каждой границе. Ширина спайка равна длительности rebuild.
• Периодичность: спайки повторяются с интервалами, совпадающими с TTL. TTL=60 с → спайки каждые 60 с. TTL=300 с → каждые 5 минут.
• p99 латентность: спайки на тех же интервалах, что и ставка запросов к БД.
• cache_miss_total rate: резкие периодические увеличения на границах вместо ровного низкого baseline.

Без этих метрик stampede выглядит как общая «медленная БД» без очевидной причины.

Минимально-жизнеспособный dashboard

Шесть метрик покрывают все stampede-сценарии:

Алерт 1: cache_miss_total rate выше 5× steady-state → stampede формируется. Алерт 2: db_query_rate p99 выше 10× p50 → пилообразная нагрузка БД → boundary-спайки. Алерт 3: cache_lock_wait_seconds p99 выше длительности rebuild → глубина очереди лока растёт.

TTL jitter

Single-flight и локи обрабатывают per-key stampede. Но что, если 1 000 ключей имеют TTL=300 с и все были закешированы одновременно? Все истекают вместе, производя 1 000 одновременных per-key stampede — single-flight корректно обрабатывает каждый, но сумма 1 000 параллельных rebuild — спайк БД.

TTL jitter: вместо фиксированного TTL использовать случайное значение в диапазоне:

ttl = base_ttl * (1 + jitter_fraction * (rand() - 0.5))
# Пример: base=300, jitter=0.25 → TTL в диапазоне [225, 375]

Флот из 1 000 ключей с ±25% jitter размазывает истечения на 150 с вместо одновременного срабатывания. Нагрузка БД становится плавной низкой кривой вместо спайка.

Большинство кеш-библиотек поддерживают jitter нативно (Caffeine в Java, Redis через application-level вычисление). Стандартный ±15–25% достаточен для большинства нагрузок.

Негативное кеширование

Та же stampede-форма применима, когда БД отвечает «нет такой строки». Если приложение не кеширует null-результаты, каждый запрос несуществующего ключа бьёт в БД — и под высокой параллельностью это miss-storm, перегружающий БД так же полно, как положительный stampede.

Фикс: кешировать sentinel “missing” с коротким TTL.

# При DB miss:
SET key:missing "" EX 10  # 10 с негативный TTL

# При чтении:
val = GET key
if val == "":
  return NOT_FOUND  # из кеша, без обращения к БД

Короткий негативный TTL (5–30 с) ограничивает расход памяти. Положительный TTL может быть намного длиннее (60–300 с). Write-through invalidation должна удалять негативную запись при INSERT реальной строки.

Замечание по безопасности: без негативного кеширования атакующий может чеканить случайные несуществующие ключи (случайные UUID в URL-пути) для амплификации нагрузки БД на порядки — задокументированный паттерн, поразивший CDN-сайты в 2024.

Pre-warming после перезапусков

Кеш, перезапущенный холодным (deploy, eviction, отказ машины), стартует пустым. Каждый входящий запрос промахивается и бьёт в БД — полный origin-спайк. При перезапуске на пиковом трафике этот спайк равен по величине полному stampede.

Процедура pre-warming:

1. До приёма публичного трафика проиграть топ-N наиболее accessed ключей из audit-лога или access-лога.
2. Прогреть кеш сначала, затем переключить трафик.
3. Для blue-green деплоев: прогреть green кеш-инстанс до steady-state перед переключением load balancer.

Edge-ноды Cloudflare pre-warm-ятся из соседних POP. Redis-backed сервисы используют startup-скрипт, читающий «топ 1 000 ключей» из audit-таблицы. Правило: никогда не перезапускать кеш под живым трафиком без pre-warming.