Предыдущая статья: Часть 1: Как один термин в лекции зажег пламя расследования.

Часть 2: В поисках классических проявлений Dogpile Effect.

Мое "расследование" началось с самого очевидного — поиска информации по термину Dogpile. Прежде всего хотелось найти каноническое определение этого термина.

Интернет, как всегда, оказался щедр на статьи, особенно на платформе Medium, где многие инженеры делятся своим опытом. Изучая эти материалы, я начал понимать, что лектор использовал термин Dogpile Effect, наиболее распространенный в веб-разработке.

Дальнейшие поиски привели меня к синониму, который используется даже чаще — Cache Stampede (Лавина запросов к кешу). И это название сразу проливает свет на суть проблемы.

Классическое определение Dogpile Effect описывает специфический сценарий отказа в системах, которые активно используют кеширование для снижения нагрузки на основной источник данных (например, базу данных).

Классический пример с кешем.

Dogpile Effect (также известный как Cache Stampede) — это каскадный сбой, который происходит, когда множество одновременных (конкурентных) процессов или потоков, после истечения времени жизни кеша, пытаются получить доступ к одному и тому же ресурсу, который в данный момент недоступен или требует длительного времени на генерацию.

Представьте себе высоконагруженный сайт (например, новостной портал):

Дорогой ресурс. Представим, что у нас есть данные, которые дорого и долго генерировать из базы данных. Это может быть главная страница новостного сайта, которая генерируется из десятков источников, требует сложных запросов к БД.
Решение проблемы — кеш. Чтобы не нагружать БД при каждом запросе, мы кешируем эти данные на определенное время (Time To Live), скажем, на одну минуту. В течение этой минуты 99% запросов получают ответ мгновенно из кэша, и все счастливы.
Новая проблема — истечение кеша. Проходит ровно 60 секунд. Ключ в кеше, по которому хранилась наша страница, становится недействительным.
Лавина запросов. Именно в эту миллисекунду, в период пиковой нагрузки, на сервер прилетает 1000 одновременных запросов на главную страницу.
"Куча-мала" (The Dogpile Effect). Каждый из этих 1000 запросов обращается к кешу, видит, что данных там нет, и каждый из них решает, что именно он должен спасти мир и сгенерировать новую версию страницы. Все 1000 запросов одновременно бросаются к базе данных, выполняя одну и ту же тяжелую работу, чтобы создать кеш.
Коллапс. База данных, не рассчитанная на такую нагрузку, начинает "захлебываться", в итоге время ответа увеличивается в десятки раз, соединения обрываются, и она может полностью отказать. Пользователи видят ошибки, а система падает.

Именно этот момент — когда толпа одновременных процессов "наваливается" на один ресурс для выполнения одной и той же задачи — и есть классический The Dogpile Effect.

Ситуация, когда множество конкурентных процессов одновременно пытаются получить один и тот же ресурс, который временно недоступен, приводя к перегрузке системы.

Этот анти-паттерн детально описан в книге Майкла Нейгарда "Release It!" как одна из ключевых причин нестабильности в высоконагруженных системах.

Dogpile Effect находится в одном ряду с другими системными анти-паттернами, такими как "Cascading Failures" (Каскадные сбои) и "Race Conditions" (Состояния гонки). То есть проблема не ограничивается кешем. Это может произойти с любым общим ресурсом:

➖ Медленный микросервис, который "упал" и сейчас перезапускается;
➖ Общий конфигурационный файл, который блокируется для чтения;
➖ Внешнее API, которое медленно отвечает.

Мои поиски подтвердили: Dogpile Effect — это не экзотический или устаревший термин. Наоборот, это очень актуальная и хорошо изученная проблема в современной архитектуре.

Почему AI-ассистент использовал термин "Thundering Herd"? Читайте в следующей статье...

[Управление репликами] Dogpile Effect