Почему источник ограничивает обращения, как отличить паузу от потери данных и что проверить, чтобы отчёт оставался полным.
Источник работает, но просит подождать
Утром команда ждёт свежую таблицу заказов. Загрузка уже получила часть данных, затем остановилась. Источник доступен, пароль не меняли, но новые обращения временно отклоняются. Это может быть ограничение частоты запросов — правило о том, сколько обращений система принимает за определённый промежуток времени.
API — интерфейс, через который одна программа получает сведения у другой. Каждое обращение использует ресурсы поставщика: он проверяет доступ, ищет записи и готовит ответ. Ограничение помогает распределить нагрузку между потребителями. Само по себе оно не означает, что записи удалены или источник перестал существовать.
Чей запас обращений расходуется
Лимит может относиться к пользователю, приложению, подключению или адресу, с которого приходят обращения. Несколько процессов иногда расходуют один общий запас. Поэтому отдельная загрузка выглядит спокойной, а совокупная нагрузка оказывается слишком высокой.
В документации GitHub описаны основные ограничения за период и дополнительные ограничения, в том числе на одновременно выполняемые обращения. Значения зависят от условий доступа. Это пример конкретного поставщика: переносить его правила на другой API нельзя. Перед планированием загрузки нужно проверить условия именно своего источника.
Условный пример двух загрузок
Представим учебный источник, который разрешает восемь обращений в минуту. Одна загрузка собирает каталог и делает шесть обращений. Вторая получает остатки товаров и делает ещё четыре. Каждая укладывается в предел отдельно, но вместе им нужны десять обращений. Два обращения придётся выполнить позже.
Если первая загрузка успела получить четыре части из шести, её результат пока неполный. Остатки могли завершиться раньше. Таблица с ценами и остатками тогда отражает разные стадии обновления, даже если оба процесса написаны правильно.
Для читателя отчёта важен простой вопрос: закончился ли сбор всего ожидаемого набора? Нельзя считать частичный результат полным только потому, что первые ответы были успешными. Допустимое время ожидания стоит сопоставить со сроком, когда данные действительно нужны бизнесу.
Почему частые повторы не помогают
Если поставщик просит подождать, немедленное повторение того же обращения не создаёт дополнительный запас. Оно способно увеличить нагрузку и продлить проблему. Рекомендации GitHub по работе с API предлагают учитывать указанный срок ожидания, ограничивать повторы и прекращать бесконечные попытки.
Пауза должна быть объяснимой: какая часть уже получена, почему продолжение отложено и когда ожидается следующая попытка. Иначе сотрудник видит только неподвижный индикатор и запускает ещё одну загрузку вручную. В нашем примере это добавит третьего потребителя того же лимита.
Что проверить перед изменением расписания
Сначала соберите картину обращений всех процессов. Уточните, какой лимит сработал, делят ли процессы одно подключение и сохраняется ли безопасная точка продолжения. Отдельно проверьте, как отчёт обозначает незавершённое обновление.
- Есть ли описание ограничений у поставщика?
- Выполняются ли несколько загрузок одновременно?
- Как определяется полнота полученного набора?
- Укладывается ли ожидание в срок подготовки отчёта?
- Кто узнает, если загрузка так и не завершится?
Ответом может стать разнесение обращений во времени или изменение способа получения данных. Ускорять процесс имеет смысл после понимания ограничения, а не увеличением количества повторов наугад.
Как перейти к практике
Если хотите понимать, как такие решения работают в проектах, посмотрите Data Engineer для начинающих. Начните с назначения механизмов, затем связывайте их с задачами вашей команды.
