Amazon SQS (Simple Queue Service) 是 AWS 歷史最悠久（也是最核心）的服務之一。
一句話總結：它是用來「解耦 (Decouple)」應用程式元件的「緩衝區 (Buffer)」。
當你的系統前端流量暴增，後端處理不來時，SQS 就是那個負責「排隊」的地方，讓後端可以依照自己的步調慢慢處理，確保資料不流失。以下是考試與實務設計的重點整理：
1. 核心概念：解耦 (Decoupling)
- Producer (生產者)：發送訊息到 SQS（例如：使用者下訂單）。
- Queue (佇列)：訊息暫存在這裡（最長可存 14 天，預設 4 天）。
- Consumer (消費者)：從 SQS 「拉取 (Pull)」 訊息並進行處理（例如：EC2 或 Lambda 處理訂單）。
為什麼這很重要？
如果沒有 SQS，前端直接呼叫後端，一旦後端掛掉，前端也會跟著掛（緊耦合）。有了 SQS，即使後端維修 1 小時，前端依然可以繼續收單，訊息乖乖在 SQS 裡排隊，等後端修好再處理。
2. 兩種佇列類型 (Queue Types) —— 考試必考！
這兩者的區別是 AWS 考試的經典題：
3. 重要參數與功能 (Key Features)
A. Visibility Timeout (可見性逾時)
- 機制：當 Consumer A 把訊息拿去處理時，這條訊息會有幾秒鐘對其他 Consumer 「隱形」。
- 目的：防止多個 Consumer 處理同一條訊息。
- 異常處理：如果 Consumer A 處理到一半掛掉（超過時間沒刪除訊息），訊息會重新出現在 Queue 中，讓 Consumer B 接手處理。
B. Dead Letter Queue (DLQ, 死信佇列)
- 機制：如果一條訊息被 Consumer 處理失敗了很多次（例如超過 5 次），SQS 認為這條訊息有問題（毒藥訊息），就會把它移到 DLQ。
- 目的：避免錯誤的訊息卡住整個系統，方便工程師事後排查 bug。
C. Short Polling vs. Long Polling
- Short Polling：Consumer 問 SQS 有沒有信？SQS 馬上回傳（可能回傳空值），浪費錢與資源。
- Long Polling (推薦)：Consumer 問 SQS，如果沒有信，SQS 會等待幾秒（最多 20秒）直到有信才回傳。優點：省錢（減少 API 呼叫次數）、降低延遲。
4. 常見架構模式 (Architecture Patterns)
Auto Scaling 配合 SQS
- 場景：電商促銷活動。
- 設計：設定 CloudWatch 監控 SQS 的 ApproximateNumberOfMessagesVisible (排隊長度)。如果排隊訊息太多 →→ 觸發 Auto Scaling 新增 EC2 來消化訊息。如果沒訊息 →→ 減少 EC2 省錢。
Fan-out Pattern (扇出模式) —— SQS + SNS
- 場景：使用者上傳頭像後，系統需要同時做三件事：1. 存檔、2. 產生縮圖、3. 發 Email。
- 做法：應用程式發送訊息給 SNS Topic。SNS 平行推送給 3 個不同的 SQS Queues。3 個不同的 Worker 分別處理各自 Queue 裡的任務。
5. 超級比一比：SQS vs. SNS vs. Kinesis
6. 考試關鍵字 (Keywords)
- Decouple (解耦) →→ 必選 SQS。
- Pull-based (拉取模式)。
- Buffer / Batching (緩衝 / 批次處理)。
- Order is important / No duplicates (順序重要 / 不可重複) →→ 選 FIFO Queue。
- Application integration (應用程式整合)。
