Dogpile-эффект: коллизия параллелизма в момент истечения горячего ключа

Пейджер в 3 часа ночи. Запрос фида главной страницы — 200ms-агрегация, которая обычно выполняется пару раз в минуту — внезапно выполняется тысячи раз в секунду. База на 100% CPU, пул соединений исчерпан. Ничего не деплоили. Потом кто-то читает конфиг кэша: у ключа фида TTL в 5 минут, и в 02:55:00 он истёк. В этот миг в полёте было ~5000 запросов, каждый промахнулся по одному и тому же ключу, и все 5000 ушли в базу одновременно. Один истёкший ключ, 5000 одновременных одинаковых запросов.

Dogpile — это ракурс «параллелизм в момент истечения»

Есть более широкая тема — cache stampede / thundering herd — о том, как отсутствующий ключ заваливает origin. Dogpile-эффект — её самое острое и конкретное лицо: коллизия, которая происходит ровно в момент истечения на одном горячем ключе. Чем горячее ключ, тем хуже dogpile, потому что «горячий» значит, что много запросов одновременно в полёте, а истечение TTL — это событие, которое попадает по всем им в одну и ту же миллисекунду.

Пройди по таймлайну. Ключ закэширован и обслуживает тысячи чтений в секунду прямо из памяти — origin простаивает. Таймер TTL доходит до нуля. Запрос #1 читает кэш, получает промах и начинает пересчёт. Пока он ещё пересчитывает (это занимает 200ms), приходят запросы #2…#5000, каждый читает кэш, каждый тоже получает промах — потому что #1 ещё не записал новое значение — и каждый тоже начинает пересчёт. Промежуток между «первым промахом» и «значение перезаписано» — это и есть всё окно, в котором формируется dogpile. У наивного чтения cache-aside нет координации между этими параллельными промахами, поэтому origin за один тик переходит из простоя в N-параллельность.

Математика стоимости — это и есть вся проблема

Причина опасности dogpile мультипликативна, и цифры безжалостны. Возьми дорогую операцию — скажем, 200ms-агрегацию в базе. В установившемся режиме за тёплым кэшем она почти не выполняется. В момент истечения она выполняется один раз на каждый параллельный запрос. Один дорогой запрос × N параллельных запросов = расплавление origin.

Подставь реальный трафик. Формулировка из Wikipedia: страница, рендер которой занимает 3 секунды, при 10 запросах в секунду означает 30 процессов, пересчитывающих одновременно в момент истечения. Теперь масштабируй: 5000 запросов/сек по 200ms-запросу означает до 5000 одновременных соединений с базой, каждое держит запрос 200ms — далеко за пределами большинства лимитов пула (пул Postgres часто 20–100 соединений). Пул исчерпывается, здоровые несвязанные запросы встают в очередь за стадом, и промах кэша по одному ключу кладёт всю базу. Стоимость запроса в установившемся режиме никогда не была проблемой; проблема — множитель параллелизма в момент истечения.

Single-flight: свернуть N промахов в один пересчёт

Первый рефлекс — блокировка. На промахе первый запрос захватывает блокировку для этого ключа и пересчитывает; все остальные, кто промахнулся в окне, блокируются на ней и, когда она освобождается, читают свежезаписанное значение вместо пересчёта. golang.org/x/sync/singleflight в Go — каноничная реализация: вызови Do(key, fn), и если вызов для этого ключа уже в полёте, дополнительные вызывающие ждут и получают результат исходного вызова, а не выполняют fn заново. Сообщаемый эффект драматичен — Reddit срезал пиковую нагрузку на базу ~в 3 раза с request coalescing на эндпоинтах фида, а заваливание сервера 100 параллельными запросами по одному ключу может дедуплицировать ~95% избыточных дорогих прогонов, превращая множество ожиданий 3–5 с в один прогон 3–5 с, общий для всех вызывающих.

Оговорка сеньора: локальный mutex коалесцирует только внутри одного процесса. С 20 инстансами приложения за балансировщиком каждый инстанс запускает свой single-flight, поэтому origin всё равно видит до 20 параллельных пересчётов — лучше, чем 5000, но не один. Чтобы получить один пересчёт на весь флот, нужна распределённая блокировка (например, Redis SET key val NX PX 30000), которая покупает межпроцессную координацию ценой сетевого round-trip и новой зависимости от доступности хранилища блокировок.

XFetch: не давать горячему ключу истекать под нагрузкой

Блокировка чинит симптом после промаха; вероятностное раннее истечение (XFetch, из статьи VLDB 2015 «Optimal Probabilistic Cache Stampede Prevention» авторов Vattani, Chierichetti и Lowenstein) бьёт по причине — оно делает так, что ключ практически никогда не истекает, пока он горячий. Каждый читатель на попадании бросает кубик: он добровольно пересчитывает раньше с вероятностью, которая растёт по мере приближения истечения. Правило решения:

time() − delta * beta * log(rand(0,1)) ≥ expiry

где delta — сколько занял последний пересчёт, beta — ручка настройки (статья доказывает, что beta = 1 фактически оптимален), а log(rand(0,1)) берёт выборку из экспоненциального распределения. Изящество: более дорогое значение (большая delta) обновляется раньше и охотнее, и поскольку каждый читатель решает независимо, первый удачливый читатель пересчитывает в одиночку — задолго до того, как TTL дойдёт до нуля — и перезаписывает ключ, так что когда приходит стадо, значение свежее, и больше никто не промахивается. Коллизия растворена, потому что событие истечения больше не совпадает с пиком параллелизма.

Режимы отказа сеньора: лекарство, которое становится болезнью

Каждый фикс вносит собственную продакшн-опасность, и постмортемы по dogpile обычно про отказ фикса, а не исходного промаха.

Блокировка пересчёта может стать узким местом сериализации. Если пересчёт медленный, а ключ крайне горячий, теперь каждый читатель блокируется на одном держателе блокировки на всю длительность пересчёта — ты превратил шторм параллелизма в обрыв латентности, где p99 этого эндпоинта становится временем пересчёта для всех. Хуже — блокировка без таймаута: если единственный пересчётчик падает или зависает на середине, держа блокировку, каждый читатель блокируется навсегда — самонанесённый полный отказ, где база здорова и простаивает, но каждый запрос в deadlock-е, ожидая блокировку, которая никогда не освободится. Всегда ставь TTL блокировки (и делай его длиннее, чем худший случай пересчёта, иначе блокировка истечёт на середине пересчёта и ты снова откроешь dogpile). Джиттер TTL реален, но узок: он останавливает истечение пачки ключей, закэшированных вместе, в одну и ту же секунду, но ничего не делает для одного отдельного горячего ключа — у него по-прежнему ровно один момент истечения и собственное стадо, ждущее его. Тянуться к джиттеру, чтобы починить dogpile одного горячего ключа, — частая ошибка диагноза.