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

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

我认为解决这一问题的办法如下

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

基本上使用SNS，以便多个SQ可以同时消费

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

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

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

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

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

我要找的直通输出是每秒5公里

即使是成本明智的SQS one看起来也更昂贵，因为我需要从SNS+SQS两个方面支付费用，但如果我们只使用S3，则S3 put和lambda

---

请建议

我不会做这两件事，并且这样做：

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

---

SNS to lambda将运行处理请求负载所需的尽可能多的lambda，最高可达您帐户上的限制或lambda上设置的限制。将SQS放在那里的唯一原因是为了增加一些弹性，但我可能只是在Lambda上这样做，作为一个死信队列。

但是保证消息不会丢失的是什么。还有为什么不使用s3方法呢。我觉得你的方法更好。但是为什么我们要在这里排除s3。消息不太可能传递。S3方法可以工作，假设您没有达到速率限制，但它不是实现这一点的理想方法，而且会更慢。由于lambda限制，SNS在1000个并发请求后开始节流，并且它直接开始进入DLQ，因此将SQS处理…SNS将向lambda发送成批记录，不只是一次一个。如果你认为你需要一个更高的限制，那么你可以得到一个增加（1000是一个软限制）。同样值得了解关于S3（）与SNS（）交付的保证。@jarmod所以S3在这种情况下看起来也很有希望？也许有几个选择。您可能有超出上述范围的需求，因此通过堆栈溢出问题提供最佳体系结构并不理想。S3方法为消息提供了极好的长期耐用性（如果您需要的话），并且成本较低，但是SNS/SQS方法在非常高的规模下（比S3更高的摄取率和更低的延迟读/写）可能更可取，尽管使用推送模型触发Lambda可能会导致Lambda所做的任何事情的扩展问题（例如，写入后端数据库）。还应该考虑动态数据流。