黑皮考町

SQS 跟 SNS 的差別在哪? 這裡簡單的整理一下, SQS 是Pull Based的架構, 消費者要自己去佇列中抓訊息下來 SNS 是Push Based的架構, 訊息會自動推撥給訂閱者 使用情境 SQS 用在將應用程式解偶降低相依性 SNS Fanout, 用在同時將訊息散發到其他不同的服務上 使用例子 SQS 線上機票查詢服務(skyscanner), 假設架構如下 我們可以把服務使用者的EC2 instance與負責撈資料的EC2 instance解偶, 好處是, 即使撈資料的EC2掛了, 也不會弄丟使用者的查詢請求, 因為沒處理完的訊息會持續地保留在佇列中等待被處理 SNS 線上影像處理服務, 當使用者上傳照片到S3, 可以透過SNS同時散發這訊息給: (一)處理影像的Lambda, 以及(二)寄發感謝函給使用者的服務, 藉此平行地執行相應的動作 儲存方式 SQS 可以保留訊息到最長14天 SNS 不能保留訊息, 若推撥時訂閱者不在, 訊息會遺失 消費者 SQS的消費者通常都作相似的工作 SNS的消費者(訂閱者)有很大的可能是處理不一樣的工作 https://stackoverflow.com/questions/13681213/what-is-the-difference-between-amazon-sns-and-amazon-sqs

Simple Notification Service Simple Notification Service(簡稱SNS) 允許我們從雲上推撥訊息到任何其他行動裝置或是服務上 Mobile Directly Push 基本上, 要實作訊息推撥的服務, 我們必須串接裝置平台上的Push Notification Service, 但是不同平台有各自的Push Notification Service, 如果目的端橫跨多平台(比如Apple, Google Android, Windows), 這對開發人員來說會是個很大的工程 使用SNS的Mobile Directly Push就不必煩惱這種問題, 因為他都幫我們整合好了, 所以可以簡單地實現跨平台推撥訊息的服務 Push-subscribe  定義好Topic之後, 只要將訊息傳到指定的Topic, 任何訂閱這個Topic的行動裝置或服務都會收到推撥通知 訂閱的對象 除了行動裝置之外, Email, SMS, Lambda, SQS, HTTP Endpoint也可以訂閱SNS上的Topic 優點 1. 主動推撥, 不需要特別發請求去詢問有沒有訊息 2. 推撥訊息時, 無需特別考慮目的端使用何種通訊協定 3. 允許同一則訊息同時在不同的通訊協定上傳送 https://docs.aws.amazon.com/sns/latest/dg/SNSMobilePush.html https://blog.idanbean.io/2016/03/02/aws-sns-with-apns/