Amazon Web Services (AWS) 提供了兩個處理非同步資料的服務：SQS (Simple Queue Service) 和 Kinesis Data Streams。雖然兩者功能都類似 Queue，但它們的設計理念和使用場景截然不同，下面表格可以清楚地看到它們的差異。

在數據量不大( ex：每分鐘三四千個 Request )和只有一個 consumer 的情況下，其實使用 SQS 已經足夠。但如果你的數據是幾百萬，甚至是幾千萬個 Request ，而且資料需要給多個 consumer 做處理，SQS 恐怕不敷使用，主要原因有兩個：

• SQS 的延遲時間過長
• SQS 的訊息一但被 consume 過，會立即被刪除，無法再給其他 consumer 讀取。

SQS 的延遲時間過長

在上面的表格有說到， SQS 的延遲是秒級的，而 Kinesis 是毫秒級的，究竟差異有多大呢？讓我們來實測看看。實驗的設定如下：

• Batch size: 100
• Batch window: 5 seconds
• Request 數量：10000

SQS 延遲可長達 6~7 秒，這也代表 message 塞在 Queue 裡面的時間，會 Request 的數量增加而變長。

Kinesis 幾乎是即時被處理。

Kinesis 可同時有多個 consumer

之前的文章有把資料同時送到 S3 和 DynamoDB ，只使用一個 Lambda 去完成資料的處理。

但如果今天想要將系統解耦，也避免單一一個 Lambda 的執行時間過長，多拆出一隻 Lambda 出來，這時候就會發生 S3 和 DynamoDB 兩個 datalake 的資料不同步，同一筆 data 只會進到其中一個 datalake ，因為 SQS 的 message 被其中一個 Lambda Consume 之後就會被刪除。

所以架構上用 Kinesis Data Streams 取代 SQS ，會更符合使用情境。

Reference

• 受管串流資料服務 - Amazon Kinesis Data Streams 定價 | Amazon Web Services
• Amazon SQS 定價

Medium: 使用 Serverless 架構設計廣告點擊系統 — SQS vs Kinesis Data streams