頻率限制
Google Ads API 會根據每個用戶端客戶 ID (CID) 和開發人員權杖的每秒查詢次數 (QPS)，將要求分組以進行頻率限制，也就是說，系統會分別對 CID 和開發人員權杖強制執行計量。Google Ads API 會使用 Token Bucket 演算法來計算要求，並判斷適當的 QPS 限制，因此確切限制會因任何特定時間的整體伺服器負載而異。
設定速率限制是為了防止使用者 (無論是有意或無意) 傳送大量要求，導致 Google Ads API 伺服器不堪負荷，進而中斷其他使用者的服務。
如果要求違反頻率限制，系統會拒絕要求並傳回以下錯誤：
RESOURCE_TEMPORARILY_EXHAUSTED。
您可以主動減少要求數量，並從用戶端節流 QPS，藉此控管應用程式並減輕速率限制。
您可以透過幾種方式降低超過頻率限制的可能性。 熟悉企業整合模式 (EIP) 概念，例如訊息傳遞、重新傳送和節流，有助於建構更穩健的用戶端應用程式。
以下是建議做法，依複雜度排序，簡單的策略位於頂端，後方則是更強大但複雜的架構：
限制並行工作
超過速率限制的其中一個根本原因是，用戶端應用程式產生過多的平行工作。雖然我們不會限制用戶端應用程式可發出的並行要求數量，但這可能會超過開發人員權杖層級的每秒要求數限制。
建議您為要發出要求的並行工作總數 (跨所有程序和機器) 設定合理的上限，並向上調整以盡量提高輸送量，但不要超過速率限制。
此外，您也可以考慮從用戶端節流每秒查詢次數 (請參閱「節流和速率限制工具」)。
批次處理請求
建議將多項作業批次處理為單一要求。這項功能最適合用於 MutateFoo 通話。舉例來說，如果您要更新多個 AdGroupAd 執行個體的狀態，可以呼叫一次 MutateAdGroupAds，並傳入多個 operations，不必為每個 AdGroupAd 呼叫一次 MutateAdGroupAds。如需其他範例，請參閱批次作業指南。
雖然批次處理要求可減少要求總數，並降低每分鐘要求次數的速率限制，但如果您對單一帳戶執行大量作業，仍可能觸發每分鐘作業次數的速率限制。
節流和頻率限制器
除了限制用戶端應用程式中的執行緒總數，您也可以在用戶端實作速率限制工具。這可確保程序和 / 或叢集中的所有執行緒，都受到用戶端特定 QPS 限制的控管。
您可以查看 Guava Rate Limiter，或為叢集環境實作自己的憑證區塊演算法。舉例來說，您可以產生權杖並儲存在共用交易儲存空間 (例如資料庫)，每個用戶端都必須先取得並使用權杖，才能處理要求。如果代幣用完，用戶端就必須等到下一批代幣產生。
待播設定
訊息佇列是作業負載分配的解決方案，同時也能控管要求和取用端速率。訊息佇列選項有很多，有些是開放原始碼，有些是專有選項，其中許多選項可搭配不同語言使用。
使用訊息佇列時，可以有多個生產者將訊息推送到佇列，並有多個消費者處理這些訊息。您可以透過限制並行消費者數量，在消費者端實作節流機制，也可以為生產者或消費者實作速率限制器或節流機制。
舉例來說，如果訊息消費者遇到速率限制錯誤，該消費者可以將要求傳回佇列，以便重試。同時，該消費者也可以通知所有其他消費者暫停處理幾秒，以從錯誤中復原。