1. 超过键范围吞吐量（热分区）
Amazon DynamoDB 在分区级别对表和全局二级索引（GSI）都会实施特定的吞吐量限制。每个分区都有每秒最大读取容量单位（RCU）和写入容量单位（WCU）数量。当分区上集中的流量超过这些限额时，就会遇到节流情况，而其他操作的使用量可能并不高，从而产生“热分区”。DynamoDB 的分区级别节流对读取和写入操作是独立的，分区可能会限制读取，而写入操作正常，或者反之。即使您的表或 GSI 具有足够的总容量，也可能发生这种节流。如需详细了解：
-
DynamoDB 分区限额以及预防热分区的有效分区键设计方法，请参阅在 DynamoDB 中设计并有效使用分区键的最佳实践。
-
一般分区概念和数据分布，请参阅 DynamoDB 中的分区。
-
有关管理分区键和吞吐量的更多指导和实际场景，请参阅其他资源。
当单个分区超过其吞吐量限额时，DynamoDB 会在节流异常中返回 KeyRangeThroughputExceeded 节流原因类型。该信息标识出现高流量的分区，以及哪种操作类型（读取或写入）导致了问题。
超出键范围吞吐量缓解措施
本节针对分区级别节流场景提供解决方法指导。使用本指南之前，请确保您根据应用程序的异常处理确定了具体的节流原因，并确定了受影响资源的 Amazon 资源名称（ARN）。有关检索节流原因和识别受限制资源的信息，请参阅DynamoDB 节流诊断框架。
在深入研究特定节流场景之前，请首先检查问题是否会自动解决：
-
DynamoDB 通常通过其自动拆分热分区机制来适应热分区。如果您看到节流事件在短时间后停止，则表可能已经通过拆分热分区来适应流量。拆分分区后，每个新分区都会处理一小部分键空间，这有助于更均匀地分配负载。许多情况下无需进一步操作，因为 DynamoDB 已自动解决问题。
有关拆分热分区机制的更多信息，请参阅其他资源。
如果节流问题仍然存在，请参阅下面的特定节流方案，了解针对性的补救选项：
TableReadKeyRangeThroughputExceeded
何时出现
DynamoDB 表中一个或多个分区的消耗速率，超过了分区的读取吞吐量限额。无论您的表预置了多大的总容量，这种节流情况都可能会出现，并且会影响预置表和按需表。您可以在 常见的诊断和监控方法 中监控 CloudWatch 指标来分析节流事件。
修复方案
请考虑采取以下步骤来解决节流事件：
对于预置模式和按需模式：
-
预热容量：如果节流情况仍然存在，请检查您的表是否受本身的了解 DynamoDB 热吞吐量容量限制。使用热吞吐量或提前增加读取预置容量，来应对预期的流量增长。增加热吞吐量可以提高表处理突然出现的流量峰值的能力，防止出现节流。随着时间的推移，如果实际吞吐量始终接近热吞吐量水平，则 DynamoDB 可能会根据观察到的使用模式，拆分繁忙的分区。
-
识别热键：如果表没有自动解决问题，并且您的热吞吐量很高或者提高热吞吐量无济于事，则您需要确定具体的热键。使用 使用 CloudWatch Contributor Insights 识别热键 确定是否有任何特定的分区键值过热。这是有效确定缓解工作的第一步。请注意，识别热键并不总是那么简单，尤其是在具有滚动的热分区（随着时间的推移不同的分区变热）或由扫描等操作触发节流时。对于这些复杂的场景，您可能需要分析应用程序的访问模式，并将其与节流事件的时间关联起来。
-
根据使用案例考虑使用最终一致性读取：从强一致性读取切换到最终一致性读取，这可以将消耗的 RCU 减半，并直接将有效读取容量翻番。有关实施最终一致性读取以减少读取容量消耗的最佳实践，请参阅 DynamoDB 读取一致性。
-
改进分区键设计：作为长期解决方案，请考虑改进分区键设计，在分区之间更均匀地分配访问权限。这种方法通常可以解决根本原因，提供了针对热分区问题的最全面的解决方法。但是，这种方法需要精心规划，因为会涉及到巨大的迁移挑战。
TableWriteKeyRangeThroughputExceeded
何时出现
DynamoDB 表中一个或多个分区的消耗速率，超过了分区的写入吞吐量限额。无论您的表预置了多大的总容量，这种节流情况都可能会出现，并且会影响预置表和按需表。您可以在 常见的诊断和监控方法 中监控 CloudWatch 指标来分析节流事件。
修复方案
请考虑采取以下步骤来解决节流事件：
对于预置模式和按需模式：
-
预热容量：如果节流情况仍然存在，请检查您的表是否受本身的了解 DynamoDB 热吞吐量容量限制。使用热吞吐量或提前增加写入预置容量，来应对预期的流量增长。增加热吞吐量可以提高表处理突然出现的流量峰值的能力，防止出现节流。随着时间的推移，如果实际吞吐量始终接近热吞吐量水平，则 DynamoDB 可能会根据观察到的使用模式，拆分繁忙的分区。
-
识别热键：如果表没有自动解决问题，并且您的热吞吐量很高或者提高热吞吐量无济于事，则您需要确定具体的热键。使用 使用 CloudWatch Contributor Insights 识别热键 确定是否有任何特定的分区键值过热。这是有效确定缓解工作的第一步。请考虑以下常见模式：
-
如果您在节流数据中频繁看到相同的分区键，则表示这是集中热键。
-
如果您没有看到重复出现的键，而是以有序的方式写入数据（例如顺序时间戳，或者遵循键空间顺序的基于扫描的操作），则可能存在滚动的热分区，当写入操作在键空间中移动时，随时间的推移不同的键会变热。
请注意，写入节流可能会发生在
BatchWriteItem等操作上或者会同时影响多个项目的事务上。当BatchWriteItem请求中的单个项目受到限制时，DynamoDB 不会将这些节流错误传播到应用程序代码。相反，DynamoDB 会在响应中返回有关未处理项目的信息，应用程序必须重试这些特定项目来处理这种情况。对于事务，如果任何项目出现了节流事件，则整个操作将失败并返回TransactionCanceledException。对于这些复杂的场景，您可能需要分析应用程序的写入模式和数据摄取工作流，将这些信息与发生节流事件的时间关联起来，并实施适当的重试处理策略。 -
-
改进分区键设计：作为长期解决方案，请考虑改进分区键设计，在分区之间更均匀地分配访问权限。这种方法通常可以解决根本原因，提供了针对热分区问题的最全面的解决方法。但是，这种方法需要精心规划，因为会涉及到巨大的迁移挑战。
IndexReadKeyRangeThroughputExceeded
何时出现
DynamoDB GSI 中一个或多个分区的消耗速率，超过了分区的读取吞吐量限额。无论您的 GSI 预置了多大的总容量，这种节流情况都可能会出现，并且会影响预置表和按需表。您可以在 常见的诊断和监控方法 中监控 CloudWatch 指标来分析节流事件。
修复方案
请考虑采取以下步骤来解决节流事件：
-
预热容量：如果节流情况仍然存在，请检查您的 GSI 是否受本身的了解 DynamoDB 热吞吐量容量限制。使用热吞吐量或提前增加读取预置容量，来应对预期的流量增长。增加热吞吐量可以提高 GSI 处理突然出现的流量峰值的能力，防止出现节流。随着时间的推移，如果实际吞吐量始终接近热吞吐量水平，则 DynamoDB 可能会根据观察到的使用模式，拆分繁忙的分区。
-
识别热键：如果 GSI 没有自动解决问题，并且您的热吞吐量很高或者提高热吞吐量无济于事，则您需要确定具体的热键。使用 使用 CloudWatch Contributor Insights 识别热键 确定是否有任何特定的分区键值过热。这是有效确定缓解工作的第一步。请注意，对于 GSI，分区键分布可能与您的基表有很大不同，从而造成不同的热键模式。
-
重新设计 GSI 分区键：考虑您的 GSI 键设计是否可能会造成人为的热点（例如状态标志、仅限日期的键或布尔属性），将读取集中在少数分区上。请考虑使用复合键，将低基数属性与高基数属性相结合（例如，“ACTIVE#customer123”而不是仅用“ACTIVE”），或者对影响 GSI 分布的基表项目应用在 DynamoDB 表中使用写入分片来均匀分配工作负载技术，以便在多个分区之间分配写入操作。虽然查询分片数据需要额外的应用程序逻辑来汇总结果，但这种方法可以更均匀地分配访问模式来防止节流。
IndexWriteKeyRangeThroughputExceeded
何时出现
DynamoDB GSI 中一个或多个分区的消耗速率，超过了分区的写入吞吐量限额。无论您的 GSI 预置了多大的总容量，这种节流情况都可能会出现，并且会影响预置表和按需表。您可以在 常见的诊断和监控方法 中监控 CloudWatch 指标来分析节流事件。
修复方案
请考虑采取以下步骤来解决节流事件：
-
重新设计 GSI 分区键：检查您的 GSI 分区键设计，确保其基数（唯一性）足以均匀地分配写入操作。导致 GSI 写入节流的一个常见原因是使用低基数属性作为 GSI 分区键（例如只有几个可能值的状态标志）。即使您的基表具有分布良好的分区键，如果其分区键将写入集中到少量的值上，则 GSI 仍然会遇到热分区。例如，如果 80% 的项目具有 status="ACTIVE"，则这会在基于状态的 GSI 中造成非常热的分区。请考虑使用复合键，将低基数属性与高基数属性相结合（例如，“ACTIVE#customer123”而不是仅用“ACTIVE”），或者对影响 GSI 分布的基表项目应用在 DynamoDB 表中使用写入分片来均匀分配工作负载技术，以便在多个分区之间分配写入操作。虽然查询分片数据需要额外的应用程序逻辑来汇总结果，但这种方法可以更均匀地分配访问模式来防止节流。
-
预热容量：检查您的 GSI 是否受本身的了解 DynamoDB 热吞吐量容量限制。使用热吞吐量或提前增加读取预置容量，来应对预期的流量增长。增加热吞吐量可以提高 GSI 处理突然出现的流量峰值的能力，防止出现节流。随着时间的推移，如果实际吞吐量始终接近热吞吐量水平，则 DynamoDB 可能会根据观察到的使用模式，拆分繁忙的分区。
-
优化 GSI 投影：应用优化 GSI 投影技术来减少对 GSI 的写入量。对更少的属性进行投影，可以显著减少每个 GSI 更新消耗的写入容量。
常见的诊断和监控方法
在对分区级别的节流问题进行故障排除时，可以利用多种 CloudWatch 指标来识别热分区并确认根本原因。
关键 CloudWatch 指标
监控以下关键指标以诊断分区级别的节流：
-
分区级别的节流事件：
ReadKeyRangeThroughputThrottleEvents和WriteKeyRangeThroughputThrottleEvents跟踪单独分区何时超过其吞吐量限额。ReadThrottleEvents和WriteThrottleEvents跟踪任意读取或写入请求何时超过其预置容量。 -
容量消耗：
ConsumedReadCapacityUnits和ConsumedWriteCapacityUnits显示整体使用模式。
解决过程
使用 CloudWatch Contributor Insights 识别热键
使用此过程来确定哪些分区键导致了节流。
-
在表或 GSI 上启用 CloudWatch Contributor Insights 来跟踪最受限的键。考虑保持 CloudWatch Contributor Insights 的持续启用，使用受限的键模式来实时获取节流警报。此模式仅关注受限制的请求，仅在出现节流问题时处理事件。这种针对性的监控是一种经济高效的方式，可以确保持续检测节流问题。
-
确定哪些键导致了热分区问题。
-
（在启用了完整的访问的键和受限的键模式时）分析一段时间内的访问模式，确定热键是否一致或是否发生在特定时段。
改进分区键设计
如果您可以修改表架构以更好地在分区之间分配流量时，请使用此方法。在可以使用此方法时，这是解决热分区问题的最有效的长期解决方案。理想情况下，应在初始表设计阶段仔细考虑分区键的设计。
重新设计分区键意味着对数据模型的根本性更改，会影响整个应用程序生态系统。在继续使用此方法之前，请认真考虑以下重要限制：
-
数据迁移的复杂性：重新设计分区键需要迁移现有的全部数据，对于大型表来说，这会占用大量资源且非常耗时。
-
应用程序代码更改：对表执行读取或写入操作的所有应用程序代码都必须进行更新，以便使用新的键结构。
-
生产影响：迁移到新的键设计时，在过渡期间通常会产生停机时间或者需要采用复杂的双重写入策略。
有关分区键设计的全面指导和所应遵循的原则，请参阅在 DynamoDB 中设计并有效使用分区键的最佳实践和在 DynamoDB 中设计分区键来分配工作负载。
优化 GSI 投影
查看应用程序的查询模式，来确切地确定查询 GSI 时需要哪些属性可用，并仅对这些属性进行投影。当您更新未投影到 GSI 中的属性时，就不会对 GSI 执行写入操作，从而减少更新期间的写入吞吐量消耗。这种针对性的投影策略可以优化性能和成本，同时仍可支持应用程序的查询要求。请注意，对较少的属性进行投影可以减少写入容量消耗，但可能需要额外的基表读取。
有关高效投影策略的更多信息，请参阅在 DynamoDB 中使用二级索引的最佳实践。
其他资源
以下博客文章提供了本指南中所涵盖概念的动手操作示例和实用细节：
-
有关使用 GSI 分配读取流量的更多信息，请参阅 Using Global Secondary Indexes to create eventually consistent secondary indexes in Amazon DynamoDB
。 -
有关扩展 DynamoDB 和管理热分区的动手操作指南，请参阅 Part 1: Scaling DynamoDB - How partitions, hot keys, and split for heat impact performance
。 -
有关 DynamoDB 的拆分热分区机制的工作原理、其优势和实施细节的详细信息，请参阅 Part 3: Summary and best practices
。 -
有关详细的写入分片策略，请参阅在 DynamoDB 表中使用写入分片来均匀分配工作负载。