前一篇 講 message queue 的演進 timeline——從 ActiveMQ 到 NATS 每一代解什麼極限。這篇接著講判斷依據：
- 什麼具體 case 推著團隊從 RabbitMQ 改 Kafka？
- 什麼 case 反而會從 Kafka 改回 RabbitMQ / Redis Streams？
- 沒撞到對應極限就換 broker，會付出什麼成本？
這不是抽象比較，是「我該不該動 broker」的決策框架。
換 broker 的真實成本
開頭先講為什麼換 broker 是一個大決定：
- 應用層改寫：producer / consumer 的 client library 換、訊息格式可能要調、ack 機制不同
- 訊息保證模型重學：RabbitMQ 的「ack 機制 + DLQ」跟 Kafka 的「offset commit + Consumer Group」mental model 完全不同
- 運維鏈路重做：監控指標、alert rule、disaster recovery、容量規劃全部要重寫
- 團隊重訓：所有 engineer 都要重新學
不是隨便就能換的。所以選錯成本高，有 case-by-case 的判斷依據才能少走冤枉路。
從 RabbitMQ 改 Kafka 的真實 driver
這幾個訊號出現了，你的場景才真的需要 Kafka：
Driver 1：Throughput 撞 RabbitMQ 的 disk I/O 極限
具體數字：單個 RabbitMQ broker（中型機器）能穩定處理約 20-50K msg/s。超過這個範圍會看到 disk I/O 飽和、memory 用爆、ack latency 上升。
什麼 case 會撞這個：
- 大型網站的 user activity tracking（每秒幾十萬使用者操作）
- 物聯網 / 監控系統 telemetry（千萬 device 各自上報）
- 日誌聚合（k8s cluster 的全部容器 log）
到了這個量級，Kafka 的 sequential disk write + zero-copy 讓單機到 100K-1M msg/s 不費力。這是真正非 Kafka 不可的場景。
Driver 2：需要重新消費歷史訊息
RabbitMQ 是「ack 之後刪除」的設計。雖然它有 lazy queue / persistence，但**「Consumer 從一週前 offset 開始重新讀」這個 use case 在 RabbitMQ 上幾乎做不到**。
什麼 case 需要這個：
- 新加一個 downstream service（例如新增搜尋 index），需要讀過去所有事件補資料
- 偵錯：某個 downstream 處理錯了，要從 offset N 開始重跑
- 資料倉儲 ETL：每天從 message stream 重新抓昨天的資料
Kafka 的 log-based 模型 + retention period（可配置幾天到永久）天生支援這個。RabbitMQ 換 Kafka 經常就是被這個 driver 推的。
Driver 3：多 consumer group 各自獨立 fan-out
RabbitMQ 用 fanout exchange + 多個 queue 也能 fan-out，但每個 queue 是獨立資源——你想加第 4 個 consumer group 就要建第 4 個 queue + 重新從上游 publish 進來。
Kafka 的設計是「同一個 topic、多個 consumer group 各自有自己的 offset」——加 consumer group 不需要動 producer、不需要動 topic。這個對「事件被多個 downstream 消費」的場景天生友善。
什麼 case 觸發：
- Event-driven architecture（一個事件多個 service 各自反應）
- 大型 SaaS 的 user.created 事件被 marketing / billing / analytics / notification 同時消費
Driver 4：需要跟大數據生態整合
Kafka 跟 Spark / Flink / Hadoop / 各種 sink connector 是緊密生態的一員。RabbitMQ 整合這些工具要寫一堆 glue code。
什麼 case 觸發：
- 公司開始建 data warehouse / lakehouse，需要從 message stream 抓資料
- 即時分析需求（Flink stream processing）
反方向：從 Kafka 改回 RabbitMQ / Redis Streams 的 case
這個方向更少人講，但實際上 2022+ 越來越多——因為很多公司當年盲目跟 Kafka，後來發現用不到。
Driver 1：實際 throughput 遠低於 Kafka 的 sweet spot
具體數字：Kafka 真正的 sweet spot 是 50K msg/s 以上。如果你的實際 throughput 是 1K-10K msg/s——
- Kafka 的 partitioning / consumer rebalance 機制變成 cognitive overhead
- ZooKeeper / KRaft 運維成本完全不對等
- Latency 反而比 RabbitMQ 差（Kafka 為 throughput 優化，輕量 case p99 經常 10-50ms，RabbitMQ 1-5ms）
換回 RabbitMQ 之後：運維簡單、p99 降低、團隊心智負擔下降。
Driver 2：Routing 邏輯複雜，Kafka topic-only 模型不夠用
Kafka 的訊息路由是「producer 寫進 topic / partition、consumer 訂閱 topic」——非常簡單，但如果你需要 conditional routing（這個訊息要進 queue A 而不是 queue B、根據 routing key 動態決定），Kafka 要在 consumer 層自己寫 filter。
RabbitMQ 的 Topic Exchange / Direct Exchange / Header Exchange 三種 routing 模式，broker 層就能處理 conditional routing——對 routing 複雜的場景簡單一個級距。
什麼 case 觸發：
- E-commerce 的 order 事件，根據國家 / 地區走不同處理 pipeline
- Notification 系統的 channel routing（email / SMS / push 各走各的 queue）
Driver 3：團隊規模 / 知識結構不適合 Kafka
Kafka 的 mental model（partition / offset / consumer group / rebalance / replication factor）對小團隊是真實負擔。5 人的 backend team 用 Kafka 的維護成本，可能比業務本身還貴。
什麼 case 觸發：
- 早期 startup
- 中型公司但 backend team 規模沒大
- 沒有專職 SRE / Platform team
換成 RabbitMQ 或 Redis Streams 之後，運維 surface 大幅縮小。
Driver 4：Latency 敏感場景
Kafka 不是低延遲架構——它為 throughput 優化。如果你的 use case 需要 p99 < 5ms——
- 即時 bidding（廣告競標）
- 即時遊戲訊息
- 高頻 trading 訊號
Kafka 通常達不到。RabbitMQ 或 NATS 能做到。
我自己 local docker 跑過 4 個 broker 的對比 bench（HTTP load test, 1000 events/broker），latency 排序是 NATS（p50 7.9ms）< Redis（7.71ms）< RabbitMQ（9.58ms）< Kafka（10.76ms）。Kafka 比 NATS 慢 36%——而這還是 Kafka 在 single-broker / 沒競爭資源的最佳狀態。Production 高負載下 Kafka latency gap 通常更大。詳見 #14 Broker 選型 「我自己跑了一輪」段。
沒撞到極限就換 broker 的代價
「我們公司也用 Kafka」這種同儕壓力導致的選型最常見也最痛。沒撞到對應 driver 就換 broker，會付出：
- 完整重寫 producer / consumer code（少則一週多則一個月）
- 運維鏈路重做（監控 / alert / 容量規劃）
- 團隊重訓（所有 engineer 都要學新 mental model）
- debug 變慢（半年內團隊對新 broker 不夠熟）
這些成本沒有對應的 leverage 回報的話，是純損失。
判斷準則：
「如果我的場景沒撞到當前 broker 的具體極限——換新 broker 是 cost、不是 leverage。」
決策樹
你目前用什麼？
│
├─ RabbitMQ
│ ├─ 撞了 throughput / 重新消費 / fan-out / 大數據生態 → 評估 Kafka
│ └─ 沒撞牆 → 不要動
│
├─ Kafka
│ ├─ 實際 throughput < 10K msg/s → 評估 RabbitMQ / Redis Streams
│ ├─ Routing 複雜 broker 層處理不了 → 評估 RabbitMQ
│ ├─ Latency p99 > 10ms 影響業務 → 評估 NATS / RabbitMQ
│ ├─ 團隊維運成本壓垮 → 評估 RabbitMQ / managed Kafka（Confluent / MSK）
│ └─ 撞 Kafka 自己的極限沒解 → 留下，調整或上 managed
│
└─ 其他（Redis Streams / NATS / managed）
└─ 大致跟著場景走，撞牆才換
反思
換 broker 的根本判準不是「哪個比較好」，是「我目前的 broker 撞了什麼極限」。
撞了極限就換、沒撞就不要動。Kafka 不是強者宣言，是特定場景的解。RabbitMQ 不是過時，是 general-purpose 場景的常駐選擇。「現在我們公司都用 Kafka」不是技術決策，是 cargo cult。
下一篇講具體選型——把場景 → broker 的對應整理成 cheat sheet，10 分鐘做出判斷。