Управление нагрузкой клиента при HTTP 429
Версия 2.7
Где считать запросы
Публичный API RouteDesk допускает 120 запросов в минуту на ключ. Если общий ключ используют несколько процессов, планировщик должен учитывать их суммарную нагрузку. Ограничение каждого процесса по отдельности может пропускать короткие всплески, например когда несколько складов одновременно выгружают статусы. Считайте в одном бюджете первичные вызовы и повторные попытки.
Действия после ответа сервера
При превышении лимита RouteDesk возвращает HTTP 429 и Retry-After в секундах. Подождите указанное время. Для дальнейших повторов используйте ограниченную экспоненциальную задержку. Если запросы выполняют несколько экземпляров приложения, сделайте признак паузы общим для потребителей этого ключа. Иначе отложенный запрос одного процесса будет конкурировать с новыми заданиями остальных процессов.
Расстановка приоритетов
Разделите задания, которые ждёт оператор, и фоновую сверку исторических заказов. Заранее зарезервируйте часть рабочего бюджета для интерактивных операций. На время перегрузки остановите необязательные обновления и сохраните прогресс очереди. Обновление статуса нескольких отправлений, которые уже доставлены, обычно можно перенести. Массовый опрос после перезапуска лучше выпускать небольшими порциями.
Контроль окна повтора
Ограничьте длительность и число автоматических попыток на стороне вашей системы. Если задержки исчерпали допустимое время заказа, сохраните задачу для ручного разбора с причиной паузы. При повторах создания сохраняйте прежний Idempotency-Key и прежнее тело, пока применимо окно хранения записи. Если результат предыдущей записи неизвестен, выясните его до создания новой операции.
Что смотреть на графике
Сопоставьте число запросов на ключ, частоту 429, фактическую задержку до повтора и возраст старейшей задачи. Пик исходящих запросов при неизменном объёме заказов может быть следствием одновременных повторов. Отметьте период нагрузки, склад или процесс и время последнего успеха. Для обращения в поддержку не включайте значение ключа, полное тело запроса или сведения о получателях.
Защита от синхронных повторов
Добавьте небольшой случайный разброс к клиентской задержке после обязательного времени ожидания. Тогда несколько экземпляров, одновременно получивших ограничение, не начнут повтор в один момент. Проверьте, что рассчитанная задержка не заканчивается раньше указанного Retry-After. Записывайте момент, когда задание снова становится доступным исполнителю, чтобы обнаруживать ранние повторы.
Проверка контролируемой перегрузки
В тестовом контуре запустите несколько фоновых задач с общим ключом и проследите, как планировщик распределяет попытки. Подготовьте искусственный ответ 429 для проверки кода задержки без нагрузки на рабочую платформу. Подтвердите, что пауза влияет на всю группу, а после её окончания накопившиеся задачи выходят небольшими порциями.