用量限制和配額
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
設定限制和配額後,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 控制台的「配額」頁面主動提出配額調整要求。
如要進一步瞭解相關內容,請參閱下列資源:
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間:2025-03-25 (世界標準時間)。
[null,null,["上次更新時間: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)"]]