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

# 限流診斷
<a name="throttling-diagnosing-workflow"></a>

當應用程式發生限流時，DynamoDB 會提供詳細例外狀況資訊與對應的 CloudWatch 指標，協助您進行診斷。

本節說明如何以系統化方式了解 DynamoDB 應用程式中的限流事件。說明如何解譯限流例外狀況，並將其與 CloudWatch 指標關聯，以獲得更深入的洞察，進而了解可減少 DynamoDB 限流的變更。

## 了解限流例外狀況
<a name="throttling-exceptions"></a>

當 DynamoDB 對請求進行限流時，會傳回包含詳細診斷資訊的特定例外狀況。例如，在 Java 中，這些例外狀況可能包括 `ProvisionedThroughputExceededException`、`RequestLimitExceeded` 或 `ThrottlingException`。

每個例外狀況都包含 `ThrottlingReasons`，其中的 `ThrottlingReason` 集合包含兩個關鍵欄位，可協助識別並理解限流原因：
+ **原因** - 依照 `<ResourceType><OperationType><LimitType>` 格式串接的欄位
+ **資源 ARN** - 受影響資料表或索引的 Amazon Resource Name (ARN)

原因欄位遵循一致模式，可協助精確判斷事件發生原因：
+ **ResourceType** (受限流的資源)：`Table` 或 `Index`
+ **OperationType** (操作類型)：`Read` 或 `Write`
+ **LimitType** (限流發生原因)：
  + `KeyRangeThroughputExceeded`：當支援資料表或索引的特定分割區耗用的讀寫容量超過內部分割區輸送量限制時，會發生此情況。
  + `ProvisionedThroughputExceeded`：當讀取或寫入消耗率超過預先佈建的容量時，此情況會發生在佈建資料表或全域次要索引上。
  + `AccountLimitExceeded`：當讀取或寫入消耗率超過帳戶層級設定的資料表及其索引的最大允許消耗率時，此情況會發生在隨需資料表或索引上。您可以提出請求以提高此配額。
  + `MaxOnDemandThroughputExceeded`：當讀取或寫入消耗率超過使用者為資料表或索引設定的最大允許消耗率時，這種情況會發生在隨需資料表或索引上。您可以自行將此值提高至帳戶限制範圍內的任意值，或設定為 -1 以表示未設定使用者自訂上限。

資源 ARN 可精確識別正在被限流的資料表或索引：
+ 資料表：`arn:aws:dynamodb:[region]:[account-id]:table/[table-name]`
+ 索引：`arn:aws:dynamodb:[region]:[account-id]:table/[table-name]/index/[index-name]`

完整限流原因範例：
+ `TableReadProvisionedThroughputExceeded`
+ `IndexWriteAccountLimitExceeded`

這有助於準確識別被限流的資源、造成限流的操作類型，以及限流發生的原因。

### 例外範例
<a name="throttling-exceptions-examples"></a>

#### 範例 1：GSI 超出佈建容量
<a name="throttling-exceptions-example1"></a>

```
{
    "ThrottlingReasons": [
        {
            "reason": "IndexWriteProvisionedThroughputExceeded",
            "resource": "arn:aws:dynamodb:us-west-2:123456789012:table/CustomerOrders/index/OrderDateIndex"
        }
    ],
    "awsErrorDetails": {
        "errorCode": "ProvisionedThroughputExceeded",
        "errorMessage": "The level of configured provisioned throughput for the index was exceeded",
        "serviceName": "DynamoDB",
        "sdkHttpResponse": {
            "statusText": "Bad Request",
            "statusCode": 400
        }
    }
}
```

在此範例中，應用程式會收到原因為 `IndexWriteProvisionedThroughputExceeded` 的 `ProvisionedThroughputExceededException`。對 `OrderDateIndex` 的寫入正在被限流，因為寫入消耗已超出 GSI 所設定的佈建寫入容量。

#### 範例 2：超過隨需輸送量上限
<a name="throttling-exceptions-example2"></a>

```
{
    "ThrottlingReasons": [
        {
            "reason": "TableReadMaxOnDemandThroughputExceeded",
            "resource": "arn:aws:dynamodb:us-east-1:123456789012:table/UserSessions"
        }
    ],
    "awsErrorDetails": {
        "errorMessage": "Throughput exceeds the maximum OnDemandThroughput configured on table or index",
        "errorCode": "ThrottlingException",
        "serviceName": "DynamoDB",
        "sdkHttpResponse": {
            "statusText": "Bad Request",
            "statusCode": 400
        }
    }
}
```

在此範例中，來自 `UserSessions` 資料表的讀取請求被限流，因為其超出該資料表設定的隨需輸送量上限。

## DynamoDB 限流診斷架構
<a name="throttling-diagnosing"></a>

當應用程式發生限流時，請依下列步驟進行診斷與解決。

