Amazon Simple Queue Service (SQS) 和 Amazon Simple Notification Service (SNS) 看起來很像，實際上又不太一樣
為了更好釐清兩者，就把兩個服務的筆記放在一起比較

AWS SNS

全名是：Amazon Simple Notification Service

發佈者系統可以透過 Topics 將事件訊息分散發送至大量訂閱者系統以進行平行處理

訂閱者包含：

• Amazon SQS 佇列
• AWS Lambda 函數
• HTTPS 端點
• Amazon Kinesis Data Firehose

架構看起來像這樣

特點

1. 發送即時性的 message 給所有訂閱者
2. 不保存已發送的 message
3. 遵守為發佈/訂閱模式 (Publish/Subscribe Pattern a.k.a Pub/Sub) 模式

AWS SQS

全名是：Amazon Simple Queue Service (SQS)

是全受管訊息佇列服務，訊息通通送進 Queue 再看後續誰去抓來執行
屬於一種 Serverless 解決方案
但執行者可以是 Lambda 也可以是 Laravel 這種非 Serverless 的專案

類型

針對不同的應用程式需求提供兩種佇列類型

Standard Queue

應用程式可以處理抵達超過一次且未照順序排列的訊息

• 無限輸送量：標準佇列支援每個 API 動作每秒近乎無限個交易數 (TPS)
• 至少傳遞一次：一個訊息至少傳遞一次，但偶爾會傳遞一個以上的訊息副本
• 盡力按順序傳遞：訊息偶爾不會按照傳送順序傳遞

FIFO 佇列

當操作和事件的順序很重要或者不能接受重複項目時

• 高輸送量：根據預設，FIFO 佇列支援高達每秒 300 個訊息 (每秒 300 次傳送、接收或刪除操作)
• 恰好處理一次：訊息只會傳遞一次並保持可用狀態，直到消費者(consumer)處理訊息並將之刪除
• 先入先出傳送：嚴格保持訊息傳送和接收的順序 (First In First Out)

Poll

Short polling

詢問之後會馬上取得結果，即使 queue 裡沒東西也會告訴你沒東西
需要不斷詢問才能保證取得最新的狀態
這種方式就像是好像有人一直問你有沒有工作可以做？有沒有工作可以做？有沒有工作可以做

Long polling

詢問之後除非 timeout 或是 queue 裡面有訊息，否則不會立即取得 response
減少額外的輪詢以盡量降低成本，同時以最快的速度接收新訊息
佇列處於空的狀態時，長輪詢請求下一則訊息最多等待 20 秒

特點

1. 由接收端主動去 poll message
2. 一個 queue 只能對應到一個 consumer
3. consumer 回應 queue 完成處理程序後，才會刪掉message

SNS 和 SQS 差異

SNS

新內容更新時發布事件通知給所有訂閱者
是 Push-Based 的架構，訊息會自動推播給訂閱者

簡單來說就是廣播通知

SQS

將 Queue 任務從程式碼中分離
是 Pull-Based 的架構，消費者 (consumer) 要自己去 Queue 中抓訊息下來處理

簡單來說就是 Queue

組合範例

1. 建立 SNS Topic 和 SQS 的方法

1. 進入 SNS 服務，建立 SNS Topic
2. 進入 SQS 服務並建立 SQS
3. 將剛建立的 SQS 訂閱剛建立的 SNS Topic，藉此取得 podcast 內容
   1. 在 SQS Dashboard 勾選目標 SQS 後
   2. 點選上方Action下拉選單後選擇Subscribe to Amazon SNS topic
   3. 選擇剛剛建立的 Topic，並按下Save

2. 模擬 SNS 發送訊息

1. 到 SNS Topic 頁面並選擇 Topic 後，點選右上角Publish message
2. 輸入測試用的內容，並按下Publish message

3. 確認是否收到訂閱訊息

在 SNS Publish message 後，理論上有訂閱 Topic 的全部端點都會收到

1. 開啟 SQS 頁面, 選擇有訂閱 Topic 的 SQS
2. 點選Send and receive message
3. 往下拉到 Receive messages 區塊並選擇Poll for Messages
4. 成功後就可看到訊息清單出現在下面，並且可以點進去看詳細內容

參考來源：傳送散發事件通知