用量限额和配额
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
限制和配额可保护 Google 基础架构免受以不当方式使用 Alert Center API 的自动化流程的危害。从某个 API 发出过多请求可能是由无害的拼写错误所致，也可能是由于系统设计效率低下、进行不必要的 API 调用所致。无论是什么原因，在来自特定来源的流量达到特定水平后，您都必须将其屏蔽，这样才能保证 Google Workspace 系统的整体健康状况。它可以确保一个开发者的行为不会对更广泛的社区产生负面影响。
在极少数情况下，如果您的 API 请求失败，您会收到 HTTP 状态代码响应。状态代码 403 包含与输入不正确相关的错误信息，而 HTTP 状态代码 503 包含错误信息，指明超出了哪些 API 配额。这些响应可让您的自定义应用检测这些错误并采取适当措施。
如果您需要在固定时间段内完成请求，请在 Java 或 C# 应用中并行发送请求或使用多个线程。并行请求的一个示例是请求来自不同用户的小批量电子邮件，而不是同时向一个用户添加或移除大量电子邮件。如果是会话串，请尝试从 10 个会话开始，每个用户电子邮件一个会话串。请注意，线程建议需要权衡利弊，并且并不适用于所有 API 情况。如果请求数量过多，则会出现配额错误。
对于基于时间的所有错误（每个线程 N 秒最多 N 秒的错误），尤其是 503 状态代码错误，我们建议您的代码捕获异常，并使用指数退避算法算法，等待一小段延迟后再重试失败的调用。一个线程的 Alert Center API 示例是等待 5 秒，然后重试失败的调用。如果请求成功，则对其他线程重复此模式。如果第二个请求未成功，您的应用应缩减请求频率，直到调用成功为止。例如，将最初的 5 秒延迟增加到 10 秒，然后再次重试失败的呼叫。此外，还需决定重试限制。例如，在您的应用向用户返回错误之前，使用不同的延迟时间重试请求 5 到 7 次。
| API 限制类别 |
限制 |
| 提醒中心 QPS 和 QPD 速率 |
该 API 会限制 API 控制台项目的请求数。该 API 项目的每秒请求数（项目 QPS）上限为 1000。此外，每位用户每秒的请求次数（用户 QPS）上限为 150。
如果超出这些限制，服务器将返回 HTTP 503 状态代码。重试请求时请使用指数退避算法算法。
|
| 其他类型的限制 |
限制和准则 |
| 数据格式，默认 |
默认数据格式为 JSON。
|
| 未经授权的请求 |
Google 不允许向此 API 发出未经授权的请求。如果未提供授权令牌，请求会被视为未授权。如需了解详情，请参阅为请求授权。 |
申请增加每个项目的配额
根据项目的资源用量，您可能需要申请增加配额。系统会将服务帐号执行的 API 调用视为使用单个帐号。申请增加配额并不保证一定会获得批准。大型配额增加可能需要更长时间才能获得批准。
并非所有项目的配额都完全相同。随着您越来越多地使用 Google Cloud，您的配额可能需要增加。如果您预计自己的用量即将显著增加，可以在 Google Cloud 控制台的“配额”页面中主动申请调整配额。
如需了解详情，请参阅以下资源：
如未另行说明，那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可，并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情，请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-03-25。
[null,null,["最后更新时间 (UTC)：2025-03-25。"],[],[],null,["# Usage limits and quotas\n\nLimits and quotas protect the Google infrastructure from an automated process that uses the Alert Center API in an inappropriate way. Excessive requests from an API might result from a harmless typo, or might result from an inefficiently designed system that makes needless API calls. Regardless of the cause, blocking traffic from a specific source once it reaches a certain level is necessary for the overall health of the Google Workspace system. It ensures that one developer's actions cannot negatively impact the larger community.\n\nIn the unlikely event that your API request fails, you'll receive an HTTP status code response. A status code of `403` has error information about incorrect input and an HTTP status code of `503` has error information indicating which API quotas have been exceeded. These responses allow your custom application to detect these errors and take appropriate action.\n\nIf your requests need to be completed in a fixed period of time, send your requests in parallel or use multiple threads in your Java or C# application. An example of parallel requests is requesting small batches of emails from different users rather than adding or removing lots of emails from one user simultaneously. In the case of threads, try starting with 10 threads, one thread per user email. Note, the thread recommendation has trade-offs and is not useful for all API situations. If the number of requests gets too high, quota errors will occur.\n\nFor all errors that are time based (maximum of \u003cvar translate=\"no\"\u003eN\u003c/var\u003e things for \u003cvar translate=\"no\"\u003eN\u003c/var\u003e seconds per thread), especially the 503 status code errors, we recommend your code catch the exception and, using an [exponential backoff](http://wikipedia.org/wiki/Truncated_binary_exponential_backoff) algorithm, wait for a small delay before retrying the failed call. A Alert Center API example for one thread is to wait 5 seconds and retry the failed call. If the request is successful, repeat this pattern for the other threads. If the second request is not successful, your application should scale back on the frequency of the request until a call is successful. For example, increase the initial 5 second delay to 10 seconds and retry your failed call again. Also, decide on a retry limit. For example retry a request 5 to 7 times with different delay times before your application returns an error to the user.\n\n| API Limit Categories | Limits |\n|--------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Alert Center QPS and QPD rates | The API limits the number of requests for your APIs Console project. The API project's maximum number of requests per second (project QPS) is 1000. And, the maximum number of requests per user per second (user QPS) is 150. If these limits are exceeded, the server returns an HTTP `503` status code. Use the [exponential backoff](http://wikipedia.org/wiki/Truncated_binary_exponential_backoff) algorithm when retrying your requests. |\n\n\n| Other Types of Limits | Limitations and Guidelines |\n|-----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Data format, default | The default data format is JSON. |\n| Unauthorized requests | Google does not allow unauthorized requests to this API. A request is considered unauthorized if no authorization token is provided. For more information, see [Authorizing requests](/workspace/admin/alertcenter/guides/authorizing). |\n\nRequest a per-project 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)"]]
