為什么 SQS 在基於事件的場景中優於 S3

Question

我必須設計一個成本優化的解決方案，它應該是 aws 雲原生的。 我必須解決的問題是我有 9000 萬條消息來自數據庫。 每個事件都是獨立的，無需排序即可處理。 我必須處理每條消息並進行一些操作，然后將其放入 Elastic search service 。

我認為的解決方案低於一個

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

基本上使用來自SNS，以便多個SQS可以同時消費。

這樣做時，我想為什么我們不能使用 S3 以便記錄可以永久保存並可以復制到另一個區域，而且我們可以在 S3 中的每個放置事件上調用 lambda 函數。

所以我的計划是，如果我們使用 S3，那么對於 9000 萬條記錄，我們將在 s3 中創建 9000 萬個文件，然后使用雲前端我們可以讀取甚至沒有雲，我們可以使用 lambda 函數從 s3 讀取。

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

S3 put 的吞吐量為 3500/second/folder，out 的吞吐量為 5000/sec/prefix 。 在 s3 和 sqs 中放置請求的成本幾乎相同。

有人能告訴我使用基於 S3 的解決方案有什么問題嗎。 我知道在這里使用 SQS 看起來非常明顯，但是如果我們在這種情況下使用 S3 int 會有什么風險？

我正在尋找的輸出是每秒 5k。

即使是成本明智的 SQS 看起來也更昂貴，因為我需要同時支付 SNS + SQS 但如果我們使用 S3，則只有 S3 put 和 lambda

請建議

Answer 1

我不會做其中任何一個，而是這樣做：

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

SNS 到 lambda 將運行盡可能多的 lambda，以處理請求負載，直至您的帳戶限制或 lambda 上設置的限制。 將 SQS 放在那里的唯一原因是為了增加一些彈性，但我可能只是在 Lambda 上這樣做，作為一個死信隊列。