頻率限制

Google Ads API 會將每個用戶端客戶 ID (CID) 和開發人員權杖的每秒查詢次數 (QPS) 要求頻率限制,這表示計量作業會同時針對客戶 ID 和開發人員權杖強制執行。Google Ads API 使用代碼值區演算法來衡量要求,並決定適當的每秒查詢次數限制,因此確切的限制會因任一時間點的總伺服器負載而異。

實施頻率限制的目的,是要避免 (或無意) 大量請求 Google Ads API 伺服器,導致大量的使用者服務中斷,進而影響其他使用者的服務中斷。

違反頻率限制的要求會遭到拒絕,並傳回錯誤:RESOURCE_TEMPORARILY_EXHAUSTED

您可以透過主動減少要求數量以及從用戶端調節 QPS 來控制應用程式,並改善頻率限制。

有幾種方法可以降低超過頻率限制的可能性。 熟悉訊息傳遞、重新提交和節流等企業整合模式 (EIP) 概念,將有助於建立更強大的用戶端應用程式。

以下為按複雜度排序的建議方法,頂端有更精簡的策略,之後則是更健全而複雜的架構:

限制並行工作

超過頻率限制的根本原因之一,就是用戶端應用程式會大量執行平行工作。雖然我們不限制用戶端應用程式的平行要求數,但這很容易超出開發人員權杖層級的「每秒要求數」限制。

建議您針對要發出要求的並行工作總數設定合理的上限 (適用於所有程序和機器),並應向上調整,以提高總處理量並超過頻率限制。

此外,您也可以考慮從用戶端調節 QPS (請參閱節流和頻率限制)。

批次處理請求

請考慮將多項作業批次處理為單一要求。這適用於 MutateFoo 呼叫。舉例來說,如果您要更新多個 AdGroupAd 的執行個體狀態,而無需為每個 AdGroupAd 呼叫 MutateAdGroupAds,可以只呼叫 MutateAdGroupAds,然後傳入多個 operations。如需其他範例,請參閱批次作業指南

批次要求可減少要求總數,並降低「每分鐘要求數」頻率限制,但如果您針對單一帳戶執行大量作業,可能會觸發「每分鐘作業的作業頻率」限制。

節流和頻率限制

除了限制用戶端應用程式中的執行緒總數以外,您也可以在用戶端實作頻率限制。這可以確保用戶端和/或叢集中的所有執行緒都受到用戶端的特定 QPS 限制規範。

您可以查看 Guava 頻率限制器,或為叢集環境實作自己的權杖值區演算法。例如,您可以產生符記,並將其儲存在共用的交易儲存空間 (如資料庫) 中,且每個用戶端在處理要求之前,都必須取得及使用權杖。如果符記已使用,用戶端就必須等待到下一個批次符記產生作業。

排程

訊息佇列是作業負載分配的解決方案,同時控制要求和消費者費率。目前有許多訊息佇列選項,有些有開放原始碼,有些則是專屬,而且其中多數選項可搭配不同的語言。

使用訊息佇列時,您可以讓多個製作者將訊息推送至佇列,以及多個處理這些訊息的消費者。您可透過限制消費者人數,或者限制生產者或消費者的速率限制器或節流器,藉此在消費者端實作節流。

舉例來說,如果訊息消費者遇到頻率限制錯誤,消費者可以將要求傳回待重試佇列。同時,消費者也可以通知所有其他消費者暫停處理作業數秒,以便從錯誤中復原。