Google Ads API ограничивает количество запросов в секунду (QPS) как для идентификаторов клиентов, так и для проектов Google Cloud. Помимо количества запросов в минуту (частоты вызовов API), в Google Ads API также ограничено количество операций в минуту (общее количество операций API во всех запросах). Google Ads API использует алгоритм сегмент-маркера, чтобы измерять запросы и определять подходящее ограничение на количество запросов в секунду. Поэтому точное ограничение зависит от общей нагрузки на сервер в любой момент времени.
Ограничения частоты запросов нужны для того, чтобы один пользователь не мог нарушить работу сервиса для других пользователей, намеренно или случайно перегрузив серверы Google Ads API большим количеством запросов.
Запросы, нарушающие ограничения частоты запросов, отклоняются с ошибкой RESOURCE_TEMPORARILY_EXHAUSTED.
Вы можете контролировать свое приложение и смягчать ограничения частоты запросов, активно сокращая количество запросов и регулируя количество запросов в секунду на стороне клиента.
Есть несколько способов снизить вероятность превышения ограничения частоты запросов. Чтобы создать более надежное клиентское приложение, ознакомьтесь с концепциями шаблонов интеграции корпоративных приложений (EIP), такими как обмен сообщениями, повторная доставка и регулирование.
Рекомендации ниже упорядочены по сложности: от простых стратегий до более надежных, но сложных архитектур.
- Экспоненциальная задержка
- Ограничение количества параллельных задач
- Пакетная обработка запросов
- Ограничение частоты запросов
- Очередь
Экспоненциальная выдержка
Если приложение получает ошибку RESOURCE_TEMPORARILY_EXHAUSTED, используйте экспоненциальную выдержку со случайным джиттером, прежде чем повторить неудавшийся запрос. Экспоненциальная выдержка постепенно увеличивает время ожидания между повторными попытками (например, 2 секунды, затем 4 секунды, затем 8 секунд плюс небольшая случайная задержка), позволяя восстановить нагрузку на сервер и корзины квот, предотвращая при этом синхронизированные всплески повторных попыток в экземплярах клиента.
Ограничение на количество параллельных задач
Одна из основных причин превышения ограничений частоты запросов заключается в том, что клиентское приложение порождает чрезмерное количество параллельных задач. Хотя мы не ограничиваем количество параллельных запросов, которые может отправлять клиентское приложение, это может привести к превышению лимита на количество запросов в секунду на уровне проекта Google Cloud.
Рекомендуется установить разумную верхнюю границу для общего количества параллельных задач, которые будут отправлять запросы (для всех процессов и компьютеров), и корректировать ее в сторону увеличения, чтобы оптимизировать пропускную способность, не превышая ограничение частоты запросов.
Кроме того, вы можете ограничить количество запросов в секунду на стороне клиента (см. раздел Ограничение частоты запросов).
Пакетные запросы
Попробуйте объединить несколько операций в один запрос. Это наиболее актуально для вызовов Mutate для различных сервисов. Например, если вы обновляете статус нескольких экземпляров AdGroupAd, вы можете вызвать MutateAdGroupAds один раз и передать несколько operations вместо того, чтобы вызывать MutateAdGroupAds по одному разу для каждого AdGroupAd. Дополнительные примеры приведены в руководстве по пакетным операциям.
Пакетная обработка запросов позволяет уменьшить общее количество вызовов API и снизить ограничение частоты запросов. Однако если вы выполняете большое количество операций в одном аккаунте, то можете превысить ограничение на число операций в минуту.
Ограничение частоты запросов
Помимо ограничения общего количества потоков в приложении, вы также можете реализовать ограничители частоты запросов на стороне клиента. Это гарантирует, что все потоки в ваших процессах и/или кластерах будут регулироваться определенным ограничением на количество запросов в секунду со стороны клиента.
Используйте Guava RateLimiter или реализуйте собственный алгоритм сегмент-маркера для кластерной среды. Например, вы можете управлять токенами в распределенном хранилище данных в памяти с низкой задержкой, таком как Redis или Memcached, где каждый клиент получает и использует токен перед обработкой запроса. Если токены исчерпаны, клиент ждет, пока не будет пополнена следующая партия токенов.
Очередь
Очередь сообщений – это решение для распределения операционной нагрузки, которое также позволяет контролировать частоту запросов и потребителей. Существует множество вариантов очередей сообщений, некоторые из которых являются ПО с открытым исходным кодом, а некоторые – проприетарными, и многие из них могут работать с разными языками.
При использовании очередей сообщений у вас может быть несколько производителей, отправляющих сообщения в очередь, и несколько потребителей, обрабатывающих эти сообщения. Ограничения можно реализовать на стороне потребителя, ограничив количество одновременных потребителей, или реализовав ограничение частоты запросов или дроссели для производителей или потребителей.
Например, если потребитель сообщений сталкивается с ошибкой ограничения частоты запросов, он может вернуть запрос в очередь со стандартной задержкой повторной попытки (используя экспоненциальную выдержку) и обновить цикл обратной связи общего ограничителя частоты запросов, чтобы все потребители автоматически снижали скорость обработки при восстановлении после ошибки.