Какова правильная реакция клиента на HTTP 429, когда клиент является многопоточным? - PullRequest
Новая
       34

Какова правильная реакция клиента на HTTP 429, когда клиент является многопоточным?

0 голосов
/ 24 ноября 2018

Код состояния HTTP 429 сообщает клиенту, выполняющему запрос, отменить запрос и повторить запрос через период, указанный в заголовке Retry-After ответа.

В однопоточном клиенте очевидно, чтопоток, получающий 429, должен ждать, как сказано, и затем повторить попытку.Но RFC прямо заявляет, что

эта спецификация не определяет, как сервер-источник идентифицирует пользователя и как он считает запросы.

Следовательнов многопоточном клиенте консервативный подход не позволяет всем потокам отправлять запросы до момента повторной попытки.Но:

  • Многие потоки уже могут пройти точку, в которой они могут записать информацию из одного отклоненного потока, и отправят как минимум еще один запрос.
  • Глобальная синхронизация междуПотоки могут быть трудны для реализации и получения правильных
  • Если установка запускает не только несколько потоков, но и несколько клиентов, возможно, на разных компьютерах, откат их всех на одном 429 становится нетривиальным.

У кого-нибудь есть конкретные данные из области, как серверы облачных провайдеров на самом деле обрабатывают это?Будут ли они немедленно обостряться, если я не буду сдерживать все темы? Совет Microsoft равен

  1. Подождите количество секунд, указанное в поле Retry-After.
  2. Повторите запрос.
  3. Если запрос снова завершается с ошибкой с кодом ошибки 429, вы все еще ограничены.Продолжайте использовать рекомендованную задержку Retry-After и повторяйте запрос до тех пор, пока он не будет выполнен.

Он дважды говорит «запрос», а не «любые запросы» или «все запросы», но этоправовая интерпретация, в которой я не уверен.

Чтобы убедиться, что это не вопрос мнения, позвольте мне сформулировать его как можно более основанное на фактах:

Существуют ли более подробные спецификации для облака?API (Microsoft, Google, Facebook, Twitter), а затем приведенный выше пример, который позволяет мне принять информированное решение о необходимости глобального отката или достаточно откатить по конкретному запросу, получившему 429?

1 Ответ

0 голосов
/ 12 мая 2019

Серверы знают, что это нужно для синхронизации или ожидать, что программисты сделают это.Поэтому сомневайтесь, есть ли наказание, если только они не получат океан запросов, которые вообще не откатываются после 429.

Каждый поток должен ждать, но каждый будет, после того, как ему будут сообщены индивидуально.

Хорошая система будет знать, какова ее скорость, и будет в этом.Один из способов добиться этого - иметь переменную sleepFor между запросами.Точное значение prod может быть получено методом проб и ошибок и будет временем ожидания минус время предыдущего запроса.

Так что, если один запрос заканчивается, и, скажем, это заняло x миллисекунд.Теперь, если время ожидания равно 0 или меньше, немедленно перейдите к следующему запросу, если 1 или больше, чем выясните sleepTime-x, если это значение меньше 1, перейдите к следующему немедленно, в противном случае, спите в течение стольких миллисекунд, а затем перейдите к следующему запросу..

Другим способом было бы иметь счет для каждых 5 минут или около того, и затем, если фактический запрос потока больше, чем тогда, он спит до 5 минут, прежде чем перейти к следующему.Здесь 5 можно настроить как timePeriod.

Что мы делаем, это храним эти значения в базе данных, но кешируем их во время выполнения.Также есть страница для аннулирования кэшей, поэтому, если мы захотим, мы можем обновить базу данных со страницы администратора, а затем аннулировать кэши, и, таким образом, клиенты будут получать новую информацию во время работы.Это помогает настроить правильное значение, чтобы оно оставалось в пределах ограничений API и выполняло достаточное количество заданий.

...