# DynamoDB 节流解决方法指导
本节针对 DynamoDB 可能返回的每种特定节流原因，提供了针对性的解决方案指导。每个条目都包含基于最佳实践的建议解决方法，以及要监控的对应 CloudWatch 指标。
DynamoDB 实施了 16 种不同的节流理由，分为 4 个主要类别。使用应用程序异常中指示的节流原因，直接导航到相关的指导方法。
## 超过键范围吞吐量（热分区）
当单个分区超过其吞吐量限额时，就会出现这些节流原因，此时预置模式和按需模式都会受影响：
+ [TableReadKeyRangeThroughputExceeded](throttling-key-range-limit-exceeded-mitigation.md#throttling-table-read-keyrange)
+ [TableWriteKeyRangeThroughputExceeded](throttling-key-range-limit-exceeded-mitigation.md#throttling-table-write-keyrange)
+ [IndexReadKeyRangeThroughputExceeded](throttling-key-range-limit-exceeded-mitigation.md#throttling-index-read-keyrange)
+ [IndexWriteKeyRangeThroughputExceeded](throttling-key-range-limit-exceeded-mitigation.md#throttling-index-write-keyrange)
## 超出预置吞吐量
在预置模式下，当消耗速率超过预置容量限额时，就会出现这些节流原因：
+ [TableReadProvisionedThroughputExceeded](throttling-provisioned-capacity-exceeded-mitigation.md#throttling-table-read-provisioned)
+ [TableWriteProvisionedThroughputExceeded](throttling-provisioned-capacity-exceeded-mitigation.md#throttling-table-write-provisioned)
+ [IndexReadProvisionedThroughputExceeded](throttling-provisioned-capacity-exceeded-mitigation.md#throttling-index-read-provisioned)
+ [IndexWriteProvisionedThroughputExceeded](throttling-provisioned-capacity-exceeded-mitigation.md#throttling-index-write-provisioned)
## 超过账户限额
在 AWS 区域中，当消耗速率超过了账户级别的吞吐量配额时，就会出现这些节流原因：
+ [TableReadAccountLimitExceeded](throttling-account-limit-exceeded-mitigation.md#throttling-table-read-account-limit)
+ [TableWriteAccountLimitExceeded](throttling-account-limit-exceeded-mitigation.md#throttling-table-write-account-limit)
+ [IndexReadAccountLimitExceeded](throttling-account-limit-exceeded-mitigation.md#throttling-index-read-account-limit)
+ [IndexWriteAccountLimitExceeded](throttling-account-limit-exceeded-mitigation.md#throttling-index-write-account-limit)
## 超出按需最大吞吐量
在按需模式下，当消耗速率超过配置的最大吞吐量限额时，就会出现这些节流原因：
+ [TableReadMaxOnDemandThroughputExceeded](throttling-ondemand-capacity-exceeded-mitigation.md#throttling-diagnostic-table-read-max-ondemand)
+ [TableWriteMaxOnDemandThroughputExceeded](throttling-ondemand-capacity-exceeded-mitigation.md#throttling-diagnostic-table-write-max-ondemand)
+ [IndexReadMaxOnDemandThroughputExceeded](throttling-ondemand-capacity-exceeded-mitigation.md#throttling-diagnostic-index-read-max-ondemand)
+ [IndexWriteMaxOnDemandThroughputExceeded](throttling-ondemand-capacity-exceeded-mitigation.md#throttling-diagnostic-index-write-max-ondemand)
# 1. 超过键范围吞吐量（热分区）
Amazon DynamoDB 在分区级别对表和全局二级索引（GSI）都会实施特定的吞吐量限制。每个分区都有每秒最大读取容量单位（RCU）和写入容量单位（WCU）数量。当分区上集中的流量超过这些限额时，就会遇到节流情况，而其他操作的使用量可能并不高，从而产生“热分区”。DynamoDB 的分区级别节流对读取和写入操作是独立的，分区可能会限制读取，而写入操作正常，或者反之。即使您的表或 GSI 具有足够的总容量，也可能发生这种节流。如需详细了解：
+ DynamoDB 分区限额以及预防热分区的有效分区键设计方法，请参阅[在 DynamoDB 中设计并有效使用分区键的最佳实践](bp-partition-key-design.md)。
+ 一般分区概念和数据分布，请参阅 [DynamoDB 中的分区](HowItWorks.Partitions.md)。
+ 有关管理分区键和吞吐量的更多指导和实际场景，请参阅[其他资源](#key-range-additional-resources)。
当单个分区超过其吞吐量限额时，DynamoDB 会在节流异常中返回 `KeyRangeThroughputExceeded` 节流原因类型。该信息标识出现高流量的分区，以及哪种操作类型（读取或写入）导致了问题。
## 超出键范围吞吐量缓解措施
本节针对分区级别节流场景提供解决方法指导。使用本指南之前，请确保您根据应用程序的异常处理确定了具体的节流原因，并确定了受影响资源的 Amazon 资源名称（ARN）。有关检索节流原因和识别受限制资源的信息，请参阅[DynamoDB 节流诊断框架](throttling-diagnosing-workflow.md#throttling-diagnosing)。
在深入研究特定节流场景之前，请首先检查问题是否会自动解决：
+ DynamoDB 通常通过其自动拆分热分区机制来适应热分区。如果您看到节流事件在短时间后停止，则表可能已经通过拆分热分区来适应流量。拆分分区后，每个新分区都会处理一小部分键空间，这有助于更均匀地分配负载。许多情况下无需进一步操作，因为 DynamoDB 已自动解决问题。
有关*拆分热分区机制*的更多信息，请参阅[其他资源](#key-range-additional-resources)。
如果节流问题仍然存在，请参阅下面的特定节流方案，了解针对性的补救选项：
+ [TableReadKeyRangeThroughputExceeded](#throttling-table-read-keyrange)
+ [TableWriteKeyRangeThroughputExceeded](#throttling-table-write-keyrange)
+ [IndexReadKeyRangeThroughputExceeded](#throttling-index-read-keyrange)
+ [IndexWriteKeyRangeThroughputExceeded](#throttling-index-write-keyrange)
### TableReadKeyRangeThroughputExceeded
**何时出现**
DynamoDB 表中一个或多个分区的消耗速率，超过了分区的读取吞吐量限额。无论您的表预置了多大的总容量，这种节流情况都可能会出现，并且会影响预置表和按需表。您可以在 [常见的诊断和监控方法](#key-range-exceeded-diagnosis-monitoring) 中监控 CloudWatch 指标来分析节流事件。
**修复方案**
请考虑采取以下步骤来解决节流事件：
**对于预置模式和按需模式：**
+ **预热容量**：如果节流情况仍然存在，请检查您的表是否受本身的[了解 DynamoDB 热吞吐量](warm-throughput.md)容量限制。使用热吞吐量或提前增加读取预置容量，来应对预期的流量增长。增加热吞吐量可以提高表处理突然出现的流量峰值的能力，防止出现节流。随着时间的推移，如果实际吞吐量始终接近热吞吐量水平，则 DynamoDB 可能会根据观察到的使用模式，拆分繁忙的分区。
+ **识别热键**：如果表没有自动解决问题，并且您的热吞吐量很高或者提高热吞吐量无济于事，则您需要确定具体的热键。使用 [使用 CloudWatch Contributor Insights 识别热键](#key-range-identify-hot-keys) 确定是否有任何特定的分区键值过热。这是有效确定缓解工作的第一步。请注意，识别热键并不总是那么简单，尤其是在具有滚动的热分区（随着时间的推移不同的分区变热）或由扫描等操作触发节流时。对于这些复杂的场景，您可能需要分析应用程序的访问模式，并将其与节流事件的时间关联起来。
+ **根据使用案例考虑使用最终一致性读取**：从强一致性读取切换到最终一致性读取，这可以将消耗的 RCU 减半，并直接将有效读取容量翻番。有关实施最终一致性读取以减少读取容量消耗的最佳实践，请参阅 [DynamoDB 读取一致性](HowItWorks.ReadConsistency.md)。
+ **改进分区键设计**：作为长期解决方案，请考虑[改进分区键设计](#key-range-improve-partition-key-design)，在分区之间更均匀地分配访问权限。这种方法通常可以解决根本原因，提供了针对热分区问题的最全面的解决方法。但是，这种方法需要精心规划，因为会涉及到巨大的迁移挑战。
### TableWriteKeyRangeThroughputExceeded
**何时出现**
DynamoDB 表中一个或多个分区的消耗速率，超过了分区的写入吞吐量限额。无论您的表预置了多大的总容量，这种节流情况都可能会出现，并且会影响预置表和按需表。您可以在 [常见的诊断和监控方法](#key-range-exceeded-diagnosis-monitoring) 中监控 CloudWatch 指标来分析节流事件。
**修复方案**
请考虑采取以下步骤来解决节流事件：
**对于预置模式和按需模式：**
+ **预热容量**：如果节流情况仍然存在，请检查您的表是否受本身的[了解 DynamoDB 热吞吐量](warm-throughput.md)容量限制。使用热吞吐量或提前增加写入预置容量，来应对预期的流量增长。增加热吞吐量可以提高表处理突然出现的流量峰值的能力，防止出现节流。随着时间的推移，如果实际吞吐量始终接近热吞吐量水平，则 DynamoDB 可能会根据观察到的使用模式，拆分繁忙的分区。
+ **识别热键**：如果表没有自动解决问题，并且您的热吞吐量很高或者提高热吞吐量无济于事，则您需要确定具体的热键。使用 [使用 CloudWatch Contributor Insights 识别热键](#key-range-identify-hot-keys) 确定是否有任何特定的分区键值过热。这是有效确定缓解工作的第一步。请考虑以下常见模式：
+ 如果您在节流数据中频繁看到相同的分区键，则表示这是集中热键。
+ 如果您没有看到重复出现的键，而是以有序的方式写入数据（例如顺序时间戳，或者遵循键空间顺序的基于扫描的操作），则可能存在滚动的热分区，当写入操作在键空间中移动时，随时间的推移不同的键会变热。
请注意，写入节流可能会发生在 `BatchWriteItem` 等操作上或者会同时影响多个项目的事务上。当 `BatchWriteItem` 请求中的单个项目受到限制时，DynamoDB 不会将这些节流错误传播到应用程序代码。相反，DynamoDB 会在响应中返回有关未处理项目的信息，应用程序必须重试这些特定项目来处理这种情况。对于事务，如果任何项目出现了节流事件，则整个操作将失败并返回 `TransactionCanceledException`。对于这些复杂的场景，您可能需要分析应用程序的写入模式和数据摄取工作流，将这些信息与发生节流事件的时间关联起来，并实施适当的重试处理策略。
+ **改进分区键设计**：作为长期解决方案，请考虑[改进分区键设计](#key-range-improve-partition-key-design)，在分区之间更均匀地分配访问权限。这种方法通常可以解决根本原因，提供了针对热分区问题的最全面的解决方法。但是，这种方法需要精心规划，因为会涉及到巨大的迁移挑战。
### IndexReadKeyRangeThroughputExceeded
**何时出现**
DynamoDB GSI 中一个或多个分区的消耗速率，超过了分区的读取吞吐量限额。无论您的 GSI 预置了多大的总容量，这种节流情况都可能会出现，并且会影响预置表和按需表。您可以在 [常见的诊断和监控方法](#key-range-exceeded-diagnosis-monitoring) 中监控 CloudWatch 指标来分析节流事件。
**修复方案**
请考虑采取以下步骤来解决节流事件：
+ **预热容量**：如果节流情况仍然存在，请检查您的 GSI 是否受本身的[了解 DynamoDB 热吞吐量](warm-throughput.md)容量限制。使用热吞吐量或提前增加读取预置容量，来应对预期的流量增长。增加热吞吐量可以提高 GSI 处理突然出现的流量峰值的能力，防止出现节流。随着时间的推移，如果实际吞吐量始终接近热吞吐量水平，则 DynamoDB 可能会根据观察到的使用模式，拆分繁忙的分区。
+ **识别热键**：如果 GSI 没有自动解决问题，并且您的热吞吐量很高或者提高热吞吐量无济于事，则您需要确定具体的热键。使用 [使用 CloudWatch Contributor Insights 识别热键](#key-range-identify-hot-keys) 确定是否有任何特定的分区键值过热。这是有效确定缓解工作的第一步。请注意，对于 GSI，分区键分布可能与您的基表有很大不同，从而造成不同的热键模式。
+ **重新设计 GSI 分区键**：考虑您的 GSI 键设计是否可能会造成人为的热点（例如状态标志、仅限日期的键或布尔属性），将读取集中在少数分区上。请考虑使用复合键，将低基数属性与高基数属性相结合（例如，“ACTIVE\$1customer123”而不是仅用“ACTIVE”），或者对影响 GSI 分布的基表项目应用[在 DynamoDB 表中使用写入分片来均匀分配工作负载](bp-partition-key-sharding.md)技术，以便在多个分区之间分配写入操作。虽然查询分片数据需要额外的应用程序逻辑来汇总结果，但这种方法可以更均匀地分配访问模式来防止节流。
### IndexWriteKeyRangeThroughputExceeded
**何时出现**
DynamoDB GSI 中一个或多个分区的消耗速率，超过了分区的写入吞吐量限额。无论您的 GSI 预置了多大的总容量，这种节流情况都可能会出现，并且会影响预置表和按需表。您可以在 [常见的诊断和监控方法](#key-range-exceeded-diagnosis-monitoring) 中监控 CloudWatch 指标来分析节流事件。
**修复方案**
请考虑采取以下步骤来解决节流事件：
+ **重新设计 GSI 分区键**：检查您的 GSI 分区键设计，确保其基数（唯一性）足以均匀地分配写入操作。导致 GSI 写入节流的一个常见原因是使用低基数属性作为 GSI 分区键（例如只有几个可能值的状态标志）。即使您的基表具有分布良好的分区键，如果其分区键将写入集中到少量的值上，则 GSI 仍然会遇到热分区。例如，如果 80% 的项目具有 status="ACTIVE"，则这会在基于状态的 GSI 中造成非常热的分区。请考虑使用复合键，将低基数属性与高基数属性相结合（例如，“ACTIVE\$1customer123”而不是仅用“ACTIVE”），或者对影响 GSI 分布的基表项目应用[在 DynamoDB 表中使用写入分片来均匀分配工作负载](bp-partition-key-sharding.md)技术，以便在多个分区之间分配写入操作。虽然查询分片数据需要额外的应用程序逻辑来汇总结果，但这种方法可以更均匀地分配访问模式来防止节流。
+ **预热容量**：检查您的 GSI 是否受其[了解 DynamoDB 热吞吐量](warm-throughput.md)容量限制。使用热吞吐量或提前增加写入预置容量，来应对预期的流量增长。增加热吞吐量可以提高 GSI 处理突然出现的流量峰值的能力，防止出现节流。随着时间的推移，如果实际吞吐量始终接近热吞吐量水平，则 DynamoDB 可能会根据观察到的使用模式，拆分繁忙的分区。
+ **优化 GSI 投影**：应用[优化 GSI 投影](#key-range-optimize-gsi-projections)技术来减少对 GSI 的写入量。对更少的属性进行投影，可以显著减少每个 GSI 更新消耗的写入容量。
## 常见的诊断和监控方法
在对分区级别的节流问题进行故障排除时，可以利用多种 CloudWatch 指标来识别热分区并确认根本原因。
**关键 CloudWatch 指标**
监控以下关键指标以诊断分区级别的节流：
+ **分区级别的节流事件**：[https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadKeyRangeThroughputThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadKeyRangeThroughputThrottleEvents) 和 [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteKeyRangeThroughputThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteKeyRangeThroughputThrottleEvents) 跟踪单独分区何时超过其吞吐量限额。[https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents) 和 [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents) 跟踪任意读取或写入请求何时超过其预置容量。
+ **容量消耗**：[https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits) 和 [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits) 显示整体使用模式。
## 解决过程
### 使用 CloudWatch Contributor Insights 识别热键
使用此过程来确定哪些分区键导致了节流。
1. 在表或 GSI 上启用 [CloudWatch Contributor Insights](contributorinsights_HowItWorks.md) 来跟踪最受限的键。考虑保持 CloudWatch Contributor Insights 的持续启用，使用*受限的键*模式来实时获取节流警报。此模式仅关注受限制的请求，仅在出现节流问题时处理事件。这种针对性的监控是一种经济高效的方式，可以确保持续检测节流问题。
1. 确定哪些键导致了热分区问题。
1. （在启用了完整的*访问的键和受限的键模式*时）分析一段时间内的访问模式，确定热键是否一致或是否发生在特定时段。
### 改进分区键设计
如果您可以修改表架构以更好地在分区之间分配流量时，请使用此方法。在可以使用此方法时，这是解决热分区问题的最有效的长期解决方案。理想情况下，应在初始表设计阶段仔细考虑分区键的设计。
重新设计分区键意味着对数据模型的根本性更改，会影响整个应用程序生态系统。在继续使用此方法之前，请认真考虑以下重要限制：
+ **数据迁移的复杂性**：重新设计分区键需要迁移现有的全部数据，对于大型表来说，这会占用大量资源且非常耗时。
+ **应用程序代码更改**：对表执行读取或写入操作的所有应用程序代码都必须进行更新，以便使用新的键结构。
+ **生产影响**：迁移到新的键设计时，在过渡期间通常会产生停机时间或者需要采用复杂的双重写入策略。
有关分区键设计的全面指导和所应遵循的原则，请参阅[在 DynamoDB 中设计并有效使用分区键的最佳实践](bp-partition-key-design.md)和[在 DynamoDB 中设计分区键来分配工作负载](bp-partition-key-uniform-load.md)。
### 优化 GSI 投影
查看应用程序的查询模式，来确切地确定查询 GSI 时需要哪些属性可用，并仅对这些属性进行投影。当您更新未投影到 GSI 中的属性时，就不会对 GSI 执行写入操作，从而减少更新期间的写入吞吐量消耗。这种针对性的投影策略可以优化性能和成本，同时仍可支持应用程序的查询要求。请注意，对较少的属性进行投影可以减少写入容量消耗，但可能需要额外的基表读取。
有关高效投影策略的更多信息，请参阅[在 DynamoDB 中使用二级索引的最佳实践](bp-indexes-general.md)。
## 其他资源
以下博客文章提供了本指南中所涵盖概念的动手操作示例和实用细节：
+ 有关扩展 DynamoDB 和管理热分区的动手操作指南，请参阅 [Part 1: Scaling DynamoDB - How partitions, hot keys, and split for heat impact performance](https://aws.amazon.com/blogs/database/part-1-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/)。
+ 有关 DynamoDB 的拆分热分区机制的工作原理、其优势和实施细节的详细信息，请参阅 [Part 3: Summary and best practices](https://aws.amazon.com/blogs/database/part-3-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/)。
+ 有关详细的写入分片策略，请参阅[在 DynamoDB 表中使用写入分片来均匀分配工作负载](bp-partition-key-sharding.md)。
# 2. 超出预置吞吐量
当应用程序的使用速率超过为表或全局二级索引预置的读取或写入容量单位（RCU/WCU）时，就会发生预置容量节流。虽然 DynamoDB 提供了容量爆增功能来应对偶发的流量峰值，但持续超出预置限额的请求会导致出现节流。发生这种情况时，DynamoDB 会在节流异常中返回 `ProvisionedThroughputExceeded` 节流原因类型。通过该原因，您可以确定问题出在读取还是写入操作上，以及它是影响基表还是全局二级索引。
无论是否启用了自动扩缩，都有可能会出现节流情况。自动扩缩会适应消耗量的增长，但并不能即时做出响应，并且扩缩能力受到您配置的最大容量限额的约束。这意味着，在流量突然激增或消耗量超过自动扩缩的最大限额时，仍可能出现节流。
## 超出预置吞吐量的缓解措施
本节针对预置容量节流场景提供解决方法指导。使用本指南之前，请确保您根据应用程序的异常处理确定了具体的节流原因，并确定了受影响资源的 Amazon 资源名称（ARN）。有关检索节流原因和识别受限制资源的信息，请参阅[DynamoDB 节流诊断框架](throttling-diagnosing-workflow.md#throttling-diagnosing)。
在深入研究具体的节流场景之前，首先请考虑节流情况是否真的是需要解决的问题：
+ 在经过良好优化的 DynamoDB 应用程序中，偶尔出现的节流是正常现象，也是意料之中的。节流仅仅意味着您已经 100% 地消耗了已配置的资源。如果应用程序能够通过重试很好地处理节流问题，并且整体性能符合要求，则可能不需要立即处理节流问题。
+ 但是，如果节流导致不可接受的客户端延迟、用户体验降级或使关键操作无法及时完成，则您应继续考虑采用以下缓解选项。
如果需要解决节流问题，请您先确定是否由以下原因引起了节流：
+ **临时流量峰值**：流量在短时间内增加，超过您的预置容量，但不会长时间持续。与持续的高流量相比，这种情况需要采用不同的策略。
+ **持续高流量**：持续的工作负载一直超过您的预置容量。
对于流量峰值，请考虑采用[其他资源](#throttling-additional-resources)中的 *Handle traffic spikes with Amazon DynamoDB provisioned capacity* 博客给出的策略。
对于持续的高流量，请考虑以下容量调整选项：
+ [TableReadProvisionedThroughputExceeded](#throttling-table-read-provisioned)
+ [TableWriteProvisionedThroughputExceeded](#throttling-table-write-provisioned)
+ [IndexReadProvisionedThroughputExceeded](#throttling-index-read-provisioned)
+ [IndexWriteProvisionedThroughputExceeded](#throttling-index-write-provisioned)
### TableReadProvisionedThroughputExceeded
**何时出现**
应用程序的读取消耗速率超过了为表配置的[预置读取容量单位](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ProvisionedThroughput.html#DDB-Type-ProvisionedThroughput-ReadCapacityUnits)（RCU）。您可以在 [常见的诊断和监控方法](#provisioned-capacity-exceeded-diagnosis-monitoring) 中监控 CloudWatch 指标来分析节流事件。
**解决方法**
请考虑采用以下策略来解决读取容量节流问题：
+ **切换到按需容量模式**：如果您经常遇到流量高峰造成的节流问题，请考虑[将表切换到按需模式](#procedure-switch-ondemand)。按需模式无需考虑预置容量，并可根据工作负载自动扩展。
+ **若要保持预置模式并且不启用自动扩缩：**
+ 请考虑[增加表的读取容量](#provisioned-capacity-exceeded-increase-table-throughput)。
+ 为表上的[读取容量启用自动扩缩](#provisioned-capacity-configure-autoscaling)。
+ **如果启用了自动扩缩（在控制台中创建的表的默认设置）：**
+ [优化表的读取自动扩缩参数](#provisioned-capacity-optimize-autoscaling-settings)。
### TableWriteProvisionedThroughputExceeded
**何时出现**
应用程序的写入消耗速率超过了为表配置的[预置写入容量单位](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ProvisionedThroughput.html#DDB-Type-ProvisionedThroughput-WriteCapacityUnits)（WCU）。您可以在 [常见的诊断和监控方法](#provisioned-capacity-exceeded-diagnosis-monitoring) 中监控 CloudWatch 指标来分析节流事件。
**解决方法**
请考虑采用以下策略来解决写入容量节流问题：
+ **切换到按需容量模式**：如果您经常遇到流量高峰造成的节流问题，请考虑[将表切换到按需模式](#procedure-switch-ondemand)。按需模式无需考虑预置容量，并可根据工作负载自动扩展。
+ **若要保持预置模式并且不启用自动扩缩：**
+ 请考虑[增加表写入容量](#provisioned-capacity-exceeded-increase-table-throughput)。
+ 为表上的[写入容量启用自动扩缩](#provisioned-capacity-configure-autoscaling)。
+ **如果启用了自动扩缩（在控制台中创建的表的默认设置）：**
+ [优化表的写入自动扩缩参数](#provisioned-capacity-optimize-autoscaling-settings)。
### IndexReadProvisionedThroughputExceeded
**何时出现**
某个全局二级索引（GSI）上的读取消耗量超过 GSI 的[预置读取容量单位](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ProvisionedThroughput.html#DDB-Type-ProvisionedThroughput-ReadCapacityUnits)（RCU）。您可以在 [常见的诊断和监控方法](#provisioned-capacity-exceeded-diagnosis-monitoring) 中监控 CloudWatch 指标来分析节流事件。
**解决方法**
请考虑采用以下策略来解决 GSI 读取容量节流问题：
+ **切换到按需容量模式**：如果您经常遇到流量高峰造成的节流问题，请考虑[将基表切换到按需模式](#procedure-switch-ondemand)。按需模式无需考虑预置容量，并可根据工作负载自动扩展。
+ **若要保持预置模式并且不启用自动扩缩：**
+ 请考虑[增加 GSI 读取容量](#provisioned-capacity-exceeded-increase-index-throughput)。
+ 为 GSI 上的[读取容量启用自动扩缩](#provisioned-capacity-configure-autoscaling)。
+ **如果启用了自动扩缩（在控制台中创建的表的默认设置）：**
+ [优化 GSI 的读取自动扩缩参数](#provisioned-capacity-optimize-autoscaling-settings)。
### IndexWriteProvisionedThroughputExceeded
**何时出现**
对基表中项目的更新会触发写入到某个 GSI，进而超过该 [GSI 的预置写入容量](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ProvisionedThroughput.html#DDB-Type-ProvisionedThroughput-WriteCapacityUnits)。这会导致基表写入时出现[背压节流](gsi-throttling.md)。您可以在 [常见的诊断和监控方法](#provisioned-capacity-exceeded-diagnosis-monitoring) 中监控 CloudWatch 指标来分析节流事件。
**解决方法**
请考虑采用以下策略来解决 GSI 写入容量节流问题：
+ **切换到按需容量模式**：如果您经常遇到流量高峰造成的节流问题，请考虑[将基表切换到按需模式](#procedure-switch-ondemand)。按需模式无需考虑预置容量，并可根据工作负载自动扩展。
+ **若要保持预置模式并且不启用自动扩缩：**
+ 请考虑[增加 GSI 写入容量](#provisioned-capacity-exceeded-increase-index-throughput)。
+ 为 GSI 上的[写入容量启用自动扩缩](#provisioned-capacity-configure-autoscaling)。
+ **如果启用了自动扩缩（在控制台中创建的表的默认设置）：**
+ [优化 GSI 的写入自动扩缩参数](#provisioned-capacity-optimize-autoscaling-settings)。
## 常见的诊断和监控方法
在对吞吐量错误进行故障排除时，可以利用多种 CloudWatch 指标来确定根本原因。
**关键 CloudWatch 指标**
监控以下关键指标来诊断预置容量节流问题：
+ **节流事件**：[https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadProvisionedThroughputThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadProvisionedThroughputThrottleEvents) 和 [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteProvisionedThroughputThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteProvisionedThroughputThrottleEvents) 跟踪什么时候出于此原因导致请求受限。[https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents) 和 [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents) 跟踪什么时候读取或写入请求超出了预置容量。
+ **容量消耗**：[https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits) 和 [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits) 显示实际使用情况。
+ **预置容量**：[https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ProvisionedReadCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ProvisionedReadCapacityUnits) 和 [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ProvisionedWriteCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ProvisionedWriteCapacityUnits) 显示配置的限额。
## 解决过程
### 增加表吞吐能力
在未启用自动扩缩和您需要立即增加容量时，请使用此过程。
1. 使用 DynamoDB 控制台、AWS CLI 或 SDK 更新表的预置容量：
+ **对于读取容量**：增加 [https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_ProvisionedThroughput.html](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_ProvisionedThroughput.html) 参数，该参数指定每秒消耗的最大强一致性读取次数，超过该值后 DynamoDB 将限制请求。
+ **对于写入容量**：增加 [https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_ProvisionedThroughput.html](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_ProvisionedThroughput.html) 参数，该参数指定每秒消耗的写入次数，超过该值后 DynamoDB 将限制请求。
1. 确认您的新容量设置未超过[每个表的吞吐量配额](ServiceQuotas.md)，并且您的账户总消耗量低于所在区域的[每个账户的吞吐量配额](ServiceQuotas.md)。如果即将接近这些限额，请考虑改为[切换到按需容量模式](#procedure-switch-ondemand)。
### 配置表自动扩缩以调整表或 GSI 的读取或写入容量
将 DynamoDB [自动扩缩](AutoScaling.md)配置为根据流量模式自动调整读取或写入容量。您可以为表和 GSI 单独配置自动扩缩，并单独控制读取和写入容量单位。
1. 为表或 GSI 上的读取容量和/或写入容量启用自动扩缩。
1. 设置目标利用率百分比，为流量峰值留出余地。
**注意**
较低的目标利用率会增加成本和扩展频率。低于 40% 的目标可能会导致预置过度。监控使用模式和成本，在性能和效率之间取得平衡。
1. 设置容量界限：
+ **最小 RCU/WCU**：在低流量时段保持足够容量。
+ **最大 RCU/WCU**：可满足峰值流量需求，并且能够防止扩展事件失控。
有关配置和管理 DynamoDB 自动扩缩的指南，请参阅[使用 DynamoDB 自动扩缩自动管理吞吐能力](AutoScaling.md)。
**注意**
自动扩缩响应流量变化通常需要几分钟时间。对于突然的流量高峰，在自动扩缩调整的同时，表的容量爆增功能可提供即时保护。为目标利用率配置足够的余量，以便为扩展操作留出时间，并保留容量爆增功能以应对意外需求。
### 优化表或索引的读取或写入自动扩缩设置
当启用了[自动扩缩](AutoScaling.md)但仍出现节流时，请使用此过程。您可以针对表和全局二级索引（GSI）单独调整自动扩缩设置，并单独控制读取和写入容量单位。
+ **调整目标使用量**：请考虑降低表或 GSI 的目标使用量，以便在发生节流之前提前触发扩展。完成这些调整后，请务必监控流量。有关容量消耗和成本影响的更多信息，请参阅[配置表自动扩缩以调整表或 GSI 的读取或写入容量](#provisioned-capacity-configure-autoscaling)。
+ **查看容量边界**：确保您的最小和最大容量设置与实际工作负载模式保持一致。
### 切换到按需容量模式。
有关切换容量模式的一般信息，请参阅[在 DynamoDB 中切换容量模式时的注意事项](bp-switching-capacity-modes.md)。请参阅服务配额来了解与[切换模式时的约束](troubleshooting-throttling-diagnostics.md)相关的具体信息。
### 增加 GSI 吞吐能力
当 GSI 上未启用自动扩缩或您需要立即增加容量时，请使用此过程。
1. 使用 DynamoDB 控制台、AWS CLI 或 SDK 更新 GSI 的预置容量：
+ **对于读取容量**：增加特定 GSI 的 [https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_GlobalSecondaryIndexUpdate.html](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_GlobalSecondaryIndexUpdate.html) 参数，该参数指定 GSI 每秒可以消耗的最大读取次数，超过该值后 DynamoDB 将限制请求。请注意，GSI 仅支持最终一致性读取。
+ **对于写入容量**：增加特定 GSI 的 [https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_GlobalSecondaryIndexUpdate.html](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_GlobalSecondaryIndexUpdate.html) 参数，该参数指定 GSI 每秒可以消耗的最大写入次数，超过该值后 DynamoDB 将限制请求。
1. 确保 GSI 的预置吞吐量能力保持在[每个账户和每个表的吞吐量配额](ServiceQuotas.md)之内。
## 其他资源
+ 有关处理 DynamoDB 预置容量表中流量峰值的详细信息（包括从利用自动扩缩和容量爆增功能，到利用策略性节流管理等各种策略），请参阅 [Handle traffic spikes with Amazon DynamoDB provisioned capacity](https://aws.amazon.com/blogs//database/handle-traffic-spikes-with-amazon-dynamodb-provisioned-capacity/)。
+ 有关如何使用 cron 表达式调度扩展策略的信息，请参阅 [Optimize costs by scheduling provisioned capacity for DynamoDB](https://aws.amazon.com/blogs/database/optimize-costs-by-scheduling-provisioned-capacity-for-amazon-dynamodb/)。
+ 有关监控和分析预置容量模式下 DynamoDB 表的吞吐量利用率模式的实操信息，请参阅 [How to evaluate throughput utilization for Amazon DynamoDB tables in provisioned mode](https://aws.amazon.com/blogs/database/how-to-evaluate-throughput-utilization-for-amazon-dynamodb-tables-in-provisioned-mode/)。
# 3. 超过账户限额
按需表没有预置容量级别可供管理，但是 DynamoDB 会强制执行账户级别的吞吐量限制，以防止执行失控并确保所有客户公平使用资源。这些每个表的账户限额作为可调整的保障措施，可以针对各个账户与区域的组合来设定。当您的读取或写入消耗速率超过这些限额时，DynamoDB 会在节流异常中返回 `AccountLimitExceeded` 节流原因类型。当表没有配置自定义的最大吞吐量设置时，会自动应用默认的每个表的账户限额。您可以选择配置最大吞吐量设置，来更精细地控制成本，实现更好的可预测性；如果您的应用程序的需求超过默认限额，则可通过 [Amazon DynamoDB 中的配额](ServiceQuotas.md) 控制台请求增加配额。
## 账户超出限额的缓解措施
本节针对账户限额节流场景提供解决方法指导。使用本指南之前，请确保您根据应用程序的异常处理确定了具体的节流原因，并确定了受影响资源的 Amazon 资源名称（ARN）。有关检索节流原因和识别受限制资源的信息，请参阅[DynamoDB 节流诊断框架](throttling-diagnosing-workflow.md#throttling-diagnosing)。
在深入研究具体的节流场景之前，请先确定是否确实需要采取行动：
+ **评估性能影响**：检查在出现节流情况时，您的应用程序是否仍能满足性能要求。许多应用程序可在达到或接近账户限额的情况下成功运行，尤其是在批量操作或数据迁移期间。
+ **查看节流模式**：如果节流是间歇性的，并且应用程序可以有效地处理重试，则当前限额可能足以满足您的工作负载。
如果您的应用程序即便在偶尔达到账户限额时，性能也可以接受，则您可以选择仅仅对情况进行监控，而不是立即实施更改。
如果您确定节流导致了不可接受的性能问题或可靠性问题，请在下面选择特定的节流原因来查找推荐的缓解选项：
+ [TableReadAccountLimitExceeded](#throttling-table-read-account-limit)
+ [TableWriteAccountLimitExceeded](#throttling-table-write-account-limit)
+ [IndexReadAccountLimitExceeded](#throttling-index-read-account-limit)
+ [IndexWriteAccountLimitExceeded](#throttling-index-write-account-limit)
### TableReadAccountLimitExceeded
**何时出现**
表的读取消耗量，超过了所在区域的账户级别每个表的读取吞吐量配额。您可以在 [常见的诊断和监控方法](#account-limit-exceeded-diagnosis-monitoring) 中监控 CloudWatch 指标来分析节流事件。
**解决方法**
按照以下步骤解决此节流问题：
+ **请求提高限额**：
请求提高每个表的读取吞吐量限额（配额代码 L-CF0CBE56）。有关如何提交请求的详细步骤，请参阅[请求增加每个表的配额](#account-limit-request-per-table-quota)。
### TableWriteAccountLimitExceeded
**何时出现**
表的写入消耗量，超过了所在区域的账户级别每个表的写入吞吐量配额。您可以在 [常见的诊断和监控方法](#account-limit-exceeded-diagnosis-monitoring) 中监控 CloudWatch 指标来分析节流事件。
**解决方法**
按照以下步骤解决此节流问题：
+ **请求增加配额**：请求增加每个表的写入吞吐量限额（配额代码 L-AB614373）。有关如何提交请求的详细步骤，请参阅[请求增加每个表的配额](#account-limit-request-per-table-quota)。
### IndexReadAccountLimitExceeded
**何时出现**
指向全局二级索引（GSI）的读取操作消耗的吞吐量，超过当前 AWS 区域中您的账户的每个表的读取配额所允许的吞吐量。账户级别每个表的读取吞吐量配额，是表及其所有 GSI 的吞吐量总和。您可以在 [常见的诊断和监控方法](#account-limit-exceeded-diagnosis-monitoring) 中监控 CloudWatch 指标来分析节流事件。
**解决方法**
根据账户的容量分布选择合适的解决方法：
+ **请求增加配额**：请求增加每个表的读取吞吐量限额（配额代码 L-CF0CBE56）。有关如何提交请求的详细步骤，请参阅[请求增加每个表的配额](#account-limit-request-per-table-quota)。
+ **优化 GSI 使用情况**：[查看 GSI 设计和查询模式](#account-limit-optimize-gsi-projections)，减少不必要的读取容量消耗。
### IndexWriteAccountLimitExceeded
**何时出现**
对基表的写入操作生成了对 GSI 的相应更新，这些更新的总和超过了 AWS 区域账户级别每个表的写入吞吐量配额。当基表项目包含通过某个 GSI 编制索引的属性时，对基表项目的每个写入操作就会触发对该 GSI 的相应写入操作。这些写入操作总和计入每个表的写入吞吐量配额。您可以监控 [常见的诊断和监控方法](#account-limit-exceeded-diagnosis-monitoring) 中的 CloudWatch 指标，来分析这些节流事件的模式和时机，并确定哪些操作导致了 GSI 写入活动过多。
**解决方法**
根据账户的容量分布选择合适的解决方法：
+ **请求增加配额**：请求增加[每个表的写入吞吐量限额](#account-limit-request-per-table-quota)（配额代码 L-AB614373），以适应来自基表操作的更高 GSI 写入流量。每个表的写入吞吐量配额应用到整个表，包括其所有 GSI。有关如何提交请求的详细步骤，请参阅[请求增加每个表的配额](#account-limit-request-per-table-quota)。
+ **优化 GSI 投影**：[检查 GSI 投影和设计](#account-limit-optimize-gsi-projections)，来减少对 GSI 的写入量。
## 常见的诊断和监控方法
在对超出账户限额导致的节流事件进行故障排除时，您可以通过多个 CloudWatch 指标来确定是达到每个表还是账户级别的限制，以及了解您的容量分配模式。
**关键 CloudWatch 指标**
监控以下关键指标来诊断账户限额节流问题：
+ **账户限额节流事件**：[https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadAccountLimitThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadAccountLimitThrottleEvents) 和 [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteAccountLimitThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteAccountLimitThrottleEvents) 跟踪什么时候由于超出账户级别限额导致请求受限。[https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents) 和 [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents) 跟踪什么时候读取或写入请求超出了预置容量。
+ **按资源划分的容量消耗[：每个表和 GSI 的 `ConsumedReadCapacityUnits`](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits)** 和 [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits) 显示各自的资源使用情况。
+ **账户级别的消耗**：使用 CloudWatch 指标数学表达式对所有表和 GSI 使用的容量求和，来监控账户的总使用量。
## 解决过程
### 请求增加每个表的配额
如果应用程序需要在超出当前每个表的吞吐量限额的情况下运行，您应使用以下步骤提交增加配额的请求。在一个特定区域中，您的 AWS 账户中的每个 DynamoDB 表（及其所有关联的 GSI）都受这些吞吐量配额的约束。这些配额表示任何单个表及其 GSI 总共可以使用的最大读取或写入容量，配额独立应用于每个表，而不是作为账户中所有表的容量总和。
或者，您也可以通过按照每个表或每个 GSI 配置最大按需吞吐量设置，来设置较低的限额。
1. 确定需要增加的具体配额：
+ **每个表的读取吞吐量限额**（配额代码 L-CF0CBE56）：每个表默认 40000 个 RCU
+ **每个表的写入吞吐量限额**（配额代码 L-AB614373）：每个表默认 40000 个 WCU
1. 使用 [AWS Service Quotas 控制台](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)请求增加配额：
+ 在 Service Quotas 中导航到 DynamoDB 服务
+ 使用配额代码查找相应的配额
+ 根据您的预计峰值使用量申请增加配额
1. 提供增加配额的理由，包括：
+ 当前的使用模式和峰值流量需求
+ 增加容量的业务理由
+ 何时需要增加容量的时间表
**注意**
配额增加的处理通常需要 24-48 小时。请相应地计划您的请求，并在等待批准时考虑采取临时的缓解策略。
### 优化 GSI 投影和设计
优化全局二级索引（GSI）投影和设计，来减少容量消耗并提高性能。
**选择性投影策略**
如果您的查询只需要访问几个属性，则只投影这几个属性，这样在基表项目发生更改时，可以减少写入 GSI 的数据量。有关投影类型的详细信息，请参阅[全局二级索引的投影](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/GSI.html#GSI.Projections)。
1. 分析查询模式：检查应用程序的查询模式，确定哪些属性实际上是通过 GSI 访问的。
1. 使用选择性投影：仅投影查询中实际需要的属性，从而减少写入量。
1. 考虑使用 `KEYS_ONLY`：如果查询只需要关键属性，请使用 `KEYS_ONLY` 投影来尽可能减少写入量。
1. 平衡读取与写入的权衡：对较少的属性进行投影可以减少写入容量消耗，但可能需要额外的基表读取。
**稀疏 GSI 实施**
稀疏 GSI 仅包含已编制索引的属性的项目，而不是基表中的所有项目。当您经常查询特定数据子集时，这可以减少分区密度并提高性能。
1. 设计仅包含具有特定属性值的项目的 GSI。
1. 通过仅在应编制索引的项目上设置 GSI 分区键属性，来实施条件索引。
1. 在稀疏 GSI 中使用复合键（例如 status\$1timestamp），进一步在编制了索引的项目子集中分配流量。
有关实施这些策略的更多信息，请参阅[在 DynamoDB 中使用二级索引的最佳实践](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/bp-indexes.html)。
# 4. 超出按需最大吞吐量
配置[按需](on-demand-capacity-mode.md)表或 GSI 时，您可以选择在表或索引级别设置最大吞吐量限制（[https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxReadRequestUnits](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxReadRequestUnits) 和 [https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxWriteRequestUnits](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxWriteRequestUnits)），以防止成本失控或者防止下游系统过载。有关最大吞吐量的更多信息，请参阅 [DynamoDB 按需表的最大吞吐量](on-demand-capacity-mode-max-throughput.md)。
当您的读取或写入消耗量超过这些自行施加的限额时，超出限额的其他请求会立即收到节流响应。DynamoDB 会返回异常以及 `MaxOnDemandThroughputExceeded` 节流原因类型，指示哪个资源已达到其吞吐量边界。
## 超过按需最大吞吐量导致的节流
此部分针对超出按需最大吞吐量导致的节流场景提供解决方法指导。使用本指南之前，请确保您根据应用程序的异常处理确定了具体的节流原因，并确定了受影响资源的 Amazon 资源名称（ARN）。有关检索节流原因和识别受限制资源的信息，请参阅[DynamoDB 节流诊断框架](throttling-diagnosing-workflow.md#throttling-diagnosing)。
在深入研究具体的节流场景之前，请首先考虑定是否确实需要采取行动：
+ **评估最大吞吐量设置**：这些限制是专门配置的，目的是控制成本或保护下游系统。如果您收到 `MaxOnDemandThroughputExceeded` 节流事件，则表示您的限额按设计发挥了作用。请考虑提高这些限额是否符合您最初的成本控制或系统保护目标。
+ **评测应用程序影响**：确定节流是否确实给您的应用程序或用户造成了问题。如果您的应用程序能够有效地处理重试操作，并且尽管偶尔会出现节流情况，但仍能满足性能要求，那么保持当前限额可能是合适的做法。
+ **查看流量模式**：分析节流代表的是预期的流量模式还是异常峰值。对于持续超过限额的可预测的重复流量模式，调整最大吞吐量设置可能会保障更好的性能。对于临时峰值，相比提升限额，实施更好的请求分配策略可能更合适。
如果您在考虑之后确定需要调整最大吞吐量设置，请参阅以下特定节流场景，了解针对性的修复选项：
+ [TableReadMaxOnDemandThroughputExceeded](#throttling-diagnostic-table-read-max-ondemand)
+ [TableWriteMaxOnDemandThroughputExceeded](#throttling-diagnostic-table-write-max-ondemand)
+ [IndexReadMaxOnDemandThroughputExceeded](#throttling-diagnostic-index-read-max-ondemand)
+ [IndexWriteMaxOnDemandThroughputExceeded](#throttling-diagnostic-index-write-max-ondemand)
### TableReadMaxOnDemandThroughputExceeded
**何时出现**
按需表超过了所配置的最大读取吞吐能力。您可以在 [常见的诊断和监控方法](#ondemand-capacity-exceeded-diagnosis-monitoring) 中监控 CloudWatch 指标来分析节流事件。
**修复方案**
请考虑采取以下步骤来解决节流事件：
+ **提高最大吞吐量限额**：使用 [DynamoDB 控制台](https://console.aws.amazon.com/dynamodb)、[AWS CLI](/amazondynamodb/latest/developerguide/AccessingDynamoDB.html#Tools.CLI) 或 DynamoDB `[UpdateTable](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_UpdateTable.html)` API，增加受影响表的 [https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxReadRequestUnits](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxReadRequestUnits) 值，然后进行监控和调整。通过这种方法，在发生节流之前，表能够处理更高的读取吞吐量。
+ **移除最大限额**：将 `MaxReadRequestUnits` 设置为 `-1` 可取消上限，实现按需扩展，直至达到账户级别的吞吐量配额。这会移除您的自定义限额，但仍保持 AWS 账户级别的保护措施。但是，取消此限额后，请务必密切监控支出，因为在达到账户级别配额之前，您的表现在可以消耗更多的容量。
### TableWriteMaxOnDemandThroughputExceeded
**何时出现**
按需表超过了所配置的最大写入吞吐能力。您可以在 [常见的诊断和监控方法](#ondemand-capacity-exceeded-diagnosis-monitoring) 中监控 CloudWatch 指标来分析节流事件。
**修复方案**
请考虑采取以下步骤来解决节流事件：
+ **提高最大吞吐量限额**：使用 [DynamoDB 控制台](https://console.aws.amazon.com/dynamodb)、[AWS CLI](/amazondynamodb/latest/developerguide/AccessingDynamoDB.html#Tools.CLI) 或 DynamoDB `[UpdateTable](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_UpdateTable.html)` API，增加受影响表的 [https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxWriteRequestUnits](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxWriteRequestUnits) 值，然后进行监控和调整。
+ **移除最大限额**：将 `MaxWriteRequestUnits` 设置为 `-1` 可取消上限，实现按需扩展，直至达到账户级别的吞吐量配额。这会移除您的自定义限额，但仍保持 AWS 账户级别的保护措施。但是，取消此限额后，请务必密切监控支出，因为在达到账户级别配额之前，您的表现在可以消耗更多的容量。
### IndexReadMaxOnDemandThroughputExceeded
**何时出现**
在按需模式下，向某个 GSI 发出的读取请求超过了为 GSI 配置的最大读取吞吐能力。您可以在 [常见的诊断和监控方法](#ondemand-capacity-exceeded-diagnosis-monitoring) 中监控 CloudWatch 指标来分析节流事件。
**修复方案**
请考虑采取以下步骤来解决节流事件：
+ **提高 GSI 最大吞吐量限额**：使用 [DynamoDB 控制台](https://console.aws.amazon.com/dynamodb)、[AWS CLI](/amazondynamodb/latest/developerguide/AccessingDynamoDB.html#Tools.CLI) 或 DynamoDB `[UpdateTable](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_UpdateTable.html)` API，增加受影响 GSI 的 [https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxReadRequestUnits](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxReadRequestUnits) 值，然后进行监控和调整。
+ **移除 GSI 最大限额**：将 GSI 的 `MaxReadRequestUnits` 设置为 `-1` 可取消上限，实现按需扩展，直至达到账户级别的吞吐量配额。这会移除您的自定义限额，但仍保持 AWS 账户级别的保护措施。但是，取消此限额后请务必密切监控支出。
### IndexWriteMaxOnDemandThroughputExceeded
**何时出现**
按需模式下，更新基表中的项目会触发向某个 GSI 的写入，超过了为 GSI 配置的最大写入吞吐能力，从而导致[背压节流](gsi-throttling.md)。您可以在 [常见的诊断和监控方法](#ondemand-capacity-exceeded-diagnosis-monitoring) 中监控 CloudWatch 指标来分析节流事件。
**修复方案**
请考虑采取以下步骤来解决节流事件：
+ **提高 GSI 最大吞吐量限额**：使用 [DynamoDB 控制台](https://console.aws.amazon.com/dynamodb)、[AWS CLI](/amazondynamodb/latest/developerguide/AccessingDynamoDB.html#Tools.CLI) 或 DynamoDB `[UpdateTable](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_UpdateTable.html)` API，增加受影响 GSI 的 [https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxWriteRequestUnits](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxWriteRequestUnits) 值，然后进行监控和调整。
+ **移除 GSI 最大限额**：将 GSI 的 `MaxWriteRequestUnits` 设置为 `-1` 可取消上限，实现按需扩展，直至达到账户级别的吞吐量配额。这会移除您的自定义限额，但仍保持 AWS 账户级别的保护措施。但是，取消此限额后请务必密切监控支出。
## 常见的诊断和监控方法
在对超出按需最大吞吐量导致的节流事件进行故障排除时，您可以利用多种 CloudWatch 指标来确定根本原因和扩展模式。
**关键 CloudWatch 指标**
监控以下关键指标，以便诊断超出最大吞吐量导致的节流：
+ **最大吞吐量节流事件**：[https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadMaxOnDemandThroughputThrottleEvents](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadMaxOnDemandThroughputThrottleEvents) 和 [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteMaxOnDemandThroughputThrottleEvents](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteMaxOnDemandThroughputThrottleEvents) 跟踪什么时候由于超出最大限额导致请求受限。[https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents) 和 [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents) 跟踪什么时候读取或写入请求超出了预置容量。
+ **当前为表或全局二级索引配置的最大吞吐量**：[https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#OnDemandMaxReadRequestUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#OnDemandMaxReadRequestUnits) 和 [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#OnDemandMaxWriteRequestUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#OnDemandMaxWriteRequestUnits) 显示当前的最大容量限额。
+ **实际容量消耗**：[https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits) 和 [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits) 显示实际使用模式。
**分析方法**
按照以下步骤，对超出按需最大吞吐量的情况进行诊断：
1. 将已消耗的容量与最大容量限额进行比较，检查消耗量是否持续接近或超过最大限额。
1. 查看节流事件的频率和时间以确定模式。查找与节流事件相吻合的消耗容量突然增加的情况。
1. 使用 [CloudWatch Contributor Insights](contributorinsights_HowItWorks.md) 来确定哪些项目或分区键消耗了最多的容量。