消息隊列性能大比拼：ActiveMQ、RabbitMQ、ZeroMQ、Kafka 等 9 款深度測評
本文譯自 Dissecting Message Queues，對 9 款主流消息系統進行吞吐量、延遲、部署維護、API 易用性多維度實測分析。
測試環境與方法論
- 硬體：MacBook Pro 2.6GHz i7 / 16GB RAM
- 拓撲：單生產者 + 單消費者 Pub/Sub
- 負載：1,000,000 條 1KB 訊息 (貼近實際業務載荷)
- 指標：發送吞吐量、接收吞吐量、端到端延遲分佈
架構分類
| 類別 | 代表產品 | 特徵 |
|---|
| Brokerless (無代理/對等) | ZeroMQ, nanomsg | 點對點直連，無中心節點，延遲極低，吞吐極高 |
| Brokered (有代理/中心節點) | ActiveMQ, RabbitMQ, Kafka, NATS, NSQ, Redis, Kestrel, ruby-nats | 訊息經 Broker 轉發，提供持久化、路由、可靠性保證 |
吞吐量實測結果 (msg/s)
Brokerless 組：數量級領先
- ZeroMQ： 發送 > 5,000,000，接收 ~600,000 (發收比 > 8:1，內部緩衝導致)
- nanomsg： 發送 ~3,000,000，接收 ~2,000,000 (發收更平衡)
Brokered 組：差距巨大
- 第一梯隊 (>100k)： NATS, Kafka, ruby-nats, Redis* (Redis 非專業 MQ，切斷慢消費者，不可靠)
- 第二梯隊 (25k-100k)： NSQ, Kestrel
- 第三梯隊 (<25k)： ActiveMQ, RabbitMQ (AMQP 協議開銷、持久化、確認機制)
關鍵觀察： Brokered 發收吞吐量基本持平；Brokerless 發送遠高於接收 (ZeroMQ 尤甚)。
延遲特性分析
- 延遲 ≠ 1/吞吐量。實際延遲分佈呈長尾，受批處理、網絡棧優化影響。
- Brokerless： 微秒級，隨訊息量增長緩慢。nanomsg 初期尖峰明顯 (批處理暖機)。
- Brokered： 毫秒級。ActiveMQ/RabbitMQ 延遲最高 (AMQP 確認、持久化)。Kafka/NATS 表現優異。
架構選型決策矩陣
| 維度 | ZeroMQ / nanomsg | ActiveMQ / RabbitMQ | Kafka / NATS | Redis Pub/Sub |
|---|
| 吞吐量 | 極高 (百萬級) | 中低 (萬級) | 高 (十萬級) | 極高但不可靠 |
| 延遲 | 微秒級 | 毫秒級 | 亞毫秒級 | 微秒級 |
| 可靠性 | 無保證 (應用層自建) | 強 (持久化、ACK、集群) | 強 (副本、ISR) | 無 (無 ACK、無持久化) |
| 部署複雜度 | 極低 (庫嵌入式) | 高 (獨立 Broker 集群) | 中高 (ZK/集群管理) | 低 |
| 協議複雜度 | 簡單 (自定義框架) | AMQP (重、複雜) | 自定義二進制 (輕) | RESP (極簡) |
| 運維成本 | 無獨立進程 | 高 (監控、調優、升級) | 中高 | 低 |
核心觀點摘錄
ZeroMQ 作者 Martin Sustrik：「保證交付是神話。沒有 100% 保證。我們應構建像互聯網一樣、面對失敗具韌性、繞過損傷的系統。」
選型建議
- 極致效能、可容忍應用層實現可靠性： ZeroMQ / nanomsg (嵌入式、無運維)。
- 企業級可靠性、複雜路由、事務支援： RabbitMQ (AMQP 生態成熟) 或 ActiveMQ (JMS 標準)。
- 高吞吐日誌/事件流、回放、流處理： Kafka (生態最豐富)。
- 輕量級服務發現、配置推送、低延遲 RPC： NATS / NATS Streaming。
- 臨時通知、實時推送、不怕丟失： Redis Pub/Sub (但別當主力 MQ)。
結語
沒有銀彈，只有權衡。先明確業務對可靠性、順序性、延遲、吞吐、運維能力的真實需求，再對號入座。 基準測試數據僅供參考，生產環境網絡、磁碟、JVM 調優、集群拓撲差異巨大，必須自行壓測驗證。
