使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
速率限制
Google Ads API 会按每个客户账号的客户 ID (CID) 和开发者令牌的每秒查询次数 (QPS) 对速率限制请求进行分桶处理，这意味着要分别针对 CID 和开发者令牌强制执行计量。Google Ads API 使用令牌桶算法对请求进行计量，并确定适当的 QPS 限制，因此，确切的限制会因任意给定时间的服务器总负载而异。
实施速率限制的目的是防止某个用户有意或无意地发出大量请求，给 Google Ads API 服务器带来过重负担，从而中断其他用户的服务。
违反速率限制的请求将被拒绝，并显示以下错误：RESOURCE_TEMPORARILY_EXHAUSTED。
您可以主动减少请求数和从客户端限制 QPS，以此方式控制您的应用并减缓超出速率限制的情况。
有许多方法可以降低超出速率限制的几率。
掌握各种企业集成模式 (EIP) 概念，如消息传递、重新传递和限流，可帮您开发更强大的客户端应用。
下面列出了一些推荐的做法，排在前面的是比较简单的策略，后面的则是比较强大但复杂的架构：
限制并发任务数
导致速率超限的一个根本原因是客户端应用产生了过多的并行任务。虽然我们不限制客户端应用可以产生多少并行请求，但这样做很容易超出开发者令牌层面的每秒请求数限制。
我们建议对所有进程和机器上将会发送请求的并行任务总数设置合理的上限，并以之为基础向上调整，从而在不超出速率限制的情况下优化吞吐量。
此外，您可以考虑从客户端限制 QPS（请参阅限流和使用速率限制器）。
批处理请求
考虑将多个操作放入单个请求中进行批量处理。这最适用于 MutateFoo 调用。例如，如果您要更新多个 AdGroupAd 实例的状态，则可以调用一次 MutateAdGroupAds 并传入多个 operations，而不是对每个 AdGroupAd 都调用一次 MutateAdGroupAds。MutateAdGroupAds如需了解更多示例，请参阅我们的批量操作指南。
虽然批量发送请求可以减少请求总数，并减缓超出“每分钟请求数”速率限制的情况，但如果您对单个账号执行大量的操作，还是可能会触发“每分钟操作数”速率限制。
限流和使用速率限制器
除了在客户端应用中限制线程总数之外，您还可以在客户端实施速率限制器。这样可确保各进程和 / 或集群中的所有线程都受到客户端指定的 QPS 限制的约束。
您可以试试 Guava 速率限制器，或为集群环境实施自己的基于令牌桶的算法。例如，您可以生成令牌并将其存储在共享事务性存储空间（例如数据库）中，每个客户端都必须先获取并使用令牌，然后才能处理请求。如果令牌用完，客户端必须等到下一批令牌生成。
队列
消息队列是用于分配操作负载的解决方案，同时还可以控制请求和使用者速率。可用的消息队列方案有许多：一些是开源的，一些是专有的，而且其中许多都支持各种不同的语言。
在使用消息队列时，您可以有多个推送消息到队列的生成者和多个处理这些消息的使用者。限流可在使用者一端实施，方法是限制并发使用者的数量，或者为生成者或使用者实施速率限制器或限流器。
例如，如果消息使用者遇到速率限制错误，那么该使用者可以将请求返回到要重试的队列。与此同时，该使用者还可以通知所有其他使用者暂停处理几秒钟，以等待从错误中恢复。
如未另行说明，那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可，并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情，请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-08-27。
[null,null,["最后更新时间 (UTC)：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."]]
