透過集合功能整理內容 你可以依據偏好儲存及分類內容。

頻率限制

Google Ads API 值區會針對各個客戶客戶 ID (CID) 和開發人員權杖的每秒查詢次數 (QPS) 要求限制頻率要求,這表示系統會同時針對客戶 ID 和開發人員權杖強制進行計量。Google Ads API 使用權杖值區演算法來計量要求,並判斷適當的 QPS 限制,因此實際限制會因在任何時候的伺服器整體負載而異。

設定頻率限制的目的,在於避免使用者以刻意或無意的方式,幹擾大量 Google Ads API 伺服器,導致服務中斷。

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

您可以主動減少要求數量,以及從用戶端限制 QPS,藉此控制應用程式並降低頻率限制。

有許多方法可以降低超過頻率限制的機會。 熟悉訊息傳遞、重新提交和節流等企業整合模式 (EIP) 概念,可協助您建構更強大的用戶端應用程式。

以下為依複雜程度排序的建議做法,頂端有策略簡單的策略,其後的架構也更加完善可靠:

限制並行任務數量

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

建議您針對即將發出的並行工作總數設定所有門檻 (適用於所有程序和機器),並向上調整,以盡可能提高總處理量,但不要超過頻率限制。

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

批次處理請求

請考慮將多項作業批次處理為單一要求。這適用於 MutateFoo 呼叫。舉例來說,假設您想更新 AdGroupAd 的多個執行個體狀態,而不是逐一呼叫 MutateAdGroupAds,則只要呼叫 MutateAdGroupAds 並傳入多個 operations 即可。如需其他範例,請參閱批次作業指南

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

節流與頻率限制

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

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

排入佇列

訊息佇列是運作負載分配的解決方案,同時控制要求和消費者費率。有多種訊息佇列選項可供選擇,部分為開放原始碼,有些則屬於專屬,而且其中許多選項可搭配不同語言使用。

使用訊息佇列時,您可以讓多個製作者推送訊息至佇列,並由多個取用者處理這些訊息。限制並行消費者的數量,或為生產者或消費者導入頻率限制器或節流器,以便在消費者端執行節流。

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