消息隊列篇—經常使用消息隊列MQ產品介紹及對比

MQ做爲中間件，消息隊列是分佈式應用間交換信息的重要組件。消息隊列可存儲在內存和磁盤上，隊列能夠存儲消息直至它們被應用程序接收。經過消息隊列在應用程序不知道彼此位置的狀況下能夠獨立處理信息或在處理消息前不須要等待接收該消息。全部消息隊列能夠解決應用解耦、異步消息等問題，是實現高性能、高可用、可伸縮和一致性架構中不可或缺的一環。

目前業界有不少MQ產品，小編做以下對比：

ZeroMQ：號稱最快的消息隊列系統，尤爲針對大吞吐量的需求場景。擴展性好，開發比較靈活，採用C語言實現，實際上只是一個socket庫的從新封裝，若是作爲消息隊列使用，須要開發大量的代碼。ZeroMQ僅提供非持久性的隊列，也就是說若是down機，數據將會丟失。其中，Twitter的Storm中使用ZeroMQ做爲數據流的傳輸。

RabbitMQ：結合erlang語言自己的併發優點，支持不少的協議：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它變的很是重量級，更適合於企業級的開發。性能較好，可是不利於作二次開發和維護。

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

Redis：作爲一個基於內存的K-V數據庫，其提供了消息訂閱的服務，能夠看成MQ來使用，目前應用案例較少，且不方便擴展。對於RabbitMQ和Redis的入隊和出隊操做，各執行100萬次，每10萬次記錄一次執行時間。測試數據分爲 128Bytes、512Bytes、1K和10K四個不一樣大小的數據。實驗代表：入隊時，當數據比較小時Redis的性能要高於RabbitMQ，而如 果數據大小超過了10K，Redis則慢的沒法忍受；出隊時，不管數據大小，Redis都表現出很是好的性能，而RabbitMQ的出隊性能則遠低於 Redis。

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

Jafka/Kafka：Kafka是Apache下的一個子項目，是一個高性能跨語言分佈式Publish/Subscribe消息隊列系統，而Jafka是在Kafka 之上孵化而來的，即Kafka的一個升級版。

具備如下特性：快速持久化，能夠在O(1)的系統開銷下進行消息持久化；高吞吐，在一臺普通的服務器上既能夠 達到10W/s的吞吐速率；徹底的分佈式系統，Broker、Producer、Consumer都原生自動支持分佈式，自動實現複雜均衡；支持 Hadoop數據並行加載，對於像Hadoop的同樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka經過 Hadoop的並行加載機制來統一了在線和離線的消息處理，這一點也是本課題所研究系統所看重的。

Apache Kafka相對於ActiveMQ是一個很是輕量級的消息系統，除了性能很是好以外，仍是一個工做良好的分佈式系統。

針對消息中間件的選擇能夠從如下方面進行考慮，以ActiveMQ和RocketMQ對比做爲案例。

優先級：咱們的項目對此需求不是特別明顯，RocketMQ須要新建一個特殊隊列來接收優先級高的隊列，沒法實現從0-65535這種細粒度的控制，ActiveMQ能夠精細控制。

順序：咱們的消息總線中的消息應該都是無狀態的，因此對消息的處理順序沒有嚴格的要求，若是有特殊要求的話能夠在業務層進行控制，activeMQ沒法保證嚴格的順序，RocketMQ能夠保證嚴格的消費順序。

持久化：都支持

穩定性：RoketMQ在穩定性上可能更值得信賴，支持多種集羣方案。

消息過濾：ActiveMQ僅支持在客戶端消費的時候進行判斷是不是本身須要的消息，RocketMQ能夠在broker端進行過濾，對於咱們的消息總線，這裏能夠節省大量的網絡傳輸是否會有消息重發形成的重複消費：RocketMQ能夠保證，ActiveMQ沒法保證。

回溯消費：即從新將某一個時刻以前的消息從新消費一遍，咱們對於這種需求應該不多，RocketMQ支持，ActiveMQ不支持（RocketMQ的隊列是持久化到硬盤的，按期進行清除。

事務：都支持

定時消費：RocketMQ支持

消息堆積：就是當緩存消息的內存滿了以後的解決方案，一種是丟棄策略，這種不會影響吞吐量，還有一種就是將消息持久化到磁盤，這種會影響吞吐量，在評估影響程度上，RocketMQ的成績稍微好一點。

客戶端不在線：RocketMQ能夠在客戶端上線後繼續將未消費的消息推送到客戶端。