重試失敗的要求

本頁面說明重試對 Identity and Access Management (IAM) API 提出的失敗要求時，應採取的最佳做法。

對於可安全重試的要求，建議使用部分指數輪詢，並導入隨機延遲。

部分指數輪詢總覽

對 IAM API 提出的要求可能會成功或失敗。如果應用程式在未等待的情況下重試失敗的要求，可能會在短時間內向 IAM 傳送大量重試要求。因此，您可能會超出配額和限制，而這些配額和限制適用於 Google Cloud 專案中的每個 IAM 資源。

為避免觸發這個問題，我們強烈建議您使用部分指數輪詢，並導入隨機延遲，這是網路應用程式的標準錯誤處理策略。採用這種方法時，用戶端會定期重試失敗的要求，並以指數方式增加每次重試之間的延遲時間。重試之間也會加入隨機延遲時間 (稱為抖動)，這項隨機延遲有助於避免多個用戶端同步重試，也就是所謂的雷鳴群效應問題。

指數輪詢演算法

下列演算法會實作指數輪詢，並加入隨機延遲：

1. 將要求傳送至 IAM。
2. 如果要求失敗，請等待 1 + random-fraction 秒後再重試要求。
3. 如果要求失敗，請等待 2 + random-fraction 秒後再重試要求。
4. 如果要求失敗，請等待 4 + random-fraction 秒後再重試要求。
5. 繼續這個模式，每次重試後等待 2ⁿ + random-fraction 秒，最多重試 maximum-backoff 次。
6. deadline 秒後，停止重試要求。

實作演算法時，請使用下列值：

• 每次重試前，等待時間為 min((2n + random-fraction), maximum-backoff)，其中 n 從 0 開始，每次重試時會增加 1。
• 將 random-fraction 改為小於或等於 1 的隨機分數值。每次重試時使用不同的值。加入這個隨機值可避免用戶端同步處理，並同時傳送大量重試要求。
• 將 maximum-backoff 取代為重試間等待時間上限 (以秒為單位)。一般值為 32 或 64 (2⁵ 或 2⁶) 秒。請選擇最適合您用途的值。
• 將 deadline 改成持續傳送重試要求的秒數上限。選擇反映您用途的值。舉例來說，在時間敏感度不高的持續整合/持續部署 (CI/CD) 管道中，您可以將 deadline 設為 300 秒 (5 分鐘)。

可重試的錯誤類型

如果 IAM API 的所有要求傳回錯誤代碼 500、502、503 或 504，請使用這項重試策略。

您也可以選擇將這項重試策略用於 IAM API 的要求，這些要求會傳回 404 錯誤代碼。IAM 讀取作業最終會保持一致，因此資源可能不會在建立後立即顯示，這可能會導致 404 錯誤。

此外，對於傳回錯誤代碼 409 和狀態 ABORTED 的所有 IAM API 要求，請使用這個重試策略的修改版本。這類錯誤表示發生並行問題。舉例來說，您可能嘗試更新另一個用戶端已覆寫的允許政策。發生這類錯誤時，您應一律重試整個讀取 - 修改 - 寫入系列要求，並使用部分指數輪詢和引入的抖動。如果只重試寫入作業，要求仍會失敗。

後續步驟

• 瞭解如何透過允許政策管理並行問題。
• 瞭解如何導入「讀取 - 修改 - 寫入」模式，更新允許政策。