重試行為 - AWS 軟體開發套件和工具
選擇standard和adaptive重試模式重試模式實作詳細資與 AWS 開發套件的相容性

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

重試行為

重試行為包括有關 SDK 如何嘗試從發出請求而導致的失敗中恢復的設置。 AWS 服務

使用下列項目設定此功能：

max_attempts-共享 AWS config文件設置
AWS_MAX_ATTEMPTS-環境變量
aws.maxAttempts-JVM 系統屬性：僅限爪哇/科特林

指定對請求進行的嘗試次數上限。

預設值：如果未指定此值，則其預設值取決於retry_mode設定值：

  • 如果retry_mode是 legacy — 使用特定於您的 SDK 的默認值（max_attempts默認情況下檢查您的特定 SDK 指南或 SDK 的代碼庫）。

  • 如果retry_mode是 standard — 進行三次嘗試。

  • 如果retry_mode是 adaptive — 進行三次嘗試。

有效值：大於 0 的數字。

retry_mode-共享 AWS config文件設置
AWS_RETRY_MODE-環境變量
aws.retryMode-JVM 系統屬性：僅限爪哇/科特林

指定 SDK 或開發人員工具嘗試重試的方式。

預設值：legacy是預設的重試策略。

有效值：

  • legacy— 特定於您的 SDK（請查看您的特定 SDK 指南或 SDK 的代碼庫）。

  • standard— 跨 AWS SDK 的標準重試規則集。此模式包含重試的一組標準錯誤，並支援重試配額。除非明確設定，否則使用此模式的預設最大嘗試次數max_attempts為三次。

  • adaptive— 實驗性重試模式，其中包含標準模式的功能，但包含自動用戶端節流。由於此模式是實驗性的，因此 future 可能會改變行為。

選擇standard和adaptive重試模式

我們建議您使用standard重試模式，除非您確定您的使用方式更適合adaptive。

注意

此adaptive模式假設您根據後端服務可能會限制要求的範圍來共用用戶端。如果不這樣做，如果您對兩個資源使用相同的用戶端，則一個資源中的節流可能會延遲對不相關資源的請求。

標準 自适应
應用程式使用案例：全部。 應用程序用例：

  1. 對延遲不敏感。

  2. 用戶端只會存取單一資源，或者，您提供的邏輯可依據正在存取的服務資源來分別集區用戶端。
支援斷路，以防止 SDK 在中斷期間重試。 支援斷路，以防止 SDK 在中斷期間重試。
在發生故障時使用抖動的指數輪詢。 使用動態輪詢持續時間來嘗試將失敗的要求數目降到最低，以換取延遲增加的可能性。
永遠不會延遲第一次請求嘗試，只有重試。 可以限制或延遲初始請求嘗試。

如果您選擇使用adaptive模式，您的應用程式必須建構圍繞可能限制的每個資源所設計的用戶端。資源，在這種情況下，比只是思考每一個更精細的調整。 AWS 服務 AWS 服務 可以有額外的維度，它們用來限制請求。讓我們以 Amazon DynamoDB 服務為例。DynamoDB 會使用 AWS 區域 加上正在存取的表格來限制請求。這意味著您的代碼正在訪問的一個表可能比其他表進行限制。如果您的程式碼使用相同的用戶端來存取所有資料表，且對其中一個資料表的要求會受到限制，則調適性重試模式會降低所有資料表的要求率。您的代碼應該被設計為每個 R egion-and-table 對有一個客戶端。如果您在使用adaptive模式時遇到非預期的延遲，請參閱所使用服務的特定 AWS 文件指南。

重試模式實作詳細資

以下是standard和adaptive重試模式的高級偽代碼：

MakeSDKRequest() {
  attempts = 0
  loop {
    GetSendToken()
    response = SendHTTPRequest()
    RequestBookkeeping(response)
    if not Retryable(response)
      return response
    attempts += 1
    if attempts >= MAX_ATTEMPTS:
      return response
    if not HasRetryQuota(response)
      return response
    delay = ExponentialBackoff(attempts)
    sleep(delay)
  }
}

