MQ選型對比RabbitMQ RocketMQ ActiveMQ
阿新 • • 發佈：2019-02-05
幾種MQ產品說明：
ZeroMQ : 擴充套件性好，開發比較靈活，採用C語言實現，實際上他只是一個socket庫的重新封裝，如果我們做為訊息佇列使用，需要開發大量的程式碼
RabbitMQ :結合erlang語言本身的併發優勢，效能較好，但是不利於做二次開發和維護
ActiveMQ: 歷史悠久的開源專案，已經在很多產品中得到應用，實現了JMS1.1規範，可以和spring-jms輕鬆融合，實現了多種協議，不夠輕巧（原始碼比RocketMQ多）.，支援持久化到資料庫，對佇列數較多的情況支援不好，不過我們的專案中並不會建很多的佇列.
Redis 做為一個基於記憶體的K-V資料庫，其提供了訊息訂閱的服務，可以當作MQ來使用，目前應用案例較少，且不方便擴充套件
RocketMQ
針對訊息中介軟體的選擇可以從以下方面進行考慮：(主要對比ActiveMQ和RocketMQ)
優先順序：我們的專案對此需求不是特別明顯，RocketMQ需要新建一個特殊佇列來接收優先順序高的佇列，無法實現從0-65535這種細粒度的控制，ActiveMQ可以精細控制
順序：我們的訊息匯流排中的訊息應該都是無狀態的，所以對訊息的處理順序沒有嚴格的要求，如果有特殊要求的話可以在業務層進行控制，activeMQ無法保證嚴格的順序，RocketMQ可以保證嚴格的消費順序
持久化：都支援
穩定性：RoketMQ在穩定性上可能更值得信賴，支援多種叢集方案，畢竟已經撐過幾個雙十一
訊息過濾：ActiveMQ僅支援在客戶端消費的時候進行判斷是否是自己需要的訊息，RocketMQ可以在broker端進行過濾，對於我們的訊息匯流排，這裡可以節省大量的網路傳輸是否會有訊息重發造成的重複消費：RocketMQ可以保證，ActiveMQ無法保證
回溯消費：即重新將某一個時刻之前的訊息重新消費一遍，我們對於這種需求應該很少，RocketMQ支援，ActiveMQ不支援（RocketMQ的佇列是持久化到硬碟的，定期進行清除
事務：都支援
定時消費：RocketMQ支援
訊息堆積：就是當快取訊息的記憶體滿了之後的解決方案，一種是丟棄策略，這種不會影響吞吐量，還有一種就是將訊息持久化到磁碟，這種會影響吞吐量，在評估影響程度上，RocketMQ的成績稍微好一點
客戶端不線上：RocketMQ可以在客戶端上線後繼續將未消費的訊息推送到客戶端
目前比較活躍的幾種MQ中介軟體產品的對比如下：（僅統計開源的專案）
| ActiveMQ | RabbitMQ | RocketMq | ZeroMQ | |
| 關注度 | 高 | 高 | 中 | 中 |
| 成熟度 | 成熟 | 成熟 | 比較成熟 | 不成熟 |
| 所屬社群/公司 | Apache |
Mozilla Public License |
Alibaba | |
| 社群活躍度 | 高 | 高 | 中 | 低 |
| 文件 | 多 | 多 | 中 | 中 |
| 特點 | 功能齊全，被大量開源專案使用 | 由於Erlang 語言的併發能力，效能很好 | 各個環節分散式擴充套件設計，主從 HA；支援上萬個佇列；多種消費模式；效能很好 | 低延時，高效能，最高 43萬條訊息每秒 |
| 授權方式 | 開源 | 開源 | 開源 | 開源 |
| 開發語言 | Java | Erlang | Java | C |
| 支援的協議 |
OpenWire、 STOMP、 REST、XMPP、 AMQP |
AMQP |
自己定義的一 套(社群提供 JMS--不成熟) |
TCP、UDP |
| 客戶端支援語言 |
Java、C、 C++、 Python、 PHP、 Perl、.net 等 |
Java、C、 C++、 Python、 PHP、Perl 等 |
Java C++（不成熟） |
python、 java、 php、.net 等 |
| 持久化 | 記憶體、檔案、資料庫 | 記憶體、檔案 | 磁碟檔案 | 在訊息傳送端儲存 |
| 事務 | 支援 | 不支援 | 支援 | 不支援 |
| 叢集 | 支援 | 支援 | 支援 | 不支援 |
| 負載均衡 | 支援 | 支援 | 支援 | 不支援 |
| 管理介面 | 一般 | 好 |
無社群有 web console 實現 |
無 |
| 部署方式 | 獨立、嵌入 | 獨立 | 獨立 | 獨立 |
| 評價 |
優點： 成熟的產品，已經在很多公司得到應用（非大規模場景）。有較多的文件。各種協議支援較好，有多重語言的成熟的客戶端； 缺點： 根據其他使用者反饋，會出莫名其妙的問題，切會丟失訊息。 其重心放到activemq6.0 產品—apollo 上去了，目前社群不活躍，且對 5.x 維護較少； Activemq 不適合用於上千個佇列的應用場景 |
優點： 由於erlang語言的特性，mq 效能較好；管理介面較豐富，在網際網路公司也有較大規模的應用；支援amqp系誒，有多中語言且支援 amqp 的客戶端可用 缺點： erlang語言難度較 大。叢集不支援動態擴充套件。 |
優點： 模型簡單，介面易用（JMS 的介面很多場合並不太實用）。在阿里大規模應用。目前支付寶中的餘額寶等新興產 品均使用rocketmq。叢集規模大概在50 臺左右，單日處理訊息上百億；效能非常好，可以大量堆 積訊息在broker 中；支援多種消費，包括叢集消費、廣播消費等。開發度較活躍，版本更新很快。 缺點： 沒有在 mq 核心中去實現JMS 等介面， |