用量限制

Google Workspace Events API 是一項共用服務，因此我們設有配額與限制，以確保所有使用者都能合理使用這項服務，並維護 Google Workspace 的整體效能。

如果超過配額，您會收到 429: Too many requests HTTP 狀態碼回應。Google Workspace Events API 後端的其他頻率限制檢查可能也會產生相同的錯誤回應。如果發生此錯誤，您應使用指數輪詢演算法，並稍後再試一次。只要不超過下表列出的每分鐘配額，您每日可發出的要求數量沒有限制。

每項專案的配額

每項專案的配額都會限制 Google Cloud 專案的查詢頻率，因此適用於呼叫每個配額指定 Google Workspace Events API 方法的單一應用程式。

下表詳細列出每項專案的查詢限制。您也可以在 Google Cloud 控制台的「配額」頁面中查看這些限制。

每項專案的配額

Google Workspace Events API 方法

限制

每分鐘寫入數

Subscriptions.create

Subscriptions.patch

Subscriptions.delete

Subscriptions.reactivate

600

每位使用者每分鐘寫入數

Subscriptions.create

Subscriptions.patch

Subscriptions.delete

Subscriptions.reactivate

100

每分鐘讀取數

Subscriptions.get

Subscriptions.list

600

每位使用者每分鐘讀取數

Subscriptions.get

Subscriptions.list

100

解決以時間為準的配額錯誤

如果是以時間為準的錯誤 (每 X 分鐘最多 N 個要求)，我們建議您讓程式碼擷取例外狀況，並使用經過截斷的指數輪詢，確保裝置不會產生過多負載。

指數輪詢是網路應用程式的標準錯誤處理策略。指數輪詢演算法會以指數方式逐漸增加要求之間的等待時間來重試要求，最多可達輪詢時間上限。如果要求還是失敗，則要求之間的延遲時間會隨著時間增加，直到要求成功為止。

演算法範例

指數輪詢演算法會以指數方式重試要求，並將每次重試之間的等待時間增加到最長輪詢時間。例如：

  1. 向 Google Workspace Events API 提出要求。
  2. 如果要求失敗，請等待 1 + random_number_milliseconds，然後重試要求。
  3. 如果要求失敗，請等待 2 + random_number_milliseconds，然後重試要求。
  4. 如果要求失敗，請等待 4 + random_number_milliseconds，然後重試要求。
  5. 依此類推，時間上限為 maximum_backoff。
  6. 繼續等待和重試，直到重試次數上限，但不要增加每次重試的等待時間。

其中：

  • 等待時間為 min(((2^n)+random_number_milliseconds), maximum_backoff)，每次疊代 (要求) 時，n 會增加 1。
  • random_number_milliseconds 是小於或等於 1,000 的隨機毫秒數。這有助於避免多個用戶端在特定情況下同步處理並同時重試，避免在同步的 Wave 中傳送要求。random_number_milliseconds 的值會在每次重試要求後重新計算。
  • maximum_backoff 通常是 32 或 64 秒，適當的值會因用途而異。

用戶端可以在達到 maximum_backoff 時間後繼續重試。之後重試時就不必繼續增加輪詢時間。舉例來說，如果用戶端使用的 maximum_backoff 時間為 64 秒，則達到這個值之後，用戶端可以每 64 秒重試一次。在某些情況下，用戶端應禁止無限期重試。

重試的等待時間和重試次數須視用途和網路狀況而定。

要求增加個別專案的配額

視專案的資源用量而定，您可能會想要申請提高配額。服務帳戶的 API 呼叫將視為使用單一帳戶。我們不保證一定能核准您提出的配額增加要求。大量增加配額的要求可能需要較長時間才能通過核准。

並非所有專案的配額都相同。隨著 Google Cloud 的使用時間逐漸增加，配額可能也必須提高。如果您預期用量將大幅攀升，可以透過 Google Cloud 控制台的「配額」頁面主動要求調整配額。

詳情請參閱下列資源：