重試策略

本頁面說明重試 Model Armor API 要求失敗的最佳做法。

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

截斷指數輪詢總覽

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

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

指數輪詢演算法

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

1. 向 Model Armor 傳送要求。
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 分鐘)。

可重試的錯誤類型

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

如果對 Model Armor API 的要求傳回錯誤代碼 429，您也可以選擇使用這項重試策略。