解决预置模式下的节流问题
如果您的应用程序超出了表或索引的预置吞吐容量，则会发生请求节流。节流会阻止您的应用程序消耗太多容量单位。当 DynamoDB 对读取或写入操作进行节流时，它会将 ProvisionedThroughputExceededException 返回给调用方。随后，应用程序可以采取相应的措施，例如，在重试请求之前等待一段较短的间隔。
要解决看似与节流相关的问题，重要的第一步是要确认节流是来自 DynamoDB 还是来自应用程序。
本主题讨论如何解决预置容量模式的常见节流问题。以下是一些常见场景以及有助于解决这些问题的可能步骤。
DynamoDB 表似乎有足够的预置容量，但请求受到节流
当吞吐量低于每分钟平均值但超过每秒可用量时，就会发生这种情况。DynamoDB 仅向 CloudWatch 报告分钟级指标，然后将这些指标计算为一分钟的总和并求平均值。但是 DynamoDB 本身会应用每秒的速率限制。因此，如果在这分钟的一小段时间（例如几秒钟或更短）内出现了过多的吞吐量，则这分钟剩余时间的请求可能会受到限制。
例如，如果我们在表上预置了 60 WCU，那么它可以在 1 分钟内执行 3600 次写入操作。但是，如果所有 3600 个 WCU 请求都在同一秒内到达，那么那一分钟的剩余时间将被节流。
解决这个问题的一种方法是在 API 调用中添加一些抖动和指数退避。有关更多信息，请参阅这篇有关退避和抖动
自动扩缩已启用，但表仍会被节流
这可能发生在流量突然猛增期间。当 2 个数据点在 1 分钟内超过所配置的目标利用率值时，可以触发自动扩缩。因此，之所以可以进行自动扩缩，是因为消耗的容量持续超出目标利用率 2 分钟。但是，如果峰值间隔超过一分钟，则可能无法触发自动扩缩。
同样，当 15 个连续的数据点低于目标利用率时，可以触发缩减事件。无论哪种情况，在触发自动扩缩之后，都会调用 UpdateTable API 操作。然后可能需要几分钟的时间才能更新表或索引的预置容量。在此期间，任何超过表的先前预置容量的请求都将被节流。
总之，自动扩缩要求连续的数据点超出目标利用率值，才能纵向扩展 DynamoDB 表。因此，建议不要将自动扩缩作为处理高峰工作负载的解决方案。有关更多信息，请参阅自动扩缩成本优化文档。
热键可能会导致节流问题
在 DynamoDB 中，基数不高的分区键可能会导致许多请求，这些请求仅针对几个分区。如果生成的热分区 超过了分区每秒 3000 RCU 或 1000 WCU 的限制，这可能会导致节流。诊断工具 CloudWatch Contributor Insights（CCI）可以为每个表的项目访问模式提供 CCI 图表，以协助对此进行调试。您可以持续监控 DynamoDB 表中最常访问的键值和其他流量趋势。有关 CloudWatch Contributor Insights 的更多信息，请参阅 CloudWatch Contributor Insights for DynamoDB。有关更多信息，请参阅在 DynamoDB 中设计分区键来分配工作负载和 Choosing the Right DynamoDB Partition Key
到该表的流量超过表级吞吐量配额
在任何区域的账户级别应用表级读取吞吐量和表级写入吞吐量配额。这些配额同时适用于预置容量模式和按需容量模式的表。默认情况下，表的吞吐量配额为 40000 个读取请求单位和 40000 个写入请求单位。如果表的流量超过此配额，则表可能会被节流。有关如何防止发生这种情况的更多信息，请参阅 Monitoring DynamoDB for operational awareness
要解决此问题，请使用 Service Quotas 控制台增加账户的表级读取或写入吞吐量配额。
