Google Ads API 會根據每秒查詢次數 (QPS)，對客戶 ID 和 Google Cloud 專案分別強制執行頻率限制。除了每分鐘要求數 (用於衡量 API 呼叫頻率) 之外，Google Ads API 也會強制執行每分鐘作業數的限制 (用於衡量要求中的 API 作業總數)。Google Ads API 會使用權杖 bucket 演算法來計算要求數量，並決定適當的 QPS 限制，因此確切限制會因任何指定時間的整體伺服器負載而異。
設定頻率限制的目的，是為了防止使用者 (無論有意或無意) 傳送大量要求，導致 Google Ads API 伺服器不堪負荷，進而影響其他使用者的服務。
如果要求違反速率限制，系統會拒絕要求並傳回以下錯誤：
RESOURCE_TEMPORARILY_EXHAUSTED。
您可以主動減少要求數量，並從用戶端節流 QPS，藉此控管應用程式並減輕頻率限制。
您可以透過幾種方法，降低超過頻率限制的可能性。熟悉訊息傳遞、重新傳送和節流等企業整合模式 (EIP) 概念，有助於建構更穩健的用戶端應用程式。
以下建議做法依複雜度排序，較簡單的策略排在前面，較穩健但複雜的架構排在後面：
指數輪詢
應用程式收到 RESOURCE_TEMPORARILY_EXHAUSTED 錯誤時，請先使用指數輪詢政策和隨機抖動，再重試失敗的要求。指數輪詢會逐步增加重試之間的等待時間 (例如等待 2 秒、4 秒、8 秒，再加上短暫的隨機延遲)，讓伺服器負載和配額 bucket 恢復，同時防止用戶端執行個體同步重試而導致用量激增。
限制並行工作數量
超出頻率限制的其中一個根本原因，是用戶端應用程式產生過多平行工作。雖然我們不限制用戶端應用程式可擁有的平行要求數量，但這可能會超過 Google Cloud 專案層級的每秒要求限制。
建議您為要提出要求 (跨所有程序和機器) 的並行工作總數設定合理的上限，並向上調整，在不超過頻率限制的情況下，盡可能提高處理量。
此外，您也可以考慮從用戶端限制 QPS (請參閱「節流和頻率限制器」)。
批次要求
建議您將多項作業批次處理成單一要求。這項功能最適用於各種服務的 Mutate 呼叫。舉例來說，如要更新多個 AdGroupAd 例項的狀態，可以呼叫 MutateAdGroupAds 一次，並傳入多個 operations，而不是為每個 AdGroupAd 呼叫 MutateAdGroupAds 一次。如需其他範例，請參閱我們的批次作業指南。
雖然批次要求可減少 API 呼叫總數，並降低每分鐘要求數的頻率限制，但如果您對單一帳戶執行大量作業，可能會觸發每分鐘作業數的頻率限制。
節流和頻率限制器
除了限制應用程式中的執行緒總數，您也可以在用戶端實作頻率限制器。這可確保程序、叢集或兩者之間的所有執行緒，都受用戶端特定 QPS 限制控管。
請參閱 Guava RateLimiter，或為叢集環境實作自己的權杖 bucket 演算法。舉例來說，您可以在分散式低延遲的記憶體內資料存放區 (例如 Redis 或 Memcached) 中管理權杖，每個用戶端都會在處理要求前取得並使用權杖。如果權杖用盡，用戶端會等待下一批權杖補充完畢。
待播設定
訊息佇列是作業負載分配的解決方案，同時也能控制要求和取用端速率。訊息佇列選項有很多，有些是開放原始碼，有些是專有選項，其中許多選項可搭配不同語言使用。
使用訊息佇列時，可以讓多個生產者將訊息推送到佇列，並讓多個消費者處理這些訊息。您可以在消費者端實作節流機制，方法是限制並行消費者數量，或是為生產者或消費者實作頻率限制器或節流器。
舉例來說，如果訊息消費者遇到頻率限制錯誤，該消費者可以將要求傳回佇列，並設定標準化的重試延遲時間 (使用指數輪詢)，然後更新共用的頻率限制器回饋循環，讓所有消費者在從錯誤中復原時，自動降低處理頻率。