用量限制

由於 Drive 標籤 API 是共用服務,我們會套用配額和限制,確保所有使用者都能公平使用,並保護 Google Workspace 生態系統的整體健康狀況。

如果您超出配額,通常會收到 429: Too many requests HTTP 狀態碼回應。如果發生這種情況,您應使用指數輪詢演算法,並稍後再試。只要您維持在下列每分鐘配額內,每天可提出的要求次數就沒有上限。

下表詳細說明要求限制:

配額
讀取要求數
每位使用者每項專案 600 (每秒查詢次數)
寫入要求數
每位使用者每項專案 300 (每秒查詢次數)

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

針對所有時間相關錯誤 (每 X 分鐘最多 N 個要求),建議您在程式碼中擷取例外狀況,並使用截斷的指數型延遲,確保裝置不會產生過多負載。

指數輪詢是網路應用程式的標準錯誤處理策略。指數輪詢演算法會以指數方式逐漸增加每次重試之間的等待時間,直到達到最大輪詢時間為止。如果要求仍無法成功,請務必讓要求之間的延遲時間隨著時間增加,直到要求成功為止。

演算法範例

指數輪詢演算法會以指數方式重試要求,並將每次重試之間的等待時間逐漸增加至最大輪詢時間,例如:

  1. 向 Drive Labels 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 的隨機毫秒數。這種設定有助於避免多個用戶端在特定情況下全部同步進行處理並同時重試,導致同步傳送每一波要求。random_number_milliseconds 的值會在每次重試要求後重新計算。
  • maximum_backoff 通常是 32 或 64 秒,適合的值視用途而異。

重試達到 maximum_backoff 時間上限後,用戶端可以繼續重試。但接下來的重試工作就不需繼續增加輪詢時間。舉例來說,如果用戶端使用的 maximum_backoff 時間上限是 64 秒,達到這個值之後,用戶端就可以維持在每 64 秒重試一次的頻率。到了特定時間點後,用戶端應停止無限重試。

重試之間的等待時間和重試次數,取決於您的用途和網路狀況。

定價

使用 Drive Labels API 完全免費。超出配額要求上限不會產生額外費用,也不會向您的帳戶收費。

申請提高配額

視專案的資源使用情形而定,您可能會想要求增加配額。服務帳戶的 API 呼叫會被視為使用單一帳戶。我們不保證一定能核准您提出的配額增加要求。不過如要增加大量配額,可能會需要較長的核准程序處理時間。

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

如要進一步瞭解相關內容,請參閱下列資源: