爲什麼我應該使用Amazon Kinesis而不是SNS-SQS？

Question

我有一個用例，其中會有數據流到達，我不能以相同的速度使用它並需要緩衝區。這可以使用SNS-SQS隊列來解決。我開始知道Kinesis解決了同樣的問題，那有什麼區別？爲什麼我應該喜歡（或不應該喜歡）Kinesis？

Answer 1

表面上它們有些相似，但您的用例將決定哪個工具是合適的。國際海事組織（IMO），如果你可以順利通過SQS，那麼你應該 - 如果它能做到你想要的，它將會更簡單和更便宜，但這裏有一個更好的解釋，從AWS常見問答中給出了適用於這兩種工具的例子幫助您決定：

FAQ's

Answer 2

最大的優勢對我來說是一個事實，即室壁運動是一個重玩隊列，SQS是沒有的。因此，您可以讓多個消費者使用Kinesis的相同消息（或在不同時間使用相同的消費者），在SQS的情況下，一旦消息被消除，它就從該隊列中消失。 因爲這個原因，SQS對於工作隊列更好。

這意味着相同的數據記錄

Answer 3

室壁運動支持多個消費者的能力可以在相同時間或不同時間在24個小時內以不同的消費者進行處理，在SQS類似的行爲可以通過寫入到多個隊列和消費者可以從多個隊列中讀取來實現。但是，再次寫入多個隊列會在系統中增加子秒（幾毫秒）延遲。第二，Kinesis提供路由選擇功能，使用分區鍵將數據記錄選擇性地路由到不同的分片，分區鍵可以由特定的EC2實例處理，並且可以啓用微量批計算（計數&聚合）。

在任何AWS軟件上工作都很簡單，但SQS是最簡單的。使用Kinesis，需要提前提供足夠的碎片，動態增加碎片的數量以管理峯值負載並減少以節省管理所需的成本。這是Kinesis的痛苦，SQS不需要這樣的事情。 SQS具有無限可擴展性。

Answer 4

在瞭解了一段時間的問題之後，考慮到同樣的問題，我發現SQS（帶SNS）對於大多數使用情況是首選，除非消息的順序對您很重要（SQS不保證FIFO消息）。 （1）您可以從多個應用程序中讀取相同的消息，以及（2）您可以在需要的情況下重新讀取消息。

通過使用SNS作爲SQS的粉絲，兩種優勢都可以實現。這意味着消息的製作者只向SNS發送一條消息，然後SNS將消息扇出到多個SQS，每個消費者應用程序一個。通過這種方式，您可以儘可能多的消費者，而不用考慮分片容量。

此外，我們還添加了一個訂閱了SNS的SQS，該SNS將持有14天的消息。在通常情況下，沒有人從這個SQS中讀取數據，但是如果有一個錯誤讓我們想要倒回數據，我們可以很容易地讀取來自SQS的所有消息，並將它們重新發送到SNS。而Kinesis只提供7天的保留期。

總之，SNS + SQS非常簡單並且提供了大多數功能。 IMO需要一個非常強大的案例來選擇Kinesis。

Answer 5

Kinesis解決了流數據在典型的地圖縮小場景中地圖部分的問題。雖然SQS不確定這一點。如果您的流數據需要在某個密鑰上進行聚合，kinesis會確保該密鑰的所有數據都會轉到特定分片，並且該分片可以在單個主機上使用，從而使密鑰聚合更容易，與SQS相比更容易

Answer 6

我會再補充一件沒人提到的東西 - SQS的價格要高出幾個數量級。

Answer 7

另一件事：Kinesis可以觸發一個Lambda，而SQS不能。因此，對於SQS，您必須提供一個EC2實例來處理SQS消息（並在發生故障時處理它），或者您必須有一個預定的Lambda（不會擴大或縮小 - 每分鐘只有一個） 。

Answer 8

從 AWS Documentation

摘錄：

我們建議亞馬遜的Kinesis流使用的情況下，使用類似下列要求：

• 路由相關的記錄，以相同的記錄處理器（如在流式MapReduce中）。例如，當給定密鑰的所有記錄路由到相同的記錄處理器時，計數和聚合更簡單。

