为什么SQS在基于事件的场景中优于S3

Question

我必须设计一个成本优化的解决方案，这应该是aws云原生。我必须解决的问题是，我有9000万条来自数据库的消息。每个事件都是独立的，处理它不需要排序。我必须处理每条消息并进行一些操作，然后将其放入Elastic search服务。

我认为这个问题的解决方案如下所示

AWS API-->LAMBDA-->SNS-->SQS(1)-->LAMBDA-->ES
                     --->SQS(2)-->LAMBDA-->ES

基本上是来自SNS，所以多个SQS可以同时使用。

在这样做的时候，我想为什么我们不能使用S3，这样记录就可以永久保存，并可以复制到另一个区域，而且我们可以在S3中的每个put事件上调用lambda函数。

所以我的计划是，如果我们使用S3，那么对于9000万条记录，我们将在s3中创建9000万个文件，然后使用云端，我们可以读取，甚至在没有云的情况下，我们可以使用λ函数从s3读取。

API-->S3-->lambda--->ES

S3 put的吞吐量为3500个/秒/文件夹，输出为5000个/秒/前缀。put请求在s3和sqs中的开销几乎相同。

谁能告诉我是什么问题是使用基于S3的解决方案。我知道在这里使用SQS看起来非常明显，但是在这种情况下使用S3有什么风险呢？

我正在寻找的吞吐量是每秒5k。

即使是在成本方面，SQS看起来也更贵，因为我需要为SNS +SQS两者都付费，但如果我们只使用S3，则只需要S3 put和lambda

请给出建议

Answer 1

我不会做这两件事中的任何一件，而是这样做：

API --> SNS --> Lambda --> ES
            --> Lambda --> ES

到lambda的SNS将运行尽可能多的lambda来处理请求负载，直到您的帐户上的限制，或者lambda上设置的限制。将SQS放在其中的唯一原因是为了增加一些弹性，但我可能只会在Lambda上这样做，作为死信队列。