頻率限制
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 頻率限制 er，或針對叢集環境實作您自己的權杖值區演算法。例如，您可以產生權杖並儲存在共用交易儲存空間 (例如資料庫)，而且每個用戶端在處理要求之前，都必須取得及使用權杖。如果已使用符記，用戶端就必須等到系統產生下一批符記後。
待播設定
訊息佇列是作業負載分配的解決方案，同時又可用來控制要求和消費者比率。市面上有許多訊息佇列選項可用，其中有些是開放原始碼，有些則是專屬用途，而許多選項也可以使用不同語言。
使用訊息佇列時，您可以讓多個生產端將訊息推送至佇列，並由多個取用端處理這些訊息。您可以透過限制並行取用者的數量，或為生產者或取用者實作頻率限制器或節流器，藉此在取用端實作節流。
舉例來說，如果訊息使用者遇到頻率限制錯誤，取用者可將要求傳回至要重試的佇列。同時，消費者也可以通知其他所有取用端，暫停處理一段秒數，以便從錯誤中復原。