我应该何时使用自动缩放以及何时使用 SQS？答案

【问题标题】：When should I use auto-scaling and when to use SQS?我应该何时使用自动缩放以及何时使用 SQS？
【发布时间】：2019-10-20 17:55:37
【问题描述】：

我正在研究 DynamoDb，但我遇到了一个找不到任何通用解决方案的问题。

我的问题是：如果我有一个使用 dynamodb 作为数据库的应用程序，初始写入容量为每秒 100 次写入，并且在高峰时段负载很重，假设每秒写入 300 次。为了减少数据库的负载，我应该使用哪个服务？

我认为我们应该进行自动缩放，但在某处我研究过，如果需要数据顺序，我们也可以使用 sqs 为数据和运动创建队列。

【问题讨论】：

Auto-scaling 和 SQS 是两个完全不相关的服务。你能澄清你的问题吗？
@Adrian 假设我有一个应用程序将每个用户的投票存储在数据库中，但在高峰时段，这个用户非常高，投票速度很快，所以在这种情况下我应该在前面使用 SQS我的 DynamoDB 的应用程序或 AutoScaling？
这取决于每个选项的成本比较，以及从提交投票到记录到数据库之间的延迟时间是可以接受的。这不是其他任何人都可以为您回答的问题（它没有“正确”答案）。
您应该查看 DynamoDB On-Demand，它允许您在无需预置容量的情况下运行 DynamoDB。

【解决方案1】：

在过去，在 DynamoDB Auto-Scaling 之前，一种常见的使用模式是：

这允许为平均工作负载而不是峰值工作负载预置 DynamoDB。但是，它有更多的部分需要管理。

如今，DynamoDB 可以使用adaptive capacity 和burst capacity 来处理临时更改。对于较大的更改，您可以实现DynamoDB Auto Scaling，这可能比 SQS 方法更容易实现。

【讨论】：

【解决方案2】：

最佳解决方案取决于您的应用程序的特性。它可以容忍异步数据库写入吗？它可以容忍对数据库写入的任何限制吗？

如果您可以在流量突然增加时处理来自 DynamoDB 的一些限制，您应该使用 DynamoDB 自动缩放。

如果节流不行，但异步写入可以，那么您可以在 DynamoDB 前面使用 SQS 来管理流量突发。在这种情况下，您仍然应该启用自动缩放，以确保您的队列工作人员有足够的吞吐量可供他们使用。

如果您必须进行同步写入并且您不能容忍来自 DynamoDB 的任何限制，您应该使用 DynamoDB 的按需模式。（但是，请注意，如果单个分区键的 WCU 超过 1k 或 3k RCU，仍然可能会受到限制。）

当然成本也是一个考虑因素。将 DynamoDB 与自动缩放结合使用将是最具成本效益的方法。我不确定 On Demand 与使用 SQS 的成本相比如何。

【讨论】：