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