Запросы ограничения скорости и Amazon SQS

Question

У меня вопрос о том, как замедлить мои запросы api. Для конкретного стороннего API я нажимаю, позволяя мне делать 3 запроса каждые 2 секунды. Если я перейду через это число, я вернусь status code 429 вместе с временем ожидания в миллисекундах.

Этот api часто называется и является прямым результатом моего собственного сервера, имеющего входящие запросы, которые не ограничены скоростью.

Поскольку у меня нет необходимости в синхронном обращении с сторонними запросами api, я решил разгрузить эту работу в мой рабочий блок beanstalk для работы на AWS, который по умолчанию читается из Amazon SQS.

В результате мой работник будет отправлять сообщение SQS обратно в очередь, если код статуса 429 возвращается из стороннего api. Это неизбежно заставляет работу api работать, когда достигается ожидание. Это, однако, похоже на плохое решение

Есть ли способ сообщить демонам на рабочем поле оставить сообщение в очереди за выделенное время ожидания? Или я могу, возможно, установить скорость, с которой демон будет читать из очереди? Я ищу подходящий способ (конкретный вариант реализации) для ограничения скорости с использованием рабочего и очереди на AWS. Большое вам спасибо за помощь!

EDIT: Я бы предположил, что существуют конфигурации, которые могут быть изменены на AWS, чтобы делать то, что я прошу, но в любом случае я ищу конкретные решения для описанной вами установки. Я не совсем уверен, как модифицировать или контролировать демона на рабочей панели с эластичным бобовым сундуком.

Answer 1

Как я понимаю, у вас есть куча триггеров для вызова стороннего сервиса, и вам необходимо ограничить скорость вызовов API.

Лучший способ - ограничить доступ к демону, который читается из SQS. В зависимости от языка, на котором записывается демон, вы должны легко находить библиотеки ограничения скорости, которые можно повторно использовать. Например, Java и Python имеют хорошо протестированные библиотеки here и here соответственно.

Имейте в виду, что эти библиотеки позволят X запросов в секунду на каждого работника. Если у вас есть один демон, X будет 1,5, для вашего варианта использования. Если у вас есть два демона (например, один на двух разных машинах), X должен быть 0,75

Answer 2

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

Если это так, то вы, вероятно, захотите посмотреть changing the message visibility времени.

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

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