頻率限制
Google Ads API 值區上的要求頻率限制，會以每個用戶端客戶 ID (CID) 和開發人員權杖的每秒查詢次數 (QPS) 和開發人員權杖為依據，這代表系統會分別強制要求客戶 ID 和開發人員權杖執行計量功能。Google Ads API 使用權杖值區演算法來測量要求，並決定適當的 QPS 限制，因此確切限制會隨時間的整體伺服器負載量而有所不同。
設定頻率限制的目的，是防止某位使用者因故意或無意間) 對 Google Ads API 伺服器發出大量要求，中斷其他使用者的服務。
系統會拒絕違反頻率限制的要求，並傳回以下錯誤：RESOURCE_TEMPORARILY_EXHAUSTED。
您可以積極減少要求數量，並從用戶端限制 QPS，藉此控管應用程式並降低頻率限制。
您可以透過許多方式降低超出頻率限制的機率。熟悉訊息傳遞、再傳遞和節流等「企業整合模式」(EIP) 概念，有助於建構更強大的用戶端應用程式。
以下建議做法是按複雜性排序，在其後採用較簡單的策略，頂層和更穩健但複雜的架構：
限制並行工作
超出頻率限制的根本原因之一，是用戶端應用程式產生過多平行工作。雖然系統並未限制用戶端應用程式的平行要求數量，但很容易超過開發人員權杖層級的每秒要求數限制。
建議您針對會發出要求的並行工作總數設定合理的上限 (跨所有程序和機器)，並在不超出頻率限制的情況下向上調整，將總處理量達到最佳狀態。
此外，您也可以考慮從用戶端調節 QPS (請參閱限制和頻率限制器)。
批次處理請求
請考慮將多項作業批次處理為單一要求。這最適合用於 MutateFoo 呼叫。舉例來說，如要更新多個 AdGroupAd 例項的狀態，可以只呼叫 MutateAdGroupAds 一次，並傳入多個 operations，不必針對每個 AdGroupAd 呼叫一次 MutateAdGroupAds。如需其他範例，請參閱批次作業指南。
雖然批次處理要求可減少要求總數並降低「每分鐘要求數」的頻率限制，但如果您對單一帳戶執行大量作業，則可能會觸發「每分鐘作業數」的頻率限制。
節流和頻率限制器
除了限制用戶端應用程式中的執行緒總數外，您也可以在用戶端實作頻率限制器。這可確保整個程序及 / 或叢集中的所有執行緒都受到用戶端的特定 QPS 限制所規範。
您可以查看 Guava 頻率限制器，或針對叢集環境導入您自己的權杖值區演算法。例如，您可以產生權杖並儲存在共用交易儲存空間 (例如資料庫)，而且每個用戶端在處理要求之前，都必須先取得並使用權杖。如果已使用符記，用戶端必須等待下一批權杖產生。
待播設定
訊息佇列是作業負載分配的解決方案，也能控管要求和取用端速率。許多訊息佇列選項可用，有些是開放原始碼，有些則獨有，而且其中許多選項可處理不同語言。
使用訊息佇列時，您可以讓多個生產端將訊息推送至佇列，並由多個取用端處理這些訊息。您可以限制同時取用者的數量，或是為生產者或取用者實施頻率限制器或節流器，藉此在取用端實作節流。
例如，如果訊息取用者遇到頻率限制錯誤，取用端可將要求傳回佇列來重試。同時，取用者也可以通知所有其他取用者，在錯誤中恢復幾秒鐘。