Постановка в очередь Guzzle-запросов с ограничениями

1. Оберните вызовы API Заданиями и поместите их в отдельную очередь:

   ApiJob::dispatch()->onQueue('api');
   

2. Используйте пакет mxl/laravel-queue-rate-limit (я автор) для ограничения скорости api очереди. Добавьте это к config/queue.php:

   'rateLimit' => [
       'api' => [
           'allows' => 40,
           'every' => 10
       ]
   ]
   

3. Запустить обработчик очереди:

   $ php artisan queue:work --queue api
   

См. также этот ответ.

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

Вы можете использовать $res->getStatusCode() из guzzle, чтобы проверить это и вернуть сообщение пользователю, если он делает слишком много запросов слишком быстро.

Можете ли вы предоставить дополнительную информацию о том, что делает ваше приложение? Вы делаете запросы в цикле foreach? Зависит ли представление от данных из этого API?

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

Я использую Cache для хранения количества запущенных запросов.

while(($count = Cache::get($this->getCacheKey(),0)) >= 40){ // Max request
    sleep(1);
}
Cache::set($this->getCacheKey(), ++$count);
// fire request

function getCacheKey(){
    return floor(time()/10); // Cool down time
}

Очередь кажется лучшим вариантом, и я в конечном итоге перейду к этому. Есть несколько вещей, которые вам нужно иметь в виду, прежде чем ставить очередь между ними.

1. Архитектура на основе обратного вызова, поскольку вам может потребоваться сохранить состояние сериализации кода в очереди. Дизайн, основанный на обратном вызове, даст полный контроль Client классу. Вам не придется беспокоиться о дросселировании в вашем коде.
2. Сериализация может быть сложной, попробуйте __sleep и __wakeup.
3. Вы также можете приоритизировать несколько звонков, вы можете выделить квоту от клиентов для таких звонков.

Лично я думаю, что Guzzle не должен обрабатывать этот случай, но если вы хотите, чтобы Guzzle справился с этим, я бы написал промежуточное программное обеспечение, которое проверяет ответ и возвращает ли он ошибку ограничения скорости (например, код состояния 429). Затем вы можете либо выдать пользовательскую ошибку, либо дождаться окончания ограничения скорости и повторить попытку. Однако это может привести к длительному времени отклика (поскольку вы ждете ограничения скорости).

Я не думаю, что очередь Laravel была бы лучше, так как это сделало бы ответ асинхронно доступным, и вам пришлось бы опрашивать вашу базу данных или ваш кеш, где бы вы ни хранили результаты. (Конечно, это может сработать, если вам не нужно, чтобы результаты были доступны немедленно)

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