部分指數輪詢

部分指數輪詢是網路應用程式的標準錯誤處理策略,用戶端會定期重試失敗的要求,同時逐漸增加每次要求之間的延遲時間。針對所有傳送給 Cloud Storage 用戶端且會回傳 HTTP 5xx429 回應碼的要求 (包含上傳及下載資料/中繼資料),用戶端皆應使用部分指數輪詢。

如果您正在進行下列作業,請務必要清楚瞭解部分指數輪詢的運作方式:

如果您目前使用 Google Cloud Platform Console,主控台會代表您向 Cloud Storage 傳送要求並處理所有必要的輪詢。

演算法範例

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

  1. 向 Cloud Storage 送出要求。

  2. 如果要求失敗,請等待 1 + random_number_milliseconds 秒後再重試要求。

  3. 如果要求失敗,請等待 2 + random_number_milliseconds 秒後再重試要求。

  4. 如果要求失敗,請等待 4 + random_number_milliseconds 秒後再重試要求。

  5. 依此類推,時間上限為 maximum_backoff

  6. 繼續等待和重試,直到重試次數達特定上限,但不再增加每次重試之間的等待時間。

其中:

  • 等待時間為 (((2^n)+random_number_milliseconds), maximum_backoff), 會在每次疊代 (要求) 時增加 1。

  • random_number_milliseconds 是小於或等於 1000 的隨機毫秒數。這種設定有助於避免多個用戶端在特定情況下全部同步進行處理並同時重試,導致同步傳送每一波要求。random_number_milliseconds 的值會在每次重試要求後重新計算。

  • maximum_backoff 通常是 32 或 64 秒,適合的值視用途而異。

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

用戶端每次的重試等待時間和重試次數,應視用途及您的網路狀況而定。舉例來說,比起桌面用戶端,同一應用程式的行動用戶端可能需要更多重試次數,且重試等待時間也需拉長。

如果超過 maximum_backoff 時間上限以及任何允許的額外重試時間後,重試要求仍舊失敗,請使用支援與說明部分列出的任一方法回報或記錄錯誤。

實作範例

搭配 Cloud Storage 使用的部分指數輪詢範例包括:

  • 可續傳上傳作業適用的 boto 範例

  • 使用 Java 或 Python 在 Storage 移轉服務內重試要求。

  • 使用指數輪詢處理 JSON API 上傳錯誤。

  • 在 Cloud Storage 使用指數輪詢,向通知訂閱者傳送物件變更通知

可搭配 Cloud Storage 在用戶端程式庫實作的輪詢範例包含:

  • 針對 Python 重試程式庫

  • Node.js 適用的 Google Cloud 用戶端程式庫可自動使用輪詢策略,重試具有 autoRetry 參數的要求。

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Cloud Storage
需要協助嗎?請前往我們的支援網頁