Метастабильный сбой, fencing-токены и production-постмортемы

Stampede длится 10 секунд. Через четыре часа БД всё ещё на 100% CPU. Stampede закончился — но система не может само-восстановиться. Это паттерн метастабильного сбоя: как только система падает в retry-шторм, она там и остаётся.

Последовательность метастабильного сбоя

Cache stampede может эскалировать в self-sustaining сбой:

1. T=0 — TTL срабатывает, стадо бьёт в БД. CPU БД насыщается.
2. T=0–5 с — запросы в очереди. Глубина очереди превышает client request timeout (например, 5 с).
3. T=5 с — начинаются client timeouts. Большинство client SDK авто-ретраят с exponential backoff. Backoff короткий (100 мс до 1 с), потому что исходный timeout выглядел как transient network failure, а не перегруженный сервер.
4. T=5–30 с — ретраи умножают стадо. Исходные 10 000 misses становятся 30 000 in-flight запросами (3 попытки на клиента). БД теперь обслуживает ретраи вместо свежих запросов. Rebuild кеша не может завершиться, потому что БД слишком занята ответами на rebuild-запросы.
5. T=4 ч — система остаётся насыщенной. Каждый новый приход ретраит. Ретраи предотвращают восстановление БД. БД предотвращает rebuild кеша. Пустой кеш генерирует больше ретраев. Self-sustaining loop.

Система имеет два стабильных состояния: healthy (кеш полный, низкая нагрузка БД) и storm (кеш пустой, БД на 100%). Возмущение переместило её из healthy в storm. Она не может вернуться сама.

Почему система не может само-восстановиться

Loop: нет кеша → ретраи → перегрузка БД → нет DB capacity → нет rebuild кеша → нет кеша. Каждый компонент корректно следует своему проектному поведению. Ни один компонент не «знает», что он в шторме. Client SDK ретраит, потому что видит таймауты. БД обрабатывает запросы по порядку. Кеш не rebuild-ится, потому что БД никогда не отвечает достаточно быстро.

Восстановление требует ломки loop извне:

1. Load-shedding на gateway — возвращать 503 Service Unavailable немедленно, когда CPU БД превышает 90%. Большинство client SDK трактуют 503 как «не ретраить немедленно» и отступают с длинным jitter. Через 30–60 с очередь дренируется, БД восстанавливается и кеш rebuild-ится.
2. Circuit-breaker на rebuild-пути — если rebuild-запрос падает или занимает слишком долго, отдавать stale forever до восстановления БД. Ломает зависимость между rebuild кеша и здоровьем БД.
3. Manual cache warmup — операторы напрямую пишут известные-хорошие значения в кеш, обходя rebuild-путь. Немедленно возвращает систему в healthy состояние.

Fencing-токен фикс для lock TTL race

Redis лок с SET lock:key uuid EX 30 NX имеет race condition когда rebuild переживает EX:

1. Запрос-1 захватывает лок с uuid-A, EX=10 с. Запускает 12-секундный rebuild.
2. T=10 с: лок авто-истекает. Запрос-2 захватывает лок с uuid-B.
3. T=12 с: запрос-1 завершает rebuild. Пишет в кеш.
4. T=12 с: запрос-2 тоже завершает rebuild. Пишет в кеш.
5. Результат: дублирование записей. Если есть параллельная инвалидация из DB-записи, stale значение запроса-1 может перезаписать более новое корректное значение.

Фикс 1: увеличить EX выше rebuild p99.9. Большинство дублей предотвращено. Не защищает от всех race.

Фикс 2: проверка fencing-токена перед записью.

# Перед записью rebuild-нутого значения:
current_lock = GET lock:key
if current_lock != my_uuid:
  ABORT  # мы потеряли лок; кто-то другой делает rebuild
ELSE:
  SET cache:key new_value EX 60  # писать только если ещё держим лок

Фикс 3: монотонная версия на ключ. Включать версию в каждую запись кеша. БД или кеш-слой отвергает записи с version ≤ текущей версии. Stale rebuilds пишут со старой версией и тихо отвергаются. Критика Мартина Клеппманна 2016 года RedLock формализовала это: distributed locks одних недостаточно для корректности; нужен fencing.

XFetch: почему экспонента оптимальна

Vattani et al. (VLDB 2015) доказывают, что ни один coordination-free алгоритм не может сделать лучше экспоненты для удержания ожидаемых refresh на TTL-окно ровно в 1. Любое более жёсткое правило либо:

• Требует координации (distributed lock, lease) для ограничения variance, либо
• Принимает большую variance (некоторые окна получают 0 refresh → stampede, некоторые много → потраченная работа).

Экспонента уникально оптимальна, потому что: минимум N независимых Exp(λ) выборок есть Exp(N·λ). С ростом размера флота N «выигрывающий» читатель срабатывает раньше — но ожидаемый total остаётся 1. Никакое другое распределение не имеет этого свойства масштабирования, оставаясь безмятежным (без состояния на читателя).

Четыре production-постмортема

Reddit 2017. Изменение feed-кеша задеплоено без single-flight. Результат: 3× DB пики на каждой TTL-границе. On-call пейджнули по CPU БД через 30 минут после деплоя; откатили за 1 час.

Shopify 2020 (Black Friday). Flash-sale главная с TTL=30 с без SWR. На 12:00:30 TTL сработал под 10× нормального трафика. Весь storefront edge имел multi-second outages на каждой TTL-границе первые 10 минут продажи. Починили деплоем stale-grace=5 мин на следующем пуше.

Twitter 2022. Unrelated баг инвалидации кеша триггерил 30М параллельных rebuild-попыток. DB connection pool насытился на 4 часа. Восстановление потребовало load-shedding + manual cache seed.

Cloudflare 2024. Баг coalescing в KV кеше кратко позволял N запросам на один ключ обходить coalescing в окне деплоя. Origin видел пропорциональную нагрузку в окне. Починили деплоем guard flag, отключившего rollout coalescing до патча.

Паттерн всех четырёх: stampede-защита либо отсутствовала, либо была мис-конфигурена, либо имела баг, побеждающий её под нагрузкой. Цена была пропорциональна gap-у защиты.

Дизайн full-stack композиции

Production кеш-стек для глобального высокотрафикового сайта нуждается в защите на каждом тире:

Каждый тир должен независимо ограничивать своё стадо — сбой на любом тире каскадирует на следующий. SWR на CDN поглощает 99% TTL-boundary трафика. XFetch предотвращает stampede следующего слоя, обновляясь до истечения. Single-flight схлопывает per-node стада. Redis lock схлопывает cross-node для 1% горячих ключей. TTL jitter десинхронизирует multi-key границы. Вместе они снижают 10 000 параллельных misses до 1 rebuild в любом месте стека.