RabbitMQ vs Kafka
比較 RabbitMQ 與 Apache Kafka 在架構設計、訊息模型、效能、適用場景上的差異，幫助選擇合適的訊息系統
RabbitMQ 是 message broker，Kafka 是分散式事件串流平台。兩者在解決相關但不同的問題，許多情境不是互斥的選擇。
Smart Broker vs Dumb Broker
這是兩者最根本的差異：RabbitMQ 的 broker 很聰明、consumer 很笨；Kafka 的 broker 很笨、consumer 很聰明。其他所有差異都源自這個設計哲學。
RabbitMQ 的 broker 負責路由、過濾、retry、訊息狀態追蹤；consumer 只要訂閱 queue 等推送。Kafka 的 broker 本質上只是持久化的 append-only log，訊息要給誰、從哪讀、要不要重播全由 consumer 自己管。
| 面向 | RabbitMQ | Kafka |
|---|---|---|
| 定位 | Message Broker | Distributed Event Streaming |
| 設計哲學 | Smart Broker / Dumb Consumer | Dumb Broker / Smart Consumer |
| 訊息模型 | Push | Pull |
| 協定 | AMQP 0-9-1 | 自家 binary protocol |
架構與訊息保留
RabbitMQ 是三層：producer → exchange → queue → consumer，訊息 ACK 後刪除。Kafka 是兩層：producer → topic partition → consumer group，partition 是不可變 append-only log，訊息依保留時間（預設 7 天）保留，消費後不刪除。
| 特性 | RabbitMQ | Kafka |
|---|---|---|
| 消費後是否保留 | 刪除 | 按保留時間保留 |
| 歷史訊息重播 | 不支援（Stream Queue 除外） | 天生支援 |
| 新 consumer 收到舊訊息 | 不會 | 會 |
Kafka 的「不刪」是事件溯源、重播、新服務處理歷史資料的基礎；RabbitMQ 的「刪」讓它保持低延遲與低儲存成本。RabbitMQ 3.9 後有 Stream Queue 可向 Kafka 模型靠攏，但生態較新。
順序保證
RabbitMQ 在單一 queue 內保序，但多 consumer 競爭時順序會亂，要嚴格順序只能單 consumer，犧牲並行。
Kafka 在單一 partition 內保序，而且一個 partition 在同一 group 內只派給一個 consumer。把相關訊息用同一 partition key 送到同一 partition，就能同時享受順序與並行。這是 Kafka 在「分區順序 + 高並行」場景勝出的關鍵。
吞吐與延遲
吞吐：Kafka 顯著勝出。單節點 Kafka 可做到每秒數十萬到百萬，RabbitMQ 約數萬到數十萬。Kafka 快的原因是順序寫磁碟、zero-copy（sendfile）、producer/consumer 原生批次、partition 平行。RabbitMQ 的 AMQP 與 broker 端路由邏輯讓單筆成本較高。
延遲：RabbitMQ 在低吞吐場景反而更低。Push 模型訊息一到就推送，Kafka 的 pull 模型有 poll interval 與 batching linger time，累加下來每則多十幾毫秒。
對偶：Kafka 適合大量、批次、能接受些微延遲；RabbitMQ 適合中量、即時、低延遲。
路由能力
RabbitMQ 的 direct/fanout/topic/headers 可組合出各種路由，開箱即用。Kafka 的 broker 只認 topic 與 partition，要分流得靠 producer 選 topic、consumer 過濾、或引入 Kafka Streams/ksqlDB。
| 能力 | RabbitMQ | Kafka |
|---|---|---|
| 根據屬性分流 | Direct / Topic | 需 Kafka Streams |
| 萬用字元訂閱 | Topic Exchange | 不支援 |
| Header 條件路由 | Headers Exchange | 不支援 |
| 一則訊息送多個 queue | Fanout | 靠多個 consumer group |
需要複雜路由時 RabbitMQ 幾乎是更好的選擇。
Consumer 模型
RabbitMQ 以 competing consumers 為主，多 consumer 訂閱同一 queue 競爭消費；要達到多組訂閱需要 pub/sub + 每組一個 queue。
Kafka 以 consumer group 為核心：每個 group 獨立維護 offset，不同 group 互不影響，天生支援「同一份訊息多組消費」。
運維與生態
| 項目 | RabbitMQ | Kafka |
|---|---|---|
| 單機部署 | 簡單 | 需要 Zookeeper / KRaft |
| Cluster 部署 | 中等 | 較複雜 |
| 升級難度 | 中等 | 高 |
| 監控生態 | Management UI + Prometheus | JMX + 第三方工具 |
RabbitMQ 入門門檻低、有內建 management UI。Kafka 生態強大（Streams、Connect、schema registry、ksqlDB）但要發揮需要團隊對流式處理有經驗。
適用場景
RabbitMQ：任務佇列、命令傳遞、複雜路由、低延遲、數萬到數十萬 msg/s、小團隊快速上線。
Kafka：事件串流、日誌收集、資料管線（CDC、ETL）、訊息重播、事件溯源、百萬 msg/s、多下游獨立消費、分析工作負載。
可以同時用嗎
可以，定位互補：RabbitMQ 處理命令（要做什麼）、Kafka 記錄事件（發生了什麼）。典型架構：API 把任務發到 RabbitMQ、worker 處理完把結果以事件寫到 Kafka，下游分析、搜尋、快取失效、推薦從 Kafka 獨立消費。
決策速查表
| 需求 | 建議 |
|---|---|
| 簡單任務佇列 | RabbitMQ |
| 複雜路由 | RabbitMQ |
| 低延遲（< 10ms） | RabbitMQ |
| 數百萬 msg/s | Kafka |
| 訊息重播 | Kafka |
| CDC、日誌收集 | Kafka |
| 多下游獨立消費 | Kafka |
| 小團隊快速上線 | RabbitMQ |
| 命令 + 事件混合 | 兩者並存 |