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

Часть 3: А при чём здесь The Thundering Herd Problem?

В конце второй части я оставил вас с интригой: почему мой AI-ассистент решил поправить лектора и предложил термин Thundering Herd (Несущееся стадо бизонов)?

AI-ассистент предложил альтернативный, более старый термин — Thundering Herd. И это не случайность, ведь эти два понятия выросли из одной и той же проблемы — конкуренции.

Чтобы ответить на этот вопрос, мне пришлось копнуть еще глубже, в историю системного программирования. Оказалось, что Thundering Herd — это не совсем синоним.

Это более старый и фундаментальный анти-паттерн, родом из мира операционных систем.

Этот термин родился для описания проблемы производительности в ранних многопроцессорных Unix-системах. Классический пример, который можно найти в книге UNIX Network Programming (автор W. Richard Stevens), связан с обработкой сетевых соединений:

Классическое определение из мира ОС

Представьте себе серверное приложение, которое запускает несколько процессов или потоков, чтобы обрабатывать входящие запросы. Все эти процессы или потоки “слушают” один и тот же сетевой порт, т.е. находятся в "спящем" режиме и ждут наступления события.

Этим событием может быть что угодно: поступление данных в сетевой сокет, освобождение файла блокировки, сигнал от другого процесса. Как только событие происходит, ядро операционной системы поступает очень просто — будит все спящие процессы.

Все эти процессы, как обезумевшее стадо бизонов, одновременно просыпаются, срываются с места и несутся "схватить" это соединение, чтобы обрабатывать единственное событие.

Только один, самый быстрый процесс, выигрывает гонку и получает дескриптор соединения для работы. Остальные N-1 процессов тратят драгоценные такты процессора на пробуждение, переключение контекста и попытку установить соединение. В итоге, обнаруживают, что работы для них нет, и снова засыпают.

Это есть классический Thundering Herd ➖ колоссальная и бессмысленная трата ресурсов CPU на пробуждение и конкуренцию "лишних" процессов ради единственного события.

Со временем разработчики операционных систем научились бороться с этой проблемой на уровне ядра (например, с помощью механизмов вроде EPOLLEXCLUSIVE в Linux, которые гарантируют пробуждение только одного потока). Однако сам термин Thundering Herd оказался настолько метким и запоминающимся, что инженеры-программисты стали применять его по аналогии к проблемам на более высоком уровне.

Так почему AI предложил этот термин?

AI-ассистент увидел в рассказе лектора стадо новых реплик и выбрал самый подходящий по его мнению термин или даже паттерн, описывающий подобное поведение:

Одно инициирующее событие → множество новых реплик → хаос

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

Итак, теперь у нас на руках два "подозреваемых": Dogpile Effect, связанный с избыточной работой, и Thundering Herd, связанный с избыточной конкуренцией. Оба они, как мы видим, лишь частично описывают то, что происходило с репликами в лекции.

В современном IT-дискурсе, особенно в блогах и на конференциях, эти тонкие академические различия часто стираются, и оба термина используются для описания общего феномена "лавинообразной конкуренции".

В следующей части нашего расследования мы наконец-то вернемся к лекции и вынесем окончательный вердикт: какой же из этих терминов точнее описывает проблему, и почему лектор выбрал именно Dogpile.

[Управление репликами] Thundering Herd