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

# 重試行為
<a name="feature-retry-behavior"></a>

**重要**  
此頁面所述的行為需要選擇加入，直到成為預設行為為止。`AWS_NEW_RETRIES_2026=true` 在您的環境中設定 。如果沒有此設定，您的 SDK 會使用 2026 年之前的重試行為，這在退避時間、重試配額成本和服務特定預設值方面有所不同。如需詳細資訊，請參閱[公告部落格文章](https://aws.amazon.com/blogs/developer/announcing-updated-retry-behavior-for-aws-sdks-and-tools/)。

當請求因暫時性錯誤或限流而 AWS 服務 失敗時，軟體開發套件可以自動重試請求。此頁面說明如何設定重試，以及如何在內部運作。
+ [設定重試](#configuring-retries)：選擇重試模式、設定最大嘗試次數，以及了解組態優先順序。
+ [重試的運作方式](#how-retries-work)：重試流程、錯誤分類、退避公式、重試配額機制和服務特定行為。

## 設定重試
<a name="configuring-retries"></a>

您可以控制開發套件使用的重試策略，以及重試次數。

### 選擇重試模式
<a name="choosing-a-retry-mode"></a>

重試模式會決定 SDK 在請求失敗時的行為。有三種模式可用：**標準**、**適應性和****傳統**。


|  | 標準 | 自適應 | 傳統 | 
| --- | --- | --- | --- | 
| 重試配額 | 是 | 是 | 依 SDK 而異 | 
| 可以延遲初始請求 | 否 | 是 | 否 | 
| Error-type-specific 退避 | 是 | 是 | 依 SDK 而異 | 
| 跨 SDKs標準化 | 是 | 是 | 否 | 
| 建議 | 所有工作負載的預設值 | 單一資源、調節繁重、延遲容錯 | 僅限回溯相容性 | 

#### 標準模式 （預設）
<a name="standard-mode"></a>

標準模式會使用指數退避搭配抖動重試失敗的請求。它會針對暫時性錯誤 （例如網路逾時） 使用較短的延遲，並針對限流錯誤 （例如 ) 使用較長的延遲`ThrottlingException`。

標準模式包含**重試配額**，也就是權杖儲存貯體，可為每個重試扣除權杖，並在請求成功時補充權杖。當可用的字符用盡時，開發套件會傳回錯誤而不重試，因此您的應用程式會快速失敗，而不是等待不太可能成功的重試。這也有助於減少重試流量，以更快的速度解決服務中斷。在正常操作期間，配額會保持完整且沒有作用。重試配額永遠不會延遲或封鎖初始請求。只有重試會受到影響。如需詳細資訊，請參閱[重試配額 （權杖儲存貯體）](#retry-quota-token-bucket)。

除非您有特定理由選擇其他模式，否則請使用標準模式。

#### 自適應模式
<a name="adaptive-mode"></a>

自適應模式包含標準模式中的所有項目，以及**用戶端速率限制器**。速率限制器會追蹤調節回應，並調整 SDK 傳送請求的速率。與標準模式不同，自適應模式可能會在偵測到限流時延遲或封鎖*初始*請求，而不只是重試。

速率限制器會依 SDK 用戶端執行個體運作。來自用戶端的所有請求都會共用相同的速率限制，無論其以哪個 API 操作或資源為目標。

**何時使用自適應模式：**
+ 您的用戶端以單一資源為目標 （例如，一個 DynamoDB 資料表），而且您預期會經常調節回應。這在呼叫大量單一 API 操作的自動化工作流程、批次處理器或 AI 工作負載中很常見。
+ 您希望軟體開發套件在服務發出限流訊號時自動減慢速度。

**不使用自適應模式時：**
+ 您的用戶端會將請求傳送至多個資源或為多個租用戶提供服務。調節一個資源會導致速率限制器拖慢來自該用戶端的所有請求，包括對不受影響資源的請求。
+ 您需要在初始請求時有可預測的延遲。

不建議將自適應模式作為一般預設值。

#### 傳統模式
<a name="legacy-mode"></a>

傳統模式是引進標準模式之前，每個 SDK 使用的重試行為。它不包含標準化的重試配額。某些 SDKs（例如 Java) 在舊版模式中有自己的重試配額實作，但軟體SDKs的行為不一致。如果沒有標準化配額，用戶端會在服務中斷期間繼續以完整速率重試。這會在不太可能成功的請求上連結執行緒和連線，同時新增可能會延遲服務復原的負載。

傳統模式會因 SDKs而異。重試計數、退避計時、可重試錯誤集和限流行為因語言而異。在 SDKs程式碼可能會有不同的行為。

**提供：**Java、Python、Ruby、PHP、C\+\+、CLI

**不適用於：**.NET、Go、Kotlin、Rust、Swift、JavaScript

傳統模式為了回溯相容性而存在。如果您目前使用舊版模式，請切換到標準模式。

### 重試設定
<a name="retry-settings"></a>

下列設定控制重試行為。您可以透過[環境變數](environment-variables.md)、[共用組態檔案 ](file-format.md)(`~/.aws/config`) 或程式碼中的用戶端組態來設定它們。


| 設定 | 它控制的內容 | 環境變數 | Config 檔案金鑰 | 預設 | 
| --- | --- | --- | --- | --- | 
| 重試模式 | 要使用的重試策略 | AWS\_RETRY\_MODE | retry\_mode | standard | 
| 最大嘗試次數 | 嘗試次數總計，包括初始請求 | AWS\_MAX\_ATTEMPTS | max\_attempts | 3 （請參閱備註） | 

的最大嘗試次數值`3`表示 SDK 會提出一個初始請求，最多重試兩次。設定嘗試完全`1`停用重試次數上限。

**注意**  
DynamoDB 和 DynamoDB Streams 用戶端預設為`4`最大嘗試次數。這些服務使用較短的基本退避延遲 (25 毫秒而非 50 毫秒），以符合其低延遲設定檔。額外嘗試可讓最後一次重試的最大退避與其他 服務相當。您可以使用上表中顯示的相同設定來覆寫此項目。

### 組態優先順序
<a name="configuration-precedence"></a>

當您在多個位置指定相同的設定時，軟體開發套件會使用下列優先順序來解析值，從最高到最低：

1. **程式碼中的明確用戶端組態。**直接在 SDK 用戶端或其組態物件上設定的值。

1. **[環境變數](environment-variables.md)。**例如 `AWS_RETRY_MODE` 或 `AWS_MAX_ATTEMPTS`。

1. **[共用組態檔案](file-format.md)。**中的 `retry_mode`或 `max_attempts`金鑰`~/.aws/config`。

1. **SDK 預設。**設定的內建預設值。

這遵循標準 [AWS SDK 組態優先順序](settings-reference.md)。在較高層級設定的值一律會覆寫在較低層級設定的值。例如，如果您在 `retry_mode=standard`中將 `AWS_RETRY_MODE=adaptive`設定為環境變數 和 `~/.aws/config`，則 SDK 會使用自適應模式。

### 語言特定組態
<a name="language-specific-configuration"></a>

此頁面 (`retry_mode` 和 `max_attempts`) 所述的跨 SDK 設定適用於所有 SDKs。不過，在程式碼中設定重試的 API 會因語言而異。如需特定語言組態選項，例如自訂退避策略、其他可重試的錯誤，以及重試配額調校，請參閱開發套件的開發人員指南。

## 重試的運作方式
<a name="how-retries-work"></a>

本節說明 AWS SDKs如何處理失敗的請求：哪些錯誤觸發重試、SDK 在嘗試之間等待多久，以及何時停止重試。

### 請求失敗時會發生什麼情況
<a name="what-happens-when-a-request-fails"></a>

當您透過 AWS SDK 進行 API 呼叫時，軟體開發套件會遵循以下順序：

1. **[僅限自適應模式](#adaptive-mode)：**軟體開發套件會檢查用戶端速率限制器。如果偵測到限流，軟體開發套件可能會在傳送請求之前延遲或封鎖請求。

1. SDK 會將請求傳送至 AWS 服務 端點。

1. 如果服務傳回成功回應，軟體開發套件會將結果傳回至您的程式碼。

1. 如果請求失敗，開發套件會將錯誤分類為*暫時性*、*限流*或*無法重試*。請參閱 [重試哪些錯誤](#which-errors-are-retried)。

1. 如果錯誤無法重試，軟體開發套件會立即將錯誤傳回至您的程式碼。未嘗試重試。

1. 如果錯誤可重試，軟體開發套件會檢查是否已達到最大嘗試次數。若是如此，它會將錯誤傳回至您的程式碼。

1. 軟體開發套件會檢查 [重試配額 （權杖儲存貯體）](#retry-quota-token-bucket)。如果字符預算用盡，軟體開發套件不會重試並將錯誤傳回至您的程式碼。例外狀況：對於 [長輪詢操作](#long-polling-operations)，軟體開發套件仍會在傳回錯誤之前套用退避延遲。

1. SDK 會根據錯誤類型和重試嘗試次數來計算退避延遲。請參閱 [軟體開發套件等待多久](#how-long-does-the-sdk-wait)。

1. SDK 會等待計算的延遲，然後再次從步驟 2 傳送請求。

SDK 會重複此迴圈，直到請求成功、達到嘗試次數上限、耗盡重試配額，或發生無法重試的錯誤為止。整個程序都是自動的。您的應用程式會看到成功回應或最終錯誤。

### 重試哪些錯誤
<a name="which-errors-are-retried"></a>

開發套件會將每個失敗的請求分類為三個類別之一：暫時性、限流或無法重試。此分類會決定 SDK 是否重試請求，以及重試之前的等待時間。

分類是根據服務回應中的**錯誤碼**和 **HTTP 狀態碼**。例如，具有錯誤碼的 HTTP 400 `RequestTimeout` 會分類為暫時性並重試。具有 的 HTTP 400 `ValidationException` 被歸類為不可重試並立即傳回。

#### 錯誤分類
<a name="error-classification"></a>

**暫時性錯誤**會以短暫的基礎延遲 (50 毫秒） 重試：


| 錯誤碼 | 
| --- | 
| RequestTimeout | 
| RequestTimeoutException | 
| InternalError | 
| IDPCommunicationError | 
| I/O 失敗 （連線重設、DNS 解析失敗、通訊端逾時） | 
| （任何沒有可辨識錯誤碼的 HTTP 500、502、503 或 504) | 

**調節錯誤**會以較長的基本延遲 (1，000 毫秒） 重試：


| 錯誤碼 | 
| --- | 
| Throttling | 
| ThrottlingException | 
| ThrottledException | 
| RequestThrottledException | 
| TooManyRequestsException | 
| ProvisionedThroughputExceededException | 
| TransactionInProgressException | 
| LimitExceededException | 
| PriorRequestNotComplete | 
| RequestThrottled | 
| EC2ThrottledException | 
| RequestLimitExceeded | 
| SlowDown | 
| BandwidthLimitExceeded | 

**無法重試的錯誤** （例如 `AccessDeniedException`、`ValidationException`、`ResourceNotFoundException`) 會立即傳回至您的程式碼。

**注意**  
具有調節錯誤碼的 HTTP 5XX 歸類為調節錯誤，而不是暫時性錯誤，即使 5XX 錯誤通常是暫時性的。開發套件會先比對錯誤碼，然後回到 HTTP 狀態碼。

調節錯誤表示服務因為速率限制而主動拒絕您的請求，因此 SDK 在重試之前會等待更長的時間，讓服務有時間復原容量。如需特定延遲，[軟體開發套件等待多久](#how-long-does-the-sdk-wait)請參閱 。

### 軟體開發套件等待多久
<a name="how-long-does-the-sdk-wait"></a>

SDK 使用**指數退避搭配完全抖動**。平均而言，每次重試會等待比上次更久的時間，並隨機分散來自多個用戶端的請求。

#### 依錯誤類型區分的基本延遲
<a name="base-delays-by-error-type"></a>

基本延遲取決於錯誤是暫時性還是限流：


| 錯誤類型 | 基本延遲 | 理由 | 
| --- | --- | --- | 
| 暫時性 （非限流） | 50 毫秒 | 暫時性錯誤通常會在幾毫秒內解決。短暫的基礎延遲可提供快速復原。 | 
| 限流 | 1，000 毫秒 | 服務已限制請求的速率。較長的基本延遲可提供復原容量的時間。 | 

#### 退避公式
<a name="backoff-formula"></a>

SDK 使用此公式計算每個重試延遲：

```
delay = random(0, 1) × min(20,000 ms, base_delay × 2^retry)
```

其中：
+ `random(0, 1)` 傳回介於 0 和 1 之間的均勻分佈值
+ `base_delay` 暫時性錯誤為 50 毫秒，調節錯誤為 1，000 毫秒
+ `retry` 第一次重試時從 0 開始 （第二次整體請求嘗試）

退避上限為 **20 秒**。無論已嘗試多少次，個別延遲都不會超過 20 秒。

#### 工作範例
<a name="worked-examples"></a>

**範例 1：暫時性錯誤，最多嘗試 3 次**


| 步驟 | 發生的情況 | Delay | 
| --- | --- | --- | 
| 嘗試 1 | 初始請求。服務傳回 HTTP 503。 | (無) | 
| 嘗試 2 | SDK 等待 random(0， 50 毫秒）。使用 503 重試失敗。 | 0–50 毫秒 （平均 \~25 毫秒） | 
| 第 3 次嘗試 | SDK 等待 random(0， 100 毫秒）。重試成功。 | 0–100 毫秒 （平均 \~50 毫秒） | 

在兩次重試中新增的總延遲平均約為 75 毫秒。

**範例 2：調節錯誤，最多嘗試 3 次**


| 步驟 | 發生的情況 | Delay | 
| --- | --- | --- | 
| 嘗試 1 | 初始請求。服務傳回 429 Throttling。 | (無) | 
| 嘗試 2 | SDK 等待 random(0， 1，000 毫秒）。重試傳回 429。 | 0–1，000 毫秒 （平均 \~500 毫秒） | 
| 第 3 次嘗試 | SDK 等待 random(0， 2，000 毫秒）。重試成功。 | 0–2，000 毫秒 （平均 \~1，000 毫秒） | 

在兩次重試中新增的總延遲平均約為 1，500 毫秒。

**範例 3：暫時性錯誤，達到退避上限**

基本延遲為 50 毫秒時，上限之前的計算延遲為：


| 重試嘗試 | 運算最大延遲 | 20 秒後上限 | 
| --- | --- | --- | 
| 1 | 50 毫秒 | 50 毫秒 | 
| 2 | 100 毫秒 | 100 毫秒 | 
| 5 | 800 毫秒 | 800 毫秒 | 
| 9 | 12，800 毫秒 | 12，800 毫秒 | 
| 10 | 25，600 毫秒 | 20，000 毫秒 | 

對於暫時性錯誤，上限會在第 10 次重試 （第 11 次嘗試） 時生效。對於基礎為 1，000 毫秒的限流錯誤，上限會在第 6 次重試時生效。

**注意**  
預設值為最多 3 次嘗試 (1 次初始請求 \+ 2 次重試） 時，永遠不會達到退避上限。此資料表說明如果您將 增加`max_attempts`到遠超過預設值，會發生什麼情況。

#### 抖動為何重要
<a name="why-jitter-matters"></a>

隨機乘數稱為*完整抖動*。如果沒有它，同時遇到錯誤的所有用戶端都會同時重試，造成大量的重試流量 (「雷擊雜湊」問題）。完全抖動會將重試均勻分散到整個退避時段，讓服務收到穩定的請求，而不是同步峰值。

例如，假設 1，000 個用戶端都同時收到 503。完整抖動會在 50 毫秒的時段均勻分配其第一次重試，而不是完全在 50 毫秒進行全部 1，000 次重試。

#### 伺服器導向重試計時
<a name="server-directed-retry-timing"></a>

有些 會在錯誤回應中 AWS 服務 包含 `x-amz-retry-after`標頭。標頭值是以毫秒為單位的延遲。出現此標頭時，開發套件會使用伺服器指定的延遲，並固定為計算的退避延遲的最小值，以及計算的退避延遲的最大值加上 5，000 毫秒。由於計算的退避本身限制為 20 秒，因此有效的伺服器導向延遲上限為 25 秒。SDK 不會套用抖動到此值，因為預期服務會抖動。這可讓服務在預期有可用容量時準確通訊。

### 重試配額 （權杖儲存貯體）
<a name="retry-quota-token-bucket"></a>

開發套件會維護內部字符預算，以追蹤成功請求與失敗的比例。當失敗普遍發生時，預算會耗盡，開發套件會直接傳回錯誤。您的應用程式會快速失敗，而不是等待不太可能成功的重試。這也會減少重試流量，協助服務中斷更快地解決。

#### 重試配額的運作方式
<a name="how-the-retry-quota-works"></a>

字符預算開始已滿。每次重試嘗試都會扣除權杖。當重試成功時，軟體開發套件會還原該重試所耗用的字符。當請求在第一次嘗試時成功 （不需要重試），軟體開發套件會還原 1 個字符。當預算達到零時，開發套件會停止重試，並將錯誤直接傳回至您的程式碼。


| 參數 | Value | 
| --- | --- | 
| 預算容量 | 500 個字符 | 
| 每次暫時性 （非限流） 重試的成本 | 14 個字符 | 
| 每次限流重試的成本 | 5 個字符 | 
| 重試後成功還原的字符 | 上次重試所耗用的金額 (14 或 5) | 
| 權杖在成功時還原，無需重試 | 1 個字符 | 

暫時性重試的成本越高，就會反映其不同的失敗模式。500 和連線失敗等暫時性錯誤通常表示整個服務的問題。在這些情況下，持續重試不太可能成功。它會為您的呼叫增加延遲、將用戶端資源綁定起來，並可能延遲每個人的復原。調節錯誤表示服務需要更多時間才能成功請求。軟體開發套件會在重試之間等待更長的時間，以改善成功的可能性。

#### 配額區塊何時重試
<a name="when-does-the-quota-block-retries"></a>

重試配額會隨時追蹤權杖，但只會在預算用盡時封鎖重試。在正常操作期間，幾乎所有請求都會成功，且預算會保持滿載。配額對重試沒有可觀測的影響。

成功重試只會還原自己的字符成本 (14 或 5 個字符），而不是相同請求中先前失敗重試的成本。例如，如果第一次重試失敗且第二次成功，預算會遺失 14 個權杖。當重試耗盡所有嘗試但未成功時，預算會消耗最快，但當請求在成功之前需要多次重試時也會逐漸耗盡。

在預設嘗試次數上限 3 次的情況下，當超過大約 **22%** 的請求導致持續暫時性失敗，或限流錯誤超過大約 **32%** 時，配額會開始耗盡。低於這些速率時，成功的請求會比失敗的重試耗盡預算更快地補充預算。

預算的 500 個權杖開始平衡提供緩衝，可吸收短暫的故障暴增。錯誤短暫激增，即使嚴重，也不會封鎖重試，除非它持續夠長的時間來耗盡緩衝區。

#### 實際影響
<a name="practical-implications"></a>
+ **低失敗率：**配額沒有作用。預算保持在或接近容量。
+ **在服務中斷期間：**如果高百分比的請求在持續期間內失敗，配額會耗盡，且您的用戶端會立即收到錯誤，而不是等待重試。這可減少用戶端延遲、釋放執行緒和連線，並協助服務更快復原。
+ **復原：**當服務復原且請求再次開始成功時，成功重試會還原其完整字符成本，第一次嘗試成功會還原 1 個字符。預算會逐漸重新填入，並自動繼續重試。
+ **範圍：**字符預算通常範圍為單一 SDK 用戶端執行個體。確切範圍可能因 SDK 而異。它不會跨程序或主機共用。

### 服務特定的行為
<a name="service-specific-behavior"></a>

#### DynamoDB
<a name="dynamodb"></a>

DynamoDB 用戶端使用針對 DynamoDB 低延遲設定檔最佳化的調校預設值：


| 設定 | 一般預設 | DynamoDB 預設 | 
| --- | --- | --- | 
| 暫時性 （非調節） 基本延遲 | 50 毫秒 | 25 毫秒 | 
| 調節基本延遲 | 1，000 毫秒 | 1，000 毫秒 | 
| 最大嘗試次數 | 3 | 4 | 

這些預設值同時適用於 Amazon DynamoDB 和 DynamoDB Streams。

#### 長輪詢操作
<a name="long-polling-operations"></a>

某些 AWS 操作使用長輪詢。他們可以保持連線開啟，等待工作到達。這些操作會受到特殊的重試處理：
+ `SQS.ReceiveMessage`
+ `SFN.GetActivityTask`
+ `SWF.PollForActivityTask`
+ `SWF.PollForDecisionTask`

**特殊行為：**當重試配額耗盡且重試遭到封鎖時 ( 中的步驟 7[請求失敗時會發生什麼情況](#what-happens-when-a-request-fails))，軟體開發套件仍會套用退避延遲，再將錯誤傳回至程式碼。

這很重要，因為長輪詢操作通常在緊密迴圈中呼叫。您的程式碼會呼叫 `ReceiveMessage`、處理任何訊息，然後立即`ReceiveMessage`再次呼叫 。如果沒有強制退避，耗盡的字符預算會導致 SDK 在不延遲的情況下傳回錯誤。然後，您的輪詢迴圈會立即傳送下一個請求、激增用戶端 CPU 用量並產生額外的流量。強制退避延遲會中斷此週期，讓用戶端資源用量和輪詢速率在失敗期間保持可管理。

## 支援 AWS SDKs和工具
<a name="feature-retry-behavior-sdk-compat"></a>

下表列出每個 SDK 中更新的重試行為的可用性。如需開發套件特定的詳細資訊，包括最低版本、before-and-after預設值和程式碼範例，請參閱 GitHub 追蹤問題。


| SDK | 支援 | GitHub 追蹤問題 | 
| --- | --- | --- | 
| [適用於 Java 的 SDK 2.x](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/) | 是 | [追蹤問題](https://github.com/aws/aws-sdk-java-v2/discussions/6984) | 
| [適用於 Python 的 SDK (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html) | 是 | [追蹤問題](https://github.com/boto/boto3/discussions/4789) | 
| [適用於 .NET 4.x 的 SDK](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/) | 是 | [追蹤問題](https://github.com/aws/aws-sdk-net/issues/4411) | 
| [PowerShell V5 的工具](https://docs.aws.amazon.com/powershell/latest/userguide/) | 是 | [追蹤問題](https://github.com/aws/aws-tools-for-powershell/issues/418) | 
| [適用於 JavaScript 3.x 的 SDK](https://docs.aws.amazon.com/sdk-for-javascript/latest/developer-guide/) | 是 | [追蹤問題](https://github.com/aws/aws-sdk-js-v3/issues/8037) | 
| [適用於 PHP 的 SDK 3.x](https://docs.aws.amazon.com/sdk-for-php/latest/developer-guide/) | 是 | [追蹤問題](https://github.com/aws/aws-sdk-php/discussions/3285) | 
| [適用於 Kotlin 的 SDK](https://docs.aws.amazon.com/sdk-for-kotlin/latest/developer-guide/) | 是 | [追蹤問題](https://github.com/aws/aws-sdk-kotlin/discussions/1885) | 
| [適用於 Rust 的 SDK](https://docs.aws.amazon.com/sdk-for-rust/latest/dg/) | 是 | [追蹤問題](https://github.com/awslabs/aws-sdk-rust/discussions/1431) | 
| [適用於 Swift 的 SDK](https://docs.aws.amazon.com/sdk-for-swift/latest/developer-guide/) | 請參閱追蹤問題 | [追蹤問題](https://github.com/awslabs/aws-sdk-swift/discussions/2166) | 
| [適用於 Ruby 的 SDK 3.x](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/) | 請參閱追蹤問題 | [追蹤問題](https://github.com/aws/aws-sdk-ruby/discussions/3390) | 
| [適用於 Go V2 的 SDK (1.x)](https://docs.aws.amazon.com/sdk-for-go/v2/developer-guide/) | 請參閱追蹤問題 | [追蹤問題](https://github.com/aws/aws-sdk-go-v2/issues/3416) | 
| [適用於 C\+\+ 的 SDK](https://docs.aws.amazon.com/sdk-for-cpp/latest/developer-guide/) | 請參閱追蹤問題 | [追蹤問題](https://github.com/aws/aws-sdk-cpp/issues/3832) | 
| [AWS CLI  ](https://docs.aws.amazon.com/cli/latest/userguide/) v2 | 請參閱追蹤問題 | [追蹤問題](https://github.com/aws/aws-cli/discussions/10329) |