---
# System prepended metadata

title: chapter 14 SQS
tags: [大話AWS雲端架構]

---

# 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 本章小節