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

# 對 Amazon DynamoDB 中的延遲問題進行疑難排解
<a name="TroubleshootingLatency"></a>

若您的工作負載似乎出現高延遲，您可以分析 CloudWatch `SuccessfulRequestLatency` 指標，並透過百分位數指標 (p50) 檢視平均與中位延遲，以判斷問題是否與 DynamoDB 有關。所回報的 `SuccessfulRequestLatency` 出現部分變化屬正常現象，偶發的尖峰 (尤其是在 `Maximum` 統計資料與高百分位數中) 無需特別擔心。然而，若 `Average` 統計資料或 p50 (中位數) 持續急遽上升，請檢視 AWS 服務健康狀態儀表板及個人健康儀表板，以取得更多資訊。可能的原因包括資料表中項目的大小 (1 KB 項目與 400 KB 項目的延遲會有所差異)，或查詢的範圍 (10 個項目與 100 個項目相比)。

百分位數指標 (p99、p90 等) 可協助您更深入了解延遲分布情形。例如：
+ p50 (中位數) 代表您的工作負載的典型延遲值。
+ p90 表示有 90% 的請求速度快於此值。
+ p99 有助於識別影響 1% 請求的最差延遲情況。

若 p99 值偏高但 p50 值正常，可能代表零星問題影響少部分請求；若 p50 值持續升高，則可能顯示效能衰退。

**注意**  
若要分析自訂百分位數值 (例如 p99.9)，可在 CloudWatch 指標統計欄位中手動輸入所需百分位數。這可讓您評估超出下拉選單預設百分位數範圍的延遲分布。

延遲指標出現變化 (特別是在高百分位數) 屬預期情形，通常是由 DynamoDB 背景作業造成，這些作業可協助維持儲存在 DynamoDB 資料表中的資料高可用性與耐用性，或反映暫時性基礎設施問題。

如有必要，請考慮使用 AWS 支援 建立支援案例，然後根據您的執行手冊，繼續評估您應用程式的任何可用回復選項 (例如，如果您有多區域架構，則撤離一個區域)。您應記錄慢速請求的請求 ID，以便在開啟支援案例時提供給 AWS 支援。

`SuccessfulRequestLatency` 指標僅衡量 DynamoDB 服務內部延遲，不包含用戶端活動與網路往返時間。若要深入了解用戶端呼叫 DynamoDB 服務的整體延遲，您可以在 AWS SDK 中啟用延遲指標記錄。

**注意**  
對於大部分單一操作 (透過完全指定主索引鍵的值來套用至單一項目的操作)，DynamoDB 提供個位數的毫秒 `Average SuccessfulRequestLatency`。此值不包括存取 DynamoDB 端點之呼叫者程式碼的傳輸負荷。對於多項目資料操作，延遲會因結果集的大小、傳回資料結構的複雜度，以及套用的任何條件表達式和篩選條件表達式等因素而有所不同。對於具有相同參數之相同資料集的重複多項操作，DynamoDB 提供高度一致的 `Average SuccessfulRequestLatency`。

請考慮下列一或多種策略來減少延遲：
+ **重複使用連線：**DynamoDB 請求預設透過 HTTPS 的已驗證工作階段傳送。建立連線需經多次往返且耗時，因此第一個請求的延遲通常高於後續重複使用連線的請求。經由已啟動連線的請求，可以提供 DynamoDB 一致的低延遲。為減少建立新連線的延遲負擔，若無其他 `GetItem` 請求，建議每 30 秒傳送一次請求，以實作「保持連線」機制。
+ **使用最終一致讀取：**如果您的應用程式不需要高度一致性讀取，請考慮使用預設的最終一致讀取。最終一致讀取的成本較低，且可從多個可用區域讀取資料，可選擇與請求端共置的可用區域，以降低延遲。如需更多詳細資訊，請參閱 [DynamoDB 讀取一致性](HowItWorks.ReadConsistency.md)。
+ **實作請求對沖：**若對 p99 延遲有極低要求，建議考慮實作請求對沖機制。在使用請求對沖時，若初始請求未能及時收到回應，系統會傳送第二個等效請求，並讓兩者同時競爭，以最先回應者為準。此方法可改善尾端延遲，但需付出額外請求的成本。您可自行設定在傳送第二個請求前的等待時間。對於讀取操作，對沖策略較容易實作。對於寫入操作，請使用以時間戳記為基礎的排序機制，以確保對沖請求視為在首次嘗試時發生，防止更新順序錯亂。此方法已在 [Amazon DynamoDB 寫入對沖的時間戳記寫入](https://aws.amazon.com/blogs/database/timestamp-writes-for-write-hedging-in-amazon-dynamodb)一文中詳述。
+ **調整請求逾時與重試行為：**從用戶端到 DynamoDB 的傳輸路徑會經過多個元件，且各元件皆具備備援設計。請考量以下面向：
  + 網路韌性
  + TCP 封包逾時
  + DynamoDB 的分散式架構

  SDK 的預設行為已針對多數應用程式進行最佳化。不過，您也可採用快速檢錯策略，並視需要調整逾時設定。明顯超出一般時間的請求，最終成功機率較低。採用快速檢錯並重新嘗試的方式，您可以透過其他路徑更快完成請求。此策略類似於請求對沖，但會終止第一個請求，而非讓其持續執行。

  避免將逾時值設定得過低。過低的逾時設定可能造成用戶端引起的可用性問題。例如，若通訊端逾時設定為 50 毫秒，當網路延遲出現尖峰 (例如單一流量接近 Amazon EC2 執行個體頻寬上限) 時，可能導致連線錯誤。請仔細權衡較低逾時設定的效益與其對應用程式可用性造成的風險，並建議優先採用對沖策略，而非縮短逾時。

   如需更深入的討論，請參閱[為延遲感知的 Amazon DynamoDB 應用程式調整 AWS Java SDK HTTP 請求設定](https://aws.amazon.com/blogs/database/tuning-aws-java-sdk-http-request-settings-for-latency-aware-amazon-dynamodb-applications/)。
+ **減少用戶端與 DynamoDB 端點之間的距離：**如果您的使用者遍布全球，請考慮使用 [全域資料表：多重作用中的多區域複寫](GlobalTables.md)。透過全域資料表，您可將資料表複寫至指定的 AWS 區域，以確保在所需區域可供使用。可將資料複本部署於接近終端使用者的位置，以降低讀寫操作的網路延遲。如需深入了解如何有效使用 DynamoDB 全域資料表，請參閱[使用 Amazon DynamoDB 全域資料表](https://docs.aws.amazon.com/prescriptive-guidance/latest/dynamodb-global-tables/introduction.html) (AWS 規範指引)。
+ **使用快取：**若您的應用以讀取為主，請考慮以下快取服務：
  + DynamoDB 加速器 (DAX)：一種全受管、高可用性的記憶體快取，可為 DynamoDB 帶來高達 10 倍的效能提升，將延遲從毫秒降至微秒，即使每秒處理數百萬次請求亦能維持效能。如需 DAX 的詳細資訊，請參閱 [使用 DynamoDB Accelerator (DAX) 的記憶體內加速](DAX.md)：
  + Amazon ElastiCache：全受管的記憶體快取服務，可與 DynamoDB 整合，並採用快取旁路模式以提升讀取效能。如需更多資訊，請參閱[使用讀取快取整合 Amazon DynamoDB 與 Amazon ElastiCache](https://docs.aws.amazon.com/prescriptive-guidance/latest/dynamodb-elasticache-integration/introduction.html) (AWS 規範指引)。