• 記錄的排序。例如，您希望將日誌數據從應用程序主機傳輸到處理/存檔主機，同時保持日誌語句的順序。

• 多個應用程序能夠同時使用同一個流的能力。例如，您有一個應用程序更新實時儀表板，另一個應用程序將數據存檔到Amazon Redshift。您希望這兩個應用程序同時並獨立地使用來自同一個流的數據。

• 幾個小時後才能以相同的順序使用記錄。例如，您有一個計費應用程序和一個在計費應用程序後面運行幾個小時的審計應用程序。由於Amazon Kinesis Streams可將數據存儲長達7天，因此您可以在計費應用程序後7天運行審計應用程序。

我們建議亞馬遜SQS使用例類似於以下要求：

• 消息語義（如消息級的ACK /失敗）和可見性超時。例如，您有一個工作項目隊列，並且想要獨立跟蹤每個項目的成功完成。 Amazon SQS跟蹤確認/失敗，因此應用程序不必維護持久性檢查點/遊標。 Amazon SQS將在配置的可見性超時後刪除acked消息並重新發送失敗的消息。

• 個別消息延遲。例如，您有一個工作隊列，需要延遲安排個別工作。藉助Amazon SQS，您可以將單個郵件配置爲最多延遲15分鐘。

• 動態增加讀取時的併發/吞吐量。例如，您有一個工作隊列，並希望添加更多的讀者，直到清理積壓。藉助Amazon Kinesis Streams，您可以擴展到足夠數量的碎片（但請注意，您需要提前提供足夠的碎片）。

• 利用Amazon SQS的透明擴展功能。例如，由於偶爾的負載峯值或業務的自然增長，您可以緩衝請求和負載變化。由於每個緩衝的請求都可以獨立處理，因此Amazon SQS可以透明地擴展以處理負載，而無需您提供任何配置指示。

Answer 9

的定價模式不同，所以根據您的使用情況下，一方或另一方可能會更便宜。使用最簡單的情況（不包括SNS）：

• SQS爲每條消息收費（每個64 KB計爲一個請求）。
• 每小時每個分片的Kinesis費用（1個分片最多可以處理1000條消息或1 MB /秒），也適用於您放入的數據量（每25 KB）。

在目前的價格堵，而不是考慮到自由層，如果你的最大郵件大小每天發送的消息1 GB，室壁運動的成本會高於SQS得多（$ 10.82 /月室壁運動與SQS $ 0.20 /月）。但是如果你每天發送1TB，Kinesis便宜一些（SQS爲每月158美元，而201美元/月）。

詳細信息：SQS每百萬次請求收取0.40美元（每個64KB），因此每GB爲0.00655美元。每天1 GB，每月僅爲0.20美元;每天1TB，每月超過201美元。

Kinesis收費爲每百萬次請求0.014美元（每個25KB），因此每GB爲0.00059美元。每天1 GB，每月不到0.02美元;每天1 TB，每月約爲18美元。然而，Kinesis每小時收費0.015美元。每個1 MB每秒至少需要1個碎片。在每天1GB的情況下，1個碎片將會很多，因此每天將增加0.36美元，總成本爲每月10.82美元。每天1 TB，您至少需要13個碎片，每天增加4.68美元，總成本爲每月158美元。這些技術的

Answer 10

語義是不同的，因爲他們的目的是支持不同的方案：

• SQS：流的項目不彼此相關
• 室壁運動：流中的物品是彼此相關

讓我們通過示例瞭解差異。

1. 假設我們有一個訂單流，對於每個訂單我們需要保留一些庫存並安排交貨。完成此操作後，我們可以安全地從流中移除項目並開始處理下一個訂單。完成完成與先前的順序，然後我們開始下一個。
2. 同樣，我們有相同的訂單流，但現在我們的目標是按目的地對訂單進行分組。一旦我們有10個訂單到同一個地方，我們希望將它們交付到一起（交貨優化）。現在這個故事是不同的：當我們從流中獲取一個新項目時，我們無法完成處理;相反，我們「等待」更多的項目來實現我們的目標。而且，如果處理器進程崩潰，我們必須「恢復」狀態（所以不會丟失命令）。

一旦一個項目的處理不能與另一個項目的處理分離，我們必須具有Kinesis語義才能安全地處理所有情況。