疑難排解佈建模式的節流問題

如果您的應用程式超過資料表或索引上佈建的輸送容量，將會請求調節。調節可防止您的應用程式使用太多容量單位。當 DynamoDB 節流讀取或寫入作業時，它會傳回給呼叫者ProvisionedThroughputExceededException。應用程式接著可以採取適當動作，例如在重試請求之前等待短間隔。

對於疑難排解看似與節流有關的問題，重要的第一步是確認節流是來自 DynamoDB 還是來自應用程式。

本主題討論如何疑難排解已佈建容量模式的常見節流問題。以下是一些常見案例，以及協助解決問題的可能步驟。

DynamoDB 表格似乎具有足夠的佈建容量，但請求正在限制

當輸送量低於每分鐘的平均值，但超過每秒可用量時，就會發生這種情況。DynamoDB 只會向分鐘層級量度報告 CloudWatch，這些量度是以一分鐘的總和和計算得出的平均值。但是 DynamoDB 本身會套用每秒的速率限制。因此，如果在該分鐘的一小部分 (例如幾秒鐘或更短的時間) 內發生過多的輸送量，則可將該分鐘剩餘時間的請求加以限流。

例如，如果我們在一個表上佈建了 60 個 WCU，那麼它可以在一分鐘內執行 3600 個寫入操作。但是，如果所有 3600 WCU 請求都在同一秒鐘內命中，則該分鐘的其餘部分將受到限流。

解決這種案例的一種方法是將一些抖動和指數退避新增至 API 呼叫。如需詳細資訊，請參閱這篇有關指數退避和抖動的貼文。

自動縮放功能已啟用，但表格仍在節流中

此情況可能發生在流量突增期間。當 2 個資料點在一分鐘範圍內違反設定的目標使用率值時，就可以觸發自動擴展。因此，由於消耗的容量在兩分鐘內高於目標使用率，因此可能會發生 auto 擴展。但是，如果尖峰相隔超過一分鐘，則可能不會觸發 auto 縮放。

同樣地，當連續 15 個資料點低於目標使用率時，就會觸發縮減規模事件。在任何一種情況下，在觸發 auto 縮放之後，都會叫用 UpdateTable API 作業。然後可能需要幾分鐘的時間來更新表格或索引的佈建容量。在此期間，任何超出表格先前佈建容量的要求都會受到限制。

總而言之，auto 擴展需要連續的資料點，其中違反了目標使用率值以擴展 DynamoDB 表。因此，不建議將 auto 擴展作為處理 spikey 工作負載的解決方案。如需詳細資訊，請參閱 auto 調整成本最佳化文件。

熱鍵可能導致節流問題

在 DynamoDB 中，沒有高基數的分割區索引鍵可能會產生許多僅以幾個分割區為目標的請求。如果產生的熱分割區超過每秒 3000 RCU 或 1000 WCU 的分割區限制，這可能會導致節流。診斷工具 CloudWatch 參與者見解 (CCI) 可以透過針對每個資料表的項目存取模式提供 CCI 圖形來協助偵錯此問題。您可以持續監控 DynamoDB 資料表中最常存取的索引鍵和其他流量趨勢。如需有關 CloudWatch 貢獻者深入解析的詳細資訊，請參閱 DynamoDB 的參CloudWatch 與者深入解析。如需詳細資訊，請參閱設計分割區金鑰以在 DynamoDB 中分配工作負載和選擇正確的 DynamoDB 分區金鑰。

您的資料表流量超出表格層級輸送量配額。

資料表層級的讀取輸送量和資料表層級的寫入輸送量配額適用於任何區域的帳戶層級。這些配額適用於同時具有佈建容量模式和隨需容量模式的資料表。根據預設，放置在資料表上的輸送量配額為 40,000 個讀取請求單位和 40,000 個寫入請求單位。如果資料表中的流量超過這個配額，資料表可能會遭到限流。有關如何防止這種情況發生的詳細資訊，請參閱監視 DynamoDB 的操作感知。

若要解決此問題，請使用 Service Quotas 主控台來提高您帳戶的資料表層級讀取或寫入輸送量配額。