Условие
Идут обычные рабочие будни. Вы — ведущий DevOps-инженер в крупном маркетплейсе. В компании вовсю идет распродажа, и система распределенных вычислений на базе Celery работает на пределе возможностей, обрабатывая терабайты аналитики. В самом начале смены дежурный инженер замечает в системе ровно 100 активных задач. Согласно внутренней архитектуре, эти задачи зациклены: каждая задача после своего успешного завершения автоматически генерирует и ставит в очередь ровно одну новую задачу.
Через пару часов инженер бьет тревогу в рабочий чат: «Ребята, у нас проблема! График застыл! Похоже, планировщик завис или сеть легла, процессы не плодятся!». Вы открываете логи, смотрите на графики мониторинга и… Система работает абсолютно штатно, никакого бага нет.
Задача
Объясните паникующему инженеру, почему его логика отказала. Как так получилось, что количество задач не растет? Напишите простую симуляцию этого процесса на Python, чтобы наглядно показать коллеге, как ведет себя такая очередь.
Решение
На первый взгляд условие кажется однозначным: каждая задача порождает еще одну, значит система должна демонстрировать рост нагрузки. Ключевая деталь заключается в том, что формулировка «каждая задача создает новую» не определяет жизненный цикл задачи как единицы работы системы.
Важное уточнение: задача порождает замену, а не рост. В реальных системах распределенной обработки (job queue, worker-based архитектуры) часто используется модель «обработал → заменил». На практике задача выполняется, после завершения создается новая задача того же типа, а старая задача удаляется из системы.
То есть система не увеличивает количество задач, а поддерживает их количество постоянным. Стабилизация очереди возникает по нескольким причинам:
- система работает в режиме steady-state (устойчивого состояния);
- скорость обработки задач равна скорости их генерации;
- это выполняется не «в среднем со временем», а на каждом шаге с самого начала — с первых же 100 задач.
В таком состоянии количество завершенных задач в единицу времени = количеству созданных задач в единицу времени. И поэтому общее число задач в очереди перестаёт расти.
Путаница инженера логическая, а не архитектурная: он представил, что новая задача «где-то» добавляется в систему, и поэтому очередь должна прирастать. Но в условии буквально сказано, что задача генерируется не в произвольный момент, а строго в конце жизни породившей ее задачи — сразу после ее успешного завершения. Иначе говоря, списание выполненной задачи и постановка новой происходят одновременно, один к одному: минус одна завершенная задача, плюс одна новая — и на длине очереди это никак не сказывается. Именно эту одновременность инженер и упустил, ожидая, что задачи будут копиться быстрее, чем исчезать.
Решение на Python
Чтобы доказать стабилизацию формально, достаточно такого простого кода:
tasks = 100 for t in range(10): # 10 условных шагов времени completed = tasks created = completed # 1 к 1 tasks = tasks- completed + created print(f"step {t}: tasks = {tasks}")
Более работоспособная модель включает очередь задач, обработчики и ограничение на параллелизм:
from collections import deque
queue = deque(range(100))
processed = 0
workers = 10
iterations = 20
for step in range(iterations):
batch = []
for _ in range(min(workers, len(queue))):
batch.append(queue.popleft())
for task in batch:
processed += 1
queue.append(task + 1000)
print(f"step {step}: queue length = {len(queue)}")
print(f"processed total: {processed}")
Заключение
В этом задании весь парадокс возникает из-за неоднозначности формулировки «создает новую задачу». В реальных распределенных системах это почти всегда означает не рост нагрузки, а замену завершенной работы новой единицей выполнения. Поэтому стабилизация очереди — нормальное состояние системы.
