我是云计算的新手，但有一个问题，我将要描述的机制是否存在或可能创建？
Dynamodb 已预置吞吐量（例如 100 次写入/秒）。当然，在实际应用程序中，实际吞吐量是非常动态的，几乎永远不会是每秒 100 次写入的预配置量。我在想，dynamodb的某种类型的队列会很棒。例如，我在高峰时段的 dynamodb 每秒可能会收到 500 个写入请求（是我分配的 5 倍），并且会返回错误。是否有我可以在客户端和数据库之间放置一些队列，因此客户端请求进入队列，客户端确认他们的请求已得到处理，然后队列以每秒 100/写入的速率向 dynamodb 吐出请求，这样就不会返回错误，我不需要提高吞吐量，这将增加我的成本？
将 AWS SQS 放在 DynamoDB 的前面将为您解决此问题，并且并不罕见的设计模式。SQS 已经非常适合根据需要进行扩展，并摄取具有不可预测流模式的大量消息。
您可以先将所有消息放入SQS，或者在超出DynamoDB数据库的设计思路时使用SQS作为溢出缓冲区。
一个或多个工作实例可以从SQS队列中读取消息，并按照您决定的速度将它们放入DynamoDB。
如果传入消息的顺序非常重要，Kinesis 是另一种选择，您可以摄取传入消息，然后按照您定义的速度，按照到达消息的相同顺序将它们插入 DynamoDB。
IMO，SQS将更容易使用，但如果您的需求更复杂，Kineses将为您提供更大的灵活性。
这无法单独使用DynamoDB来完成。DynamoDB专为统一、可扩展、可预测的工作负载而设计。如果你想在DynamoDB前面放一个队列，你必须自己做。
DynamoDB 确实对突增容量有一点容忍度，但这不适用于持续使用。您应该阅读最佳实践部分 调整预置吞吐量时考虑工作负载一致性，但这里有一些我认为很重要的段落，其中有我强调的一些事情：
对于设计用于统一工作负载的应用程序，DynamoDB的分区分配活动并不明显。工作负载中暂时的不均匀性通常可以被突发容差所吸收，如节约使用突发容量中所述。但是，如果您的应用程序必须定期适应不一致的工作负载，那么您应该考虑DynamoDB的分区行为来设计您的表(请参见了解分区行为)，并且在增加和减少该表上的供应吞吐量时要小心。
如果减少表的已配置吞吐量，DynamoDB将不会减少分区的数量。假设您创建了一个具有比应用程序实际需要的配置吞吐量大得多的吞吐量的表，然后在稍后降低了配置吞吐量。在这种情况下，每个分区的已配置吞吐量将低于最初创建吞吐量较少的表时的吞吐量。
有一些工具可以帮助自动缩放DynamoDB，比如sebdah/dynamic-dynamodb，这可能值得研究一下。
对于那些最近看到这一点的人来说，一个更新是在2018年推出了按需容量模式。
您无需预先决定容量，它将根据需求扩展读写容量。
请参阅：https://aws.amazon.com/blogs/aws/amazon-dynamodb-on-demand-no-capacity-planning-and-pay-per-request-pricing/
