Очередь интеграции растёт: как посчитать, когда она разгрузится

После сбоя связи в очереди осталось несколько тысяч заданий. Сервис снова работает, обработчики запущены, но число задач почти не уменьшается. Это возможно даже без новой ошибки: входящий поток съедает почти всю производительность. Считать время разгрузки как «очередь / скорость обработки» в такой ситуации неправильно.

Сначала определите, что именно вы считаете

Нужны три величины в одинаковых единицах: число ожидающих заданий, скорость поступления новых и скорость успешного завершения. Попытки, ошибки и уникальные бизнес-задания — разные счётчики. Если один запрос повторился пять раз, пять попыток нельзя объявлять пятью обработанными заказами.

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

Арифметика без обещаний

Если в минуту успешно завершается μ заданий, а поступает λ, очередь сокращается со скоростью μ − λ. При μ больше λ ориентировочное время разбора равно размеру очереди, делённому на эту разность. При равенстве скоростей накопленный хвост не исчезает. Если поступление быстрее обработки, хвост продолжает расти.

Это линейная оценка. Она предполагает постоянную скорость и примерно одинаковую трудоёмкость заданий. Если впереди тяжёлые файлы, внешний API снижает лимиты или обработчики конкурируют за базу, прогноз придётся пересчитать. Нельзя обещать клиенту восстановление через час только по одному числу из панели очереди.

Почему добавление обработчиков иногда замедляет работу

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

Измеряйте успешную производительность после каждого изменения. Установите предел параллелизма и число повторов с увеличивающимися интервалами. Задания с устойчивой ошибкой в данных направляйте в отдельную очередь разбора: бесконечное повторение неверного артикула не позволит ему однажды стать верным.

Разделите срочные операции и восстановительный хвост

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

Нельзя просто удалить очередь, чтобы график стал зелёным. Перед очисткой надо доказать, что задания уже выполнены, устарели по правилам процесса или перенесены в другой контролируемый список. Сохраните идентификаторы и решение по каждой группе. Для операций с деньгами нужна отдельная сверка с источником истины.

План восстановления на одну смену

1. Снимите размер, возраст и распределение ошибок; остановите опасные повторы.
2. Измерьте реальную скорость успешного завершения при безопасном параллелизме.
3. Посчитайте прогноз с текущим входящим потоком, а не с нулевым.
4. Выделите безнадёжные ошибки данных и назначьте владельца разбора.
5. После восстановления сверьте бизнес-объекты: уменьшение очереди ещё не доказывает отсутствие пропусков.

В калькуляторе задайте размеры и скорости за минуту. Результат отвечает на узкий вопрос: сократится ли очередь при этих постоянных условиях и сколько времени это займёт. Он не оценивает нагрузку на ваш сервер и не рекомендует автоматически увеличивать число процессов.