系統設計 中階
訊息佇列的應用場景與技術選型（Kafka vs RabbitMQ）
訊息佇列（Message Queue）
為何需要 MQ？
- 解耦：生產者不需等待消費者處理完成
- 削峰填谷：流量高峰時緩衝請求，避免下游服務崩潰
- 異步處理：耗時操作（發 Email、產報告）放入佇列，不阻塞主流程
- 可靠傳遞：消費失敗可重試
Kafka vs RabbitMQ
| 特性 | Kafka | RabbitMQ |
|---|---|---|
| 架構 | 分散式 Log | 傳統 MQ Broker |
| 吞吐量 | 極高（百萬/秒） | 高（萬~十萬/秒） |
| 訊息保留 | 持久化 Log，可重複消費 | 消費後刪除（預設） |
| 順序性 | Partition 內保證順序 | 單一佇列保證 |
| 使用場景 | 資料流、Log 收集、事件溯源 | 任務佇列、RPC 回呼 |
常見模式
- Point-to-Point：單一消費者處理訊息（競爭消費）
- Pub/Sub：多個消費者訂閱相同主題，各自消費
- Dead Letter Queue（DLQ）：處理失敗的訊息移入 DLQ，人工介入
面試加分：解釋「At-least-once」vs「Exactly-once」語意，及為何真正的 exactly-once 在分散式系統中很難實現（Kafka Transactions 是一個解法）。
✦ AI 模擬面試
輸入你的答案，AI 即時分析精準度與改進空間
登入後即可使用 AI 評分