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