Amazon dynamodb 尽管配置了高容量，DynamoDB更新/放入仍被限制

我在DynamoDB表的更新中看到了一些限制。我知道节气门是以每秒为单位工作的，超过规定容量的峰值有时可以被吸收，但不能保证。我知道一个人应该平均分配负载，但我没有这样做

但是请看一下度量标准中的1分钟平均图；附属的。使用的容量远低于配置的容量。这些节流阀是从哪里来的？因为所有的写入都到了一个特定的碎片

没有批写入。工作负载分布是无法轻松控制的

---

DynamoDB建立在这样一个假设之上，即为了充分发挥您所提供的吞吐量的潜力，您的读写必须均匀地分布在空间（散列/范围键）和时间上（并非所有的读写都在同一秒内）

根据图表上分配的吞吐量，您仍然很可能是一个碎片，但如果您之前将吞吐量提高到当前水平以上，并将其降低到当前水平，则可能有两个或更多碎片。虽然这是需要注意的，但可能不是直接导致这种节流行为的原因。如果表中有大量数据，超过10GB，那么肯定会有多个碎片。这意味着您的表中可能有很多冷数据，这可能会导致此问题，但这似乎不太可能

最可能的问题是您有一些热键。具体地说，您有一条或只有几条记录正在接收大量的读或写请求，这会导致限制。从本质上讲，DynamoDB可以支持写入和读取的大量IOPS，但您不能将所有这些IOPS应用于少数记录，在理想情况下，它们需要在所有记录之间均匀分布

由于您显示的节流阀数量在10到100秒之间，因此可能不需要担心。只要您使用的是官方的AWS SDK，它就会自动处理重试，并在完全放弃之前，通过指数退避多次重试请求

虽然在许多情况下很难控制对表的读写分布，但不妨再看看散列/范围键的设计，以确保它真正适合于对表的读写模式。此外，对于读取，您可以通过Memcached或Redis使用缓存，即使缓存在几分钟或几秒钟内过期，也可以帮助减少热键的影响。对于写操作，您需要查看应用程序中的逻辑，以确保没有执行任何可能导致此问题的不必要的写操作

最后一点与批处理写入有关：DynamoDB中的批处理操作不会减少不同子请求所消耗的读写量，它只是减少了生成多个HTTP请求的开销。虽然批处理请求通常有助于提高吞吐量，但它们在降低DynamoDB中节流的可能性方面没有用处