關於消息總線使用哪一種消息隊列中間件的調查

幾種MQ產品說明：

ZeroMQ :  擴展性好，開發比較靈活，採用C語言實現，實際上他只是一個socket庫的從新封裝，若是咱們作爲消息隊列使用，須要開發大量的代碼

RabbitMQ :結合erlang語言自己的併發優點，性能較好，可是不利於作二次開發和維護

ActiveMQ: 歷史悠久的開源項目，已經在不少產品中獲得應用，實現了JMS1.1規範，能夠和spring-jms輕鬆融合，實現了多種協議，不夠輕巧（源代碼比RocketMQ多）.，支持持久化到數據庫，對隊列數較多的狀況支持很差，不過咱們的項目中並不會建不少的隊列.

Redis 作爲一個基於內存的K-V數據庫，其提供了消息訂閱的服務，能夠看成MQ來使用，目前應用案例較少，且不方便擴展

RocketMQ: 阿里巴巴的MQ中間件，在其多個產品下使用，並可以撐住雙十一的大流量，他並無實現JMS規範，使用起來很簡單。部署由一個 命名服務（nameserver）和一個代理（broker）組成，nameserver和broker以及producer都支持集羣，隊列的容量受機器硬盤的限制，隊列滿後能夠支持持久化到硬盤（也能夠本身適配代碼，將其持久化到NOSQL數據庫中），隊列滿後會影響吞吐量，能夠採用主備來保證穩定性，支持回溯消費，能夠在broker端進行消息過濾.

針對消息中間件的選擇能夠從如下方面進行考慮：(主要對比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 等接口，