以下是關於偽代碼中使用的組件的更多細節：

GetSendToken:

令牌存儲桶僅在adaptive重試模式下使用。令牌存儲桶通過要求可用令牌以啟動請求來強制執行最大請求率。SDK 客戶端可配置為快速失敗請求或阻止，直到令牌變為可用。

客戶端速率限制是一種算法，最初允許以任何速率發出請求，最高可達令牌限額。但是，在偵測到節流回應之後，用戶端會受到相應 rate-of-request 的限制。如果收到成功的回應，令牌額度也會相應地增加。

使用自適應速率限制，SDK 可以減慢傳送要求的速率，以便更好地容納的 AWS 服務容量。

SendHTTPRequest:

大多數 AWS SDK 使用使用連接池的 HTTP 庫，以便您可以在發出 HTTP 請求時重複使用現有連接。一般而言，由於節流錯誤而重試要求時，會重複使用連線。由於暫時性錯誤而重試時，請求不會重複使用。

RequestBookkeeping:

如果請求成功，則應更新重試配額。僅針對adaptive重試模式，state 變數maxsendrate會根據收到的回應類型進行更新。

Retryable:

此步驟會根據下列項目決定是否可以重試回應：

  • HTTP 狀態碼 。

  • 從服務傳回的錯誤碼。

  • 連接錯誤，定義為 SDK 收到的任何錯誤，其中未收到來自服務的 HTTP 響應。

暫時性錯誤 (HTTP 狀態碼 400、408、500、502、503 和 504) 和節流錯誤 (HTTP 狀態碼 400、403、429、502、503 和 509) 都可能會重試。SDK 重試行為是與服務中的錯誤代碼或其他數據一起確定的。

MAX_ATTEMPTS:

由config檔案設定或環境變數指定。

HasRetryQuota

此步驟通過要求重試配額存儲桶中提供令牌來限制重試請求。重試配額值區是一種機制，可防止不太可能成功的重試。這些配額依賴於 SDK，通常依賴於用戶端，有時甚至依賴於服務端點。當請求因各種原因而失敗時，可用的重試配額令牌將被刪除，並在成功時進行補充。當沒有令牌保留時，重試循環將退出。

ExponentialBackoff

對於可重試的錯誤，會使用截斷的指數輪詢來計算重試延遲。SDK 使用具有抖動的截斷二進制指數輪詢。下列演算法顯示如何針對要求回應定義睡眠的時間量 (以秒為單位)i：

seconds_to_sleep_i = min(b*r^i, MAX_BACKOFF)

在上述演算法中，下列值適用：

b = random number within the range of: 0 <= b <= 1

r = 2

MAX_BACKOFF = 20 seconds適用於大多數 SDK。請參閱您的特定 SDK 指南或原始碼以進行確認。

與 AWS 開發套件的相容性

下列 SDK 支援本主題中描述的功能和設定。注意到任何部分例外情況。和唯一支援任何 JVM 系統屬 AWS SDK for Java 性設 適用於 Kotlin 的 AWS SDK 定。

SDK 支援 備註或更多資訊
AWS CLI v2 是
SDK for C++ 是
適用於轉到 V2 的開發套件 (1.x) 是
適用於 Go 1.x 的開發套件 (V1) 否
適用於 Java 2.x 的開發套件 是
適用於 Java 1.x 的開發套件 是 JVM 系統屬性：使用com.amazonaws.sdk.maxAttempts而不是aws.maxAttempts; 使用com.amazonaws.sdk.retryMode而不是aws.retryMode.
適用於 JavaScript 3.x 的開發套 是
適用於 JavaScript 2.x 的開發套 否 支援最大重試次數、含抖動的指數輪詢，以及重試輪詢的自訂方法選項。
SDK 的科特林 是
適用於 .NET 3.x 的開發套 是
適用於 PHP 3.x 的開發套件 是
SDK for Python (Boto3) 是
適用於紅寶石 3.x 的 SDK 是
適用於鏽蝕的 SDK 是
適用的工具 PowerShell 是