透過集合功能整理內容
你可以依據偏好儲存及分類內容。
頻率限制
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，並傳入多個 operations，而不是為每個 AdGroupAd 呼叫一次 MutateAdGroupAds。如需其他範例，請參閱批次作業指南。
雖然批次處理要求可減少要求總數，並降低每分鐘要求次數的速率限制，但如果您對單一帳戶執行大量作業，可能會觸發每分鐘作業次數的速率限制。
節流和頻率限制器
除了限制用戶端應用程式中的執行緒總數，您也可以在用戶端實作頻率限制工具。這樣可確保程序和 / 或叢集中的所有執行緒，都受到用戶端特定 QPS 限制的控管。
您可以查看 Guava Rate Limiter，或為叢集環境實作自己的憑證區塊演算法。舉例來說，您可以產生權杖並儲存在共用交易式儲存空間 (例如資料庫)，每個用戶端都必須先取得並使用權杖，才能處理要求。如果代幣用完，用戶端就必須等到下一批代幣產生。
待播設定
訊息佇列是作業負載分配的解決方案，同時也能控管要求和消費者速率。訊息佇列選項有很多，有些是開放原始碼，有些是專有選項，其中許多選項都可搭配不同語言使用。
使用訊息佇列時，可以讓多個生產者將訊息推送至佇列，並讓多個消費者處理這些訊息。您可以透過限制並行消費者數量，在消費者端實作節流機制，也可以為生產者或消費者實作速率限制器或節流機制。
舉例來說，如果訊息消費者遇到速率限制錯誤，該消費者可以將要求傳回佇列，以便重試。同時，該消費者也可以通知所有其他消費者暫停處理幾秒，以從錯誤中復原。
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2025-08-27 (世界標準時間)。
[null,null,["上次更新時間：2025-08-27 (世界標準時間)。"],[[["\u003cp\u003eThe Google Ads API uses rate limits to prevent service disruption, enforced by queries per second (QPS) per client customer ID and developer token.\u003c/p\u003e\n"],["\u003cp\u003eExceeding rate limits results in a \u003ccode\u003eRESOURCE_TEMPORARILY_EXHAUSTED\u003c/code\u003e error and can be mitigated by reducing request frequency and throttling QPS.\u003c/p\u003e\n"],["\u003cp\u003eStrategies for managing rate limits include limiting concurrent tasks, batching requests, implementing client-side throttling, and using message queues for load distribution.\u003c/p\u003e\n"],["\u003cp\u003eBatching requests, while reducing total requests, can potentially trigger Operations Per Minute rate limits with large operations against a single account.\u003c/p\u003e\n"],["\u003cp\u003eImplementing client-side rate limiters or using message queues with throttling mechanisms on producers/consumers provide more advanced control over request rates.\u003c/p\u003e\n"]]],[],null,["Rate Limits\n-----------\n\nThe Google Ads API buckets requests for rate limiting by queries per second (QPS) per\nclient customer ID (CID) and developer token, meaning that metering is enforced\nindependently on both CIDs and developer tokens. The Google Ads API\nuses a [Token Bucket](//en.wikipedia.org/wiki/Token_bucket) algorithm to meter requests and determine an\nappropriate QPS limit, so the exact limit will vary depending on the overall\nserver load at any given time.\n\nThe purpose of imposing rate limits is to prevent one user from disrupting\nservice for other users by (either intentionally or unintentionally)\noverwhelming the Google Ads API servers with a high volume of requests.\n\nRequests that are in violation of rate limits will be rejected with the error:\n[`RESOURCE_TEMPORARILY_EXHAUSTED`](/google-ads/api/reference/rpc/v21/QuotaErrorEnum.QuotaError#resource_temporarily_exhausted).\n\nYou can take control of your app and mitigate rate limits by both actively\nreducing the number of requests and throttling QPS from the client side.\n\nThere are a number of ways to reduce the chances of exceeding the rate limit.\nBecoming familiar with [Enterprise Integration Patterns](//www.enterpriseintegrationpatterns.com/patterns/messaging/) (EIP) concepts\nsuch as Messaging, Redelivery, and Throttling can help you build a more robust\nclient app.\n\nThe following recommended practices ordered by complexity, with simpler\nstrategies at the top and more robust but sophisticated architectures after:\n\n- [Limit concurrent tasks](#limit)\n- [Batching requests](#batch)\n- [Throttling and rate limiters](#throttle)\n- [Queueing](#queue)\n\nLimit concurrent tasks\n----------------------\n\nOne root cause of exceeding rate limits is that the client app is spawning an\nexcessive number of parallel tasks. While we don't limit the number of parallel\nrequests a client app can have, this can easily exceed the Requests Per Second\nlimit at the developer token level.\n\nSetting a reasonable upper bound for the total number of concurrent tasks that\nare going to make requests (across all processes and machines), and adjusting\nupward to optimize your throughput without exceeding the rate limit is\nrecommended.\n\nFurthermore, you can consider throttling QPS from the client side (check out\n[Throttling and rate limiters](#throttle)).\n\nBatching requests\n-----------------\n\nConsider batching multiple operations into a single request. This is most\napplicable on `MutateFoo` calls. For example, if you're updating status for\nmultiple instances of [`AdGroupAd`](/google-ads/api/reference/rpc/v21/AdGroupAd) - instead of\ncalling [`MutateAdGroupAds`](/google-ads/api/reference/rpc/v21/AdGroupAdService/MutateAdGroupAds)\nonce for each [`AdGroupAd`](/google-ads/api/reference/rpc/v21/AdGroupAd), you can call\n[`MutateAdGroupAds`](/google-ads/api/reference/rpc/v21/AdGroupAdService/MutateAdGroupAds) once, and\npass in multiple `operations`. Refer to our [batch operations guidance](/google-ads/api/docs/best-practices/overview#batch_operations)\nfor some additional examples.\n\nWhile batching requests reduces the total number of requests and mitigates the\nRequests Per Minute rate limit, it may trigger the Operations Per Minute rate\nlimit if you perform a large number of operations against a single account.\n\nThrottling and rate limiters\n----------------------------\n\nIn addition to limiting the total number of threads in your client application,\nyou can also implement rate limiters on the client side. This can ensure all the\nthreads across your processes and / or clusters are governed by a specific QPS\nlimit from the client side.\n\nYou can check out [Guava Rate Limiter](//github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/RateLimiter.java), or implement your own [Token\nBucket](//en.wikipedia.org/wiki/Token_bucket) based algorithm for a clustered environment. For example, you\ncould generate tokens and store them in a shared transactional storage such as a\ndatabase, and each client would have to acquire and consume a token before it\nprocesses the request. If the tokens were used up, the client would have to wait\nuntil the next batch of tokens is generated.\n\nQueueing\n--------\n\nA message queue is the solution for operation load distribution, while also\ncontrolling request and consumer rates. There are a number of message queue\noptions available---some open source, some proprietary---and many of\nthem can work with different languages.\n\nWhen using message queues, you can have multiple producers pushing messages to\nthe queue and multiple consumers processing those messages. Throttles can be\nimplemented at the consumer side by limiting the number of concurrent consumers,\nor implement rate limiters or throttlers for either the producers or consumers.\n\nFor example, if a message consumer encounters a rates limit error, that consumer\ncan return the request to the queue to be retried. At the same time, that\nconsumer can also notify all other consumers to pause processing for a number of\nseconds to recover from the error."]]
