用量限制

由於 Google Chat API 屬於共用服務,因此我們會套用配額與限制,確保所有使用者都能公平使用這項服務,並保護 Google Workspace 的整體效能。

如果超出配額,您會收到 429: Too many requests HTTP 狀態碼回應。在 Chat 後端進行額外檢查頻率限制時,也可能會產生相同的錯誤回應。如果發生此錯誤,您應使用指數輪詢演算法,並稍後再試。只要超出下表所列的每分鐘配額,每天可提出的要求數量就沒有上限。

Chat API 方法有兩種:每個空間和每項專案的配額。

每空間配額

個別空間配額會限制指定空間中的查詢頻率,且會在該聊天室中呼叫列出的 Chat API 方法。

下表詳細列出每個聊天室的查詢限制:

每個空間配額

Chat API 方法

上限 (每 60 秒,聊天室內所有 Chat 應用程式會共用
)

每分鐘讀取數

media.download

spaces.get

spaces.members.get

spaces.members.list

spaces.messages.get

spaces.messages.list

spaces.messages.attachments.get

spaces.messages.reactions.list

900

每分鐘寫入數

media.upload

spaces.delete

spaces.patch

spaces.messages.create (也適用於傳入的 Webhook)

spaces.messages.delete

spaces.messages.patch

spaces.messages.reactions.create

spaces.messages.reactions.delete

60

每項專案的配額

每項專案配額都會限制 Google Cloud 專案的查詢頻率,因此會套用至單一 Chat 應用程式,針對每項配額呼叫指定的 Chat API 方法。

下表詳細列出每個專案的查詢限制。您也可以在「配額」頁面找到這些限制。

每項專案的配額

Chat API 方法

上限 (每 60 秒)

每分鐘訊息寫入次數

spaces.messages.create

spaces.messages.patch

spaces.messages.delete

3000

每分鐘訊息讀取數

spaces.messages.get

spaces.messages.list

3000

每分鐘成員寫入次數

spaces.members.create

spaces.members.delete

300

每分鐘會員讀取數

spaces.members.get

spaces.members.list

3000

每分鐘的聊天室寫入次數

spaces.setup

spaces.create

spaces.patch

spaces.delete

60

每分鐘的聊天室讀取數

spaces.get

spaces.list

spaces.findDirectMessage

3000

附件每分鐘寫入次數

media.upload

600

附件每分鐘讀取數

spaces.messages.attachments.get

media.download

3000

回應寫入頻率 (每分鐘)

spaces.messages.reactions.create

spaces.messages.reactions.delete

600

回應讀取數 (每分鐘)

spaces.messages.reactions.list

3000

額外用量限制

使用 spaces.createspaces.setup 方法建立 GROUP_CHATSPACE 類型的聊天室時,還有更多配額限制。每分鐘建立少於 35 個空格,且這類類型每小時建立 210 個空格。DIRECT_MESSAGE 類型的聊天室不適用這些額外的配額限制。

針對指定相同空間的任何 API,每秒進行大型查詢 (QPS) 可能會觸發其他內部限制,而「配額」頁面不會顯示這些限制。

解決以時間為基礎的配額錯誤

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

指數輪詢是網路應用程式的標準錯誤處理策略。 指數輪詢演算法會以指數方式逐漸增加要求之間的等待時間,並以指數方式重試要求,最多可達輪詢時間上限。如果要求還是失敗,請務必在要求成功前延長要求之間的延遲時間。

演算法範例

指數輪詢演算法會以指數方式重試要求,並增加重試之間的等待時間,最多可達輪詢時間上限。例如:

  1. 向 Google Chat 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 控制台的「配額」頁面主動提出配額調整要求

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