為什麼我的 Amazon DynamoDB 平均延遲正常但最大延遲指標高？

解決方案

在分析 CloudWatch 指標 SuccessfulRequestLatency 時，檢查平均延遲是一種最佳做法。最大延遲並不能反映 DynamoDB 資料表的整體延遲。它反映的是該時間段內單個請求所花費的最長時間。例如，如果您一次對 DynamoDB 資料表進行 100 個請求，即使 99 個請求只需要 10 毫秒，但只要有 1 個請求需要 100 毫秒，那麼最大延遲指標也會是 100 毫秒。

DynamoDB 是一種大規模的分散式系統，其後端機群有數千個節點。因此，一個 DynamoDB 資料表可能在資料表空間中有多個分割區，並且每個分割區在後端機群中有多個複本。當您對 DynamoDB 進行 API 呼叫時，DynamoDB 服務端點會接收呼叫，然後將其路由到後端節點之一進行處理。成功處理呼叫後，DyanamoDB 會將結果路由回您的用戶端。

在大多數情況下，一個 API 呼叫在一次嘗試中即可成功處理，因此您在用戶端上觀察到的延遲會很小。但第一次嘗試有時會因後端節點遇到下列狀況而失敗：

• 忙碌
• 容錯移轉
• 分割區拆分
• 連線問題

在這些狀況下，第一次嘗試會在伺服器端逾時 (5000 毫秒) 內失敗。然後，伺服器會自動在另一個節點上重試 API 呼叫，並且通常會進行多次。成功處理 API 呼叫後，伺服器會將結果返回給用戶端。發生這種狀況時，您會觀察到該特定請求的延遲增加。 因此，您通常不需要擔心較高的最大延遲指標。如果 DynamoDB 服務觀察到某個節點持續出現高延遲，則該服務會自動將該節點從後端機群中移除。當前面提到的局部故障發生在服務端時，您可能會觀察到一定百分比的 API 呼叫延遲有所增加。這在 CloudWatch 中會反映為相關 DynamoDB 資料表的 SuccessfulRequestLatency 指標升高。因此，局部故障可能會導致最大延遲增加，但您無需採取任何措施來控制此故障。

但是，您可以透過指數退避重試快速檢錯來設定應用程式，以快速做出反應。這意味著新請求會被快速路由到新的節點，從而您可以更快地取得結果。如需詳細資訊，請參閱為延遲感知型 Amazon DynamoDB 應用程式調整 AWS Java SDK HTTP 請求設定。

---

相關資訊

如何對 Amazon DynamoDB 資料表的高延遲進行疑難排解？

延遲指標記錄