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 и снизить вероятность превышения ограничения частоты запросов на количество запросов в минуту, но при этом могут привести к превышению лимита на количество операций в минуту, если вы выполняете большое количество операций с одним аккаунтом.
Ограничение частоты запросов
Помимо ограничения общего количества потоков в приложении, вы также можете реализовать ограничители частоты запросов на стороне клиента. Это гарантирует, что все потоки в ваших процессах, кластерах или и в том, и в другом будут регулироваться определенным ограничением QPS на стороне клиента.
Используйте Guava RateLimiter или реализуйте собственный алгоритм сегмента-маркера для кластерной среды. Например, вы можете управлять токенами в распределенном хранилище данных в памяти с низкой задержкой, таком как Redis или Memcached, где каждый клиент получает и использует токен перед обработкой запроса. Если токены закончились, клиент ждет, пока не будет пополнена следующая партия.
Очередь
Очередь сообщений позволяет распределять нагрузку на операции, а также контролировать скорость обработки запросов и потребителей. Существует множество вариантов очередей сообщений, некоторые из которых являются открытыми, а некоторые – проприетарными, и многие из них могут работать с разными языками.
При использовании очередей сообщений у вас может быть несколько производителей, отправляющих сообщения в очередь, и несколько потребителей, обрабатывающих эти сообщения. Ограничение частоты запросов можно реализовать на стороне потребителя, ограничив количество одновременных потребителей, или внедрив ограничители частоты запросов или ограничители для производителей или потребителей.
Например, если потребитель сообщений сталкивается с ошибкой ограничения частоты запросов, он может вернуть запрос в очередь со стандартной задержкой повторной попытки (используя экспоненциальную выдержку) и обновить общий цикл обратной связи ограничителя частоты запросов, чтобы все потребители автоматически снижали частоту обработки при восстановлении после ошибки.