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

Question

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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