### 步驟 1 - 分析 `ThrottlingReason` 詳細資訊
<a name="analyze-exception"></a>

1. 檢查**原因**欄位，以識別限流的具體原因。該原因會詳細說明被限流的資源類型 (資料表或索引)、造成限流事件的操作類型 (讀取或寫入)，以及超出的限制類型 (分割區、佈建輸送量、帳戶限制)。

1. 檢查 **resourceArn** 欄位，以識別正在被限流的資源 (資料表或全域次要索引)。

1. 使用這些綜合資訊以了解限流問題的完整脈絡。

   例如，在下列情境中，您會收到 `ProvisionedThroughputExceededException` 例外狀況，其限流原因為 `TableWriteKeyRangeThroughputExceeded`。受影響的 resourceARN 為 `arn:aws:dynamodb:us-west-2:123456789012:table/CustomerOrders`。

   此組合表示您的 `CustomerOrders` 資料表寫入操作正被限流。限流發生在分割區層級 (非資料表層級，該層級會顯示為 `TableWriteProvisionedThroughputExceeded`)。根本原因在於超出特定分割區鍵值或範圍的最大輸送容量，顯示這是熱分割區問題。

   了解例外狀況元素間的關聯有助於您採取正確的緩解策略——在此情境中，應處理熱分割區，而非提高資料表的整體佈建容量。

### 步驟 2 - 識別並分析相關的 CloudWatch 指標
<a name="analyze-cloudwatch-metrics"></a>

1. **識別您的指標：**DynamoDB 中的每個限流原因都直接對應可供監控的特定 CloudWatch 指標，用以追蹤並分析限流事件。您可以根據限流原因系統性地推導出對應的 CloudWatch 指標名稱。

1. 使用下列資料表將限流原因對應至相應的 CloudWatch 指標：  
**限流原因與 CloudWatch 指標完整對照表**    
<a name="throttling-reasons-metrics"></a>[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/amazondynamodb/latest/developerguide/throttling-diagnosing-workflow.html)

   例如，若您收到 `IndexWriteProvisionedThroughputExceeded`，至少應監控 `ResourceArn` 中所識別之特定索引的 `WriteProvisionedThroughputThrottleEvents` CloudWatch 指標。

1. 在 CloudWatch 中監控這些指標，以掌握限流事件的發生頻率與時機、區分讀取與寫入限流、識別限流增加的時間模式，並追蹤容量使用趨勢。

   DynamoDB 會針對每個資料表與全域次要索引發布詳細的監控指標。指標 `ReadThrottleEvents`、`WriteThrottleEvents`、`ThrottledRequests` 會彙整資料表及其索引中的所有限流事件。

### 步驟 3 - 使用 CloudWatch Contributor Insights 識別被限流的金鑰與高存取率 (適用於分割區層級的限流)
<a name="throttling-diagnosing-cci"></a>

若您在步驟 1 中發現分割區相關問題 (例如 `KeyRangeThroughputExceeded` 錯誤)，適用於 DynamoDB 的 CloudWatch Contributor Insights 可協助診斷哪些特定金鑰造成流量集中，並在資料表或索引中發生限流事件。

1. 根據您的 `ResourceARN`，為遭受限流的資料表或索引啟用 CloudWatch Contributor Insights。

   您可以選擇*限流金鑰*模式，僅專注於遭受限流次數最多的金鑰。此模式非常適合持續監控，因為僅在限流發生時才會處理事件。或者，您可以使用*存取與限流金鑰*模式，以協助您尋找最常被存取金鑰中的存取模式。

1. 分析報告，以辨識潛在的異常模式。找出存取或限流速率異常偏高的金鑰，並分析限流與流量之間的關聯模式。您可以結合 Contributor Insights 圖表與 DynamoDB CloudWatch 指標，建立整合式儀表板。

如需啟用與使用 CloudWatch Contributor Insights 的詳細資訊，請參閱[使用 CloudWatch Contributor Insights 於 DynamoDB](contributorinsights.md)。

### 步驟 4 - 判定合適的解決方案
<a name="throttling-diagnosing-remediate"></a>

完成限流原因診斷後，依據實際情境實作建議的解決方案。適當的解決方案取決於多項因素，包括限流情境、資料表的容量模式、資料表與金鑰設計、存取模式與查詢效率、全域與次要索引設定，以及整體系統架構與整合節點。

如需針對特定限流情境的詳細解決方案，請參閱 [DynamoDB 限流解決指南](troubleshooting-throttling-diagnostics.md) 章節。此資源提供依您的限流原因與容量模式設定量身調整的修復策略。

### 步驟 5 - 監控執行成效
<a name="throttling-diagnosing-monitor"></a>

1. 追蹤與限流情境對應的 CloudWatch 指標。

1. 透過觀察限流事件次數的下降，確認緩解策略的有效性。