訊息與事件驅動

🧱 白話：佇列 ＝ 銀行取號機——生產者抽了號碼牌就走（非同步：留言而非打電話），消費者照自己的速度一號一號叫。三大好處：解耦（下游掛了訊息不丟）、削峰（尖峰流量先排隊）、獨立擴展（隊太長就加人）。地基見 基礎篇 ch08 API 與非同步。

核心用途：解耦（Decouple）生產者和消費者，緩衝突發流量，實現非同步處理。

• Standard Queue（標準佇列）：無限吞吐量、至少一次交付（At-Least-Once，訊息可能重複）、不保證順序（Best-Effort Ordering）。消費者需要實作冪等性（Idempotency）——意思是「同一筆訊息就算被處理兩次以上，結果也要跟只處理一次一樣」，最常見的做法是讓每筆訊息帶一個唯一 ID，處理前先檢查這個 ID 是否已經處理過（例如查一下資料庫或暫存記錄），處理過就直接略過、不要重複扣款或重複建立訂單。
• FIFO Queue：嚴格保證順序（First-In-First-Out）、恰好一次（Exactly-Once）、吞吐量上限 3000 msg/s（有批次）。佇列名稱必須以 .fifo 結尾。
• Visibility Timeout：消費者取得訊息後，訊息在佇列中隱藏一段時間（預設 30 秒）。若消費者在時間內處理完並刪除訊息，訊息消失；若未刪除，訊息重新出現供其他消費者處理。
• Dead Letter Queue（DLQ）：訊息被多次處理失敗（超過 maxReceiveCount）後，自動移到 DLQ，方便後續除錯。Standard 的 DLQ 也是 Standard；FIFO 的 DLQ 必須是 FIFO。
• Long Polling：消費者等待佇列有訊息才回應（最多等 20 秒），避免空輪詢，減少 API 呼叫費用。建議啟用。
• 訊息大小：最大 256KB。超過的大訊息用 SQS Extended Client（存在 S3，SQS 只放 S3 URL）。

核心模式：一對多（One-to-Many）訊息推播（Push）。發布者發送訊息到 Topic，所有訂閱者同時收到。

• 訂閱類型：SQS、Lambda、HTTP/HTTPS、Email、SMS、Mobile Push（iOS/Android）。
• SNS FIFO Topic：類似 SQS FIFO，保證順序且去重，只能配合 SQS FIFO 訂閱使用。
• 訊息篩選（Message Filtering）：訂閱者可以設定過濾政策（JSON），只接收符合條件的訊息。例如：一個 SNS Topic 放訂單事件，不同的 SQS 佇列只訂閱特定狀態的訂單。
• 訊息大小：最大 256KB。

四種 Kinesis 服務：

• Kinesis Data Streams（KDS）：即時串流資料，按 Shard 收費，每個 Shard 1MB/s 輸入、2MB/s 輸出。資料保留 1~365 天（預設 24 小時），可多個消費者同時讀取同一筆資料（SQS 不行），支援資料重播（Replay）。適合即時監控、Log 分析。
• Kinesis Data Firehose（KDF）：全託管的資料載入服務（ETL），將串流資料自動傳送到目的地：S3、Redshift、OpenSearch、Splunk、HTTP Endpoint。不儲存資料，近即時（60 秒延遲），無需管理 Shard，按資料量計費。
• Kinesis Data Analytics（KDA）：使用 SQL 或 Apache Flink 對串流資料進行即時分析。輸入可以是 KDS 或 KDF，輸出可以再送到 KDS、KDF 或 Lambda。
• Kinesis Video Streams：專門用於串流影片到 AWS（安全攝影機、ML 模型分析）。

• 核心功能：根據事件規則（Event Rules）將 AWS 服務事件路由到指定目標（Lambda、SQS、SNS、ECS、Step Functions 等）。原名 CloudWatch Events，功能更強大。
• 事件來源：AWS 服務（EC2 狀態變更、S3 物件建立、CodePipeline 狀態等）、第三方 SaaS（Zendesk、Datadog 等）、自訂應用程式（Custom Event Bus）。
• Event Pattern 匹配：根據事件的 JSON 內容進行精確匹配，例如只在特定 S3 bucket 發生特定事件時觸發。
• 排程（Schedule）：使用 Cron 或 Rate 表達式定期觸發目標（例如每天早上 8 點執行 Lambda 函數）。
• Event Archive & Replay：可以封存事件並在之後重播，方便除錯和重新處理。