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