解决 Amazon DynamoDB 中的限制问题
在服务导向型架构和分布式系统中，限制各种服务组件处理 API 调用的速率称为“限制”。这有助于让峰值变得平滑，控制组件吞吐量不匹配情况，并在出现意外操作事件时进行可预测性更高的恢复。DynamoDB 专为这些类型的架构而设计，DynamoDB 客户端内置了针对限制请求的重试功能。一定程度上的限制对应用程序而言不一定是问题，但是持续限制数据工作流中对延迟敏感的部分可能会对用户体验产生负面影响，并会降低系统的整体效率。
如果您对 DynamoDB 表的读取或写入操作受到限制（或者如果您在执行操作时遇到 ProvisionedThroughputExceededException），请考虑使用以下策略来解决该问题。
确保预置模式的表有足够的容量
DynamoDB 向 CloudWatch 报告分钟级指标。这些指标按一分钟的总和计算，然后取平均值。但是，DynamoDB 速率限制每秒都会应用。例如，如果您为表预置了 60 个写入容量单位，则可以在一分钟内执行 3600 个写入单位，但是尝试在任何一秒内执行超过 60 个写入单位可能会导致某些请求受到限制。
要解决此问题，请确保您的表有足够的容量来服务您的流量，并使用指数回退重试受限制的请求。如果您使用的是 Amazon SDK，则默认情况下会实施此逻辑。因此，可能会出现限制，并在第二次或第三次重试时成功重试，而不会导致代码错误。为了了解发生的限制，每个 AWS-SDK 版本都有检测限制的方法。例如，在 Python 中检查返回的 ResponseMetadata.RetryAttempts 字段中的数值。如果该值大于零，则表示存在限制。检测到这个问题后，一个不错的策略是记录所涉及的分区键，因为它可能是一种热键模式，仅使用 CloudWatch 很难诊断。
另外，可以考虑在预置表上使用 Auto Scaling，根据工作负载自动调整预置容量。您还应该考虑更新扩缩策略，使其具有更高的最低利用率或更低的目标利用率，并确保最大设置不会设置得过低。
考虑切换到按需模式
Amazon DynamoDB Auto Scaling 使用 Application Auto Scaling
启动 Application Auto Scaling 后，将调用 UpdateTable API 调用来更新您的 DynamoDB 表或索引的预置容量。Application Auto Scaling 需要有连续的数据点具有较高的目标利用率值才能扩展 DynamoDB 表的预置容量。在此期间，任何超过表的预置容量的请求都将受到限制。因此，对于极其不可预测（突增）的流量模式，可以考虑使用按需模式。有关更多信息，请参阅 使用 DynamoDB Auto Scaling 自动管理吞吐能力。
在分区键之间平均地分配读取和写入操作
在 DynamoDB 中，基数低的分区键可能会导致许多请求仅锁定几个分区，从而出现热分区。如果超过每秒 3000 RCU 和 1000 WCU 的分区限制，则热分区可能会导致限制。
要查找表中访问次数最多和限制次数最多的项目，请使用 Amazon CloudWatch Contributor Insights。Amazon CloudWatch Contributor Insights 是一个诊断工具，提供 DynamoDB 表流量趋势的摘要视图，并帮助您识别最常访问的分区键。使用此工具，您可以持续监控表的项目访问模式的图表。热分区可能会降低表的整体性能。为避免出现这种性能不佳的情况，请通过选择高基数键尽可能均匀地分配读取和写入操作。有关更多信息，请参阅设计分区键来分配工作负载和选择适当的 DynamoDB 分区键
注意
使用适用于 DynamoDB 的 Amazon CloudWatch Contributor Insights 工具会产生额外费用。有关更多信息，请参阅 CloudWatch Contributor Insights for DynamoDB 计费。
增加表级读取或写入吞吐量配额
在任何区域的账户级别应用表级读取吞吐量和表级写入吞吐量配额。这些配额同时适用于预置容量模式和按需容量模式的表。默认情况下，表的吞吐量配额为 40000 个读取请求单位和 40000 个写入请求单位。如果表的流量超过此配额，则表可能会受到限制。有关如何防止发生这种情况的更多信息，请参阅监控 Amazon DynamoDB 的操作感知
要解决此问题，请使用 Service Quotas 控制台增加账户的表级读取或写入吞吐量配额。