用量限额
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
由于 Google Sheets API 是一项共享服务,因此我们会设置配额和限制
以确保所有用户都能公平使用它,并保护整个
Google Workspace 系统的运行状况。
如果超过了配额,
429: Too many requests
HTTP 状态代码响应。如果发生这种情况,您应该使用
指数退避算法,然后重试
。只要您不超出下面的每分钟配额,
限制您每天可发出的请求数
下表详细说明了请求限制:
配额 |
读请求次数 |
每个项目每分钟 |
3000 |
每个项目每个用户每分钟 |
600 |
|
高开销读取请求
(用于 presentations.pages.getThumbnail 请求。)
|
每个项目每分钟 |
300 |
每个项目每个用户每分钟 |
60 |
|
写请求次数 |
每个项目每分钟 |
600 |
每个项目每个用户每分钟 |
60 |
|
解决基于时间的配额错误
对于所有基于时间的错误(每 X 分钟最多 N 次请求),我们建议
代码会捕获异常并使用截断的指数退避算法来确保
设备不会产生过多的负载。
指数退避算法是网络应用的标准错误处理策略。一个
指数退避算法使用呈指数增加的等待时间重试请求
最长退避时间。如果请求仍未成功
需要注意的是,请求之间的延迟时间会随着时间的推移不断增加,直到请求成功为止。
示例算法
指数退避算法以指数方式重试请求,增加了等待时间
直至达到最长退避时间。例如:
- 向 GoogleSlides API 发出请求。
- 如果请求失败,等待 1 +
random_number_milliseconds
,然后重试
请求。
- 如果请求失败,等待 2 +
random_number_milliseconds
,然后重试
请求。
- 如果请求失败,等待 4 +
random_number_milliseconds
,然后重试
请求。
- 依此类推,等待时间上限为
maximum_backoff
。
- 继续等待并重试,直至达到重试次数上限,但不增加等待时间
两次重试之间的间隔时间。
其中:
- 等待时间为
min(((2^n)+random_number_milliseconds), maximum_backoff)
。
每次迭代(请求)时,n
递增 1。
random_number_milliseconds
是一个小于 或 的随机毫秒数
等于 1,000。这有助于避免出现许多客户端
都会同时重试,同时发送请求
波次。每次更新后,系统会重新计算 random_number_milliseconds
的值
重试请求。
maximum_backoff
通常为 32 或 64 秒。适当的值
具体取决于应用场景
在达到 maximum_backoff
次数后,客户端可以继续重试。
此后执行的重试不需要继续增加退避时间。对于
例如,如果客户端使用的 maximum_backoff
时间为 64 秒,那么在达到
则客户端可以每 64 秒重试一次。在某个时间点
应防止客户端无限期重试。
重试之间的等待时间和重试次数取决于您的使用场景
和网络状况
价格
对 Google Sheets API 的所有使用均无需额外付费。超出配额
请求限制不会产生额外费用,也不会对您的账号收取费用。
申请增加配额
根据您的项目的资源用量,您可能需要申请配额
增加。由服务账号进行的 API 调用会被视为使用
一个账号。我们无法保证您的增加配额请求一定会得到批准。大
增加配额可能需要更长时间才能获得批准。
并非所有项目的配额都完全相同。随着您越来越多地使用 Google Cloud,
您的配额可能需要增加。如果您预计
您可以主动
申请配额调整
在“配额”页面中
Google Cloud 控制台中。
如需了解详情,请参阅以下资源:
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-03-21。
[null,null,["最后更新时间 (UTC):2025-03-21。"],[],[],null,["# Usage limits\n\nAs the Google Slides API is a shared service, we apply quotas and limitations\nto make sure it's used fairly by all users and to protect the overall\nhealth of the Google Workspace system.\n\n\nIf you exceed a quota, you'll generally receive a\n`429: Too many requests`\nHTTP status code response. If this happens, you should use an\n[exponential backoff algorithm](#exponential) and try again\nlater. Provided you stay within the per-minute quotas below, there's no\nlimit to the number of requests you can make per day.\n\nThe following table details the request limits:\n\n| Quotas ||\n|---------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------|\n| Read requests | |---------------------------------|------| | Per minute per project | 3000 | | Per minute per user per project | 600 | |\n| Expensive read requests (Used for `presentations.pages.getThumbnail` requests.) | |---------------------------------|-----| | Per minute per project | 300 | | Per minute per user per project | 60 | |\n| Write requests | |---------------------------------|-----| | Per minute per project | 600 | | Per minute per user per project | 60 | |\n\nResolve time-based quota errors\n-------------------------------\n\n\nFor all time-based errors (maximum of N requests per X minutes), we recommend\nyour code catches the exception and uses a *truncated exponential backoff* to make sure your\ndevices don't generate excessive load.\n\n\nExponential backoff is a standard error handling strategy for network applications. An\nexponential backoff algorithm retries requests using exponentially increasing wait times\nbetween requests, up to a maximum backoff time. If requests are still unsuccessful, it's\nimportant that the delays between requests increase over time until the request is successful.\n\n### Example algorithm\n\n\nAn exponential backoff algorithm retries requests exponentially, increasing the wait time\nbetween retries up to a maximum backoff time. For example:\n\n1. Make a request to Google Slides API.\n2. If the request fails, wait 1 + `random_number_milliseconds` and retry the request.\n3. If the request fails, wait 2 + `random_number_milliseconds` and retry the request.\n4. If the request fails, wait 4 + `random_number_milliseconds` and retry the request.\n5. And so on, up to a `maximum_backoff` time.\n6. Continue waiting and retrying up to some maximum number of retries, but don't increase the wait period between retries.\n\n\nwhere:\n\n- The wait time is `min(((2^n)+random_number_milliseconds), maximum_backoff)`, with `n` incremented by 1 for each iteration (request).\n- `random_number_milliseconds` is a random number of milliseconds less than or equal to 1,000. This helps to avoid cases in which many clients are synchronized by some situation and all retry at once, sending requests in synchronized waves. The value of `random_number_milliseconds` is recalculated after each retry request.\n- `maximum_backoff` is typically 32 or 64 seconds. The appropriate value depends on the use case.\n\n\nThe client can continue retrying after it has reached the `maximum_backoff` time.\nRetries after this point don't need to continue increasing backoff time. For\nexample, if a client uses a `maximum_backoff` time of 64 seconds, then after reaching\nthis value, the client can retry every 64 seconds. At some point,\nclients should be prevented from retrying indefinitely.\n\n\nThe wait time between retries and the number of retries depend on your use case\nand network conditions.\n\nPricing\n-------\n\n\nAll use of the Google Slides API is available at no additional cost. Exceeding the quota\nrequest limits doesn't incur extra charges and your account is not billed.\n\nRequest a quota increase\n------------------------\n\n\nDepending on your project's resource usage, you might want to request a quota\nadjustment. API calls by a service account are considered to be using a\nsingle account. Applying for an adjusted quota doesn't guarantee approval. Quota adjustment\nrequests that would significantly increase the quota value can take longer to be approved.\n\n\nNot all projects have the same quotas. As you increasingly use Google Cloud over\ntime, your quota values might need to increase. If you expect a notable upcoming\nincrease in usage, you can proactively\n[request quota adjustments](https://cloud.google.com/docs/quota#requesting_higher_quota)\nfrom the [Quotas page](https://console.cloud.google.com/iam-admin/quotas)\nin the Google Cloud console.\n\nTo learn more, see the following resources:\n\n- [About quota adjustments](https://cloud.google.com/docs/quotas/overview#about_increase_requests)\n- [View your current quota usage and limits](https://cloud.google.com/docs/quota#viewing_your_quota_console)\n- [Request a higher quota limit](https://cloud.google.com/docs/quota#requesting_higher_quota)"]]