# chapter 14 SQS ###### tags: `大話AWS雲端架構` (以下圖片源自大話AWS雲端架構) Amazon Simple Queue Service (SQS) 是全受管訊息佇列服務,可讓您分離和擴展微型服務、分散式系統及無伺服器應用程式。SQS 可免除與管理和操作訊息導向中介軟體相關的複雜性及開銷,也可讓開發人員專注在與眾不同的工作上。您可以使用 SQS 在軟體元件之間傳送、存放和接收不限數量的訊息,不會遺失訊息或需要其他服務可用 ![](https://i.imgur.com/JqJzKMx.jpg) ### 14.1 任務暫存器 - SQS 在項目解決部分高併發問題後,開始追加一些新的功能,比如影片轉檔。但由於這些新功能的計算量較大,會花上一些時間。 ![](https://i.imgur.com/KMWtwDO.jpg) ### 14.2 經典應用案例 - 工作便利貼 ![](https://i.imgur.com/db9bvqC.jpg) ### 14.3 SQS的核心架構 #### 14.3.1 Producer、Message、Queue、Consumer #### 1. Producer 負責將用戶需求轉換成Message,並轉送至消息佇列 #### 2. Message 服務之間傳遞的任務資訊 #### 3. Queue 存放那些待完成任務的訊息,供Consumer #### 4. Consumer 從佇列中抽取Message,並按消息內容進行任務處理。 ![](https://i.imgur.com/fgttgUC.jpg) 用戶上傳影片之後,Instance-1按內容生成一個json格式的Message,傳到一個Queue內,並在傳入後,Instance-1馬上回覆用戶,已進行loading,請過一陣子之後再登入系統進行觀察。 ![](https://i.imgur.com/8LT7FrT.jpg) 在Queue後面新增一些Instance,專門負責按照Message的內容,抓取影片並進行影片轉碼,並將結果存回系統。 ![](https://i.imgur.com/PgCPawh.jpg) ### 14.4 每一個任務的Message容量限制 Producer生產的Message,預設最大值可到256KB,如果要傳大型檔案,建議把大型檔案放到S3,Message內記載檔案所在的S3位置,讓Consumer去S3進行拉取 ![](https://i.imgur.com/UJdiAYZ.jpg) ### 14.5 SQS的兩種版本 - Standard 與 FIFO SQS推出了兩大版本,一個是FIFO版本,先進入的Message優先處理,另一個是標準版,處理Message的時候,不考慮順序性。 #### 1. Standard Queue * 無限輸送量:標準佇列支援每個API動作每秒近乎無限個交易數(TPS) * 至少傳遞一次:一個訊息至少傳遞一次,但偶爾毀傳遞一個以上的訊息副本。 * 盡力按順序傳遞:訊息偶爾不會按照傳送順序傳遞。 #### 2. First In First Out (FIFO) Queue * 高輸送量:根據預設,FIFO佇列支援高達每秒300個訊息(每秒300次傳送、接收或刪除操作)。當每個操作都要批次處理10則訊息(最大值)時,FIFO佇列每秒最多可以支援3000則訊息。若要要求提高限制,請發出支援請求。 * 恰好處理一次:訊息只會傳遞一次並保持可用狀態,直到消費者處理訊息並將之刪除。佇列尚未引進複製功能。 * 先入先出交付:嚴格保持訊息傳送和接收的順序(即先入先出)。 ![](https://i.imgur.com/7qACn0g.jpg) ### 14.6 消息不可見性,避免任務重複 提問:一個Queue,是不是容許多個Consumer進行存取拉取訊息?那會不會有可能多個Consumer拉取同一個Message進行處理,而造成多次處理了? 回答:SQS提出了一系列避免消息重複處理的機制,當第一個Consumer拉取消息之後,消息會進入所謂的Invisibility(消息不可見) ![](https://i.imgur.com/Go1ZQJZ.jpg) #### 14.6.1 使用Message後,記得Delete Message,避免重複取用 在這情境下,拉取訊息的Consumer必須在使用消息之後,發出Delete Message的動作,這樣SQS就會把暫時隱藏的消息,整個刪除,這樣一來,出現消息重用的情況就會減少非常多。 ![](https://i.imgur.com/IGOX8dN.jpg) #### 14.6.2 取用Message的頻率差異 在這個拉取動作,我們還可以分成短輪詢與長輪詢,短輪詢使Consumer存取SQS的頻率相對快,長輪詢使Consumer存取SQS的頻率相對慢一些。就看我們的Producer生產Message的速度,而若一般情況下,SQS建議我們使用長輪詢,減少存取次數,成本也少些。 ![](https://i.imgur.com/7SHLZdD.jpg) ### 14.7 考題解析與思路延伸 14.7.1 放到Queue裡的訊息,都有保留時間,保留時間一到SQS自動刪除該訊息,預設保留時間4天,可調整的範圍為60秒至1209600秒(14天) 14.7.2 SQS用來處理系統中大型執行時間較長的工作 Q: A company has a workflow that sends video files from their on-premise system to AWS for transcoding. They use EC2 worker instance that pull transcoding jobs from SQS. Why is SQS an appropriate service for this scenario? A: SQS helps to facilitate horizontal scaling of encoding tasks. 14.7.3 Q: A website experiences upredictable traffic. Durring peak traffic times, the database is unable to keep up with the write request. Which AWS service will help decouple the web application from database? A: Amazon SQS 訊息佇列可以和其他AWS服務搭配使用,讓分散式應用程式更具擴展性且可靠性。 ### 14.8 SQS 整體架構圖 ![](https://i.imgur.com/ZrHztMK.jpg) ### 14.9 本章相關名詞 ### 14.10 本章小節