Ограничения по скорости
API Google Ads группирует запросы для ограничения частоты запросов по количеству запросов в секунду (QPS) для каждого идентификатора клиента (CID) и токена разработчика. Это означает, что учёт осуществляется независимо как для CID, так и для токенов разработчика. API Google Ads использует алгоритм Token Bucket для учёта запросов и определения подходящего лимита QPS, поэтому точный лимит будет зависеть от общей нагрузки на сервер в любой момент времени.
Целью введения ограничений по скорости является предотвращение нарушения обслуживания других пользователей одним пользователем путем (намеренно или ненамеренно) перегрузки серверов API Google Ads большим объемом запросов.
Запросы, нарушающие ограничения по скорости, будут отклонены с ошибкой: RESOURCE_TEMPORARILY_EXHAUSTED .
Вы можете взять под контроль свое приложение и снизить ограничения скорости, как активно сокращая количество запросов, так и регулируя QPS со стороны клиента.
Существует несколько способов снизить вероятность превышения лимита. Знакомство с концепциями шаблонов интеграции предприятий (EIP), такими как обмен сообщениями, повторная доставка и регулирование, поможет вам создать более надёжное клиентское приложение.
Ниже приведены рекомендуемые практики, упорядоченные по сложности, с более простыми стратегиями наверху и более надежными, но сложными архитектурами ниже:
- Ограничить одновременные задачи
- Пакетирование запросов
- Регулирование и ограничители скорости
- Очередь
Ограничить одновременные задачи
Одна из основных причин превышения ограничений частоты запросов заключается в том, что клиентское приложение генерирует чрезмерное количество параллельных задач. Хотя мы не ограничиваем количество параллельных запросов, которые может выполнять клиентское приложение, это может легко превысить ограничение на количество запросов в секунду, установленное на уровне токена разработчика.
Рекомендуется установить разумную верхнюю границу для общего числа одновременных задач, которые будут выполнять запросы (по всем процессам и машинам), а также корректировать ее в сторону увеличения для оптимизации пропускной способности, не превышая при этом предел скорости.
Кроме того, вы можете рассмотреть возможность регулирования QPS со стороны клиента (см. раздел Регулирование и ограничители скорости ).
Пакетирование запросов
Рассмотрите возможность объединения нескольких операций в один запрос. Это наиболее применимо к вызовам MutateFoo . Например, если вы обновляете статус нескольких экземпляров AdGroupAd , вместо того, чтобы вызывать MutateAdGroupAds по одному разу для каждого AdGroupAd , вы можете вызвать MutateAdGroupAds один раз и передать несколько operations . Дополнительные примеры см. в нашем руководстве по пакетным операциям .
Хотя пакетирование запросов сокращает общее количество запросов и смягчает ограничение по количеству запросов в минуту, оно может привести к срабатыванию ограничения по количеству операций в минуту, если вы выполняете большое количество операций с одной учетной записью.
Регулирование и ограничители скорости
Помимо ограничения общего количества потоков в клиентском приложении, вы также можете реализовать ограничители скорости на стороне клиента. Это позволит гарантировать, что все потоки в ваших процессах и/или кластерах будут регулироваться заданным ограничением QPS на стороне клиента.
Вы можете воспользоваться Guava Rate Limiter или реализовать собственный алгоритм на основе Token Bucket для кластерной среды. Например, можно сгенерировать токены и хранить их в общем транзакционном хранилище, например, в базе данных, и каждый клиент должен будет получить и использовать токен, прежде чем обработать запрос. Если токены будут израсходованы, клиенту придётся ждать генерации следующей партии токенов.
Очередь
Очередь сообщений — это решение для распределения рабочей нагрузки, а также для контроля количества запросов и пользователей. Существует ряд вариантов очередей сообщений — как с открытым исходным кодом, так и с собственными разработками, — и многие из них поддерживают разные языки программирования.
При использовании очередей сообщений несколько производителей могут помещать сообщения в очередь, а несколько потребителей — обрабатывать эти сообщения. Регулирование можно реализовать на стороне потребителя, ограничив количество одновременно работающих потребителей, или реализовать ограничители скорости или регуляторы скорости как для производителей, так и для потребителей.
Например, если получатель сообщения сталкивается с ошибкой ограничения скорости, он может вернуть запрос в очередь для повторной отправки. Кроме того, он может уведомить всех остальных получателей о необходимости приостановить обработку на несколько секунд для устранения ошибки.