消息隊列中間件的技術選型分析

【http://cloudate.net/?p=1165】2015/04/25  |  消息隊列 |  羅伯特

消息隊列中間件是互聯網行業不可或缺的一項基本技術，在高併發消峯，非關鍵業務異步化，通知系統，監控數據推送等場景下是必不可少的，下文爲轉載文章，具體出處不詳。

我的很喜歡ZeroMQ，非企業級的消息中間件，具備及低延遲-微秒級，使用簡單靈活可嵌入等特性，性能報告請參考官網：
http://zeromq.org/results:more-precise-0mq-tests

消息中間件是一種由消息傳送機制或消息隊列模式組成的中間件技術，利用高效可靠的消息傳遞機制進行平臺無關的數據交流，並基於數據通訊來進行分佈式系統的集成。目前業界有不少的MQ產品，像RabbitMQ、ActiveMQ、ZeroMQ等都是極好的消息中間件，可是咱們在項目中該選擇哪一個更適合呢？本文針對如下幾種消息隊列產品做了評估比較：RabbitMQ、ZeroMQ、ActiveMQ、MSMQ、Redis、memcacheQ

題外話：這裏咱們能夠先思考個小問題「Web應用中爲何會須要消息隊列服務？」
在高併發環境下，因爲來不及同步處理，請求每每會發生堵塞(主要緣由)，好比說，大量的insert，update之類的請求同時到達mysql，直接致使無數的行鎖表鎖，甚至最後請求會堆積過多，從而觸發too many connections錯誤。經過使用消息隊列，咱們能夠異步處理請求，從而緩解系統的壓力。

RabbitMQ
是使用Erlang編寫的一個開源的消息隊列，自己支持不少的協議：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它變的很是重量級，更適合於企業級的開發。是AMQP協議領先的一個實現，它實現了代理(Broker)架構，意味着消息在發送到客戶端以前能夠在中央節點上排隊。對路由(Routing)，負載均衡(Load balance)或者數據持久化都有很好的支持。此特性使得RabbitMQ易於使用和部署，適宜於不少場景如路由、負載均衡或消息持久化等，用消息隊列只需幾行代碼便可搞定。可是，這使得它的可擴展性差，速度較慢，由於中央節點增長了延遲，消息封裝後也比較大。如需配置RabbitMQ則須要在目標機器上安裝Erlang環境。

ØMQ(ZeroMQ)
號稱最快的消息隊列系統，尤爲針對大吞吐量的需求場景。是一個很是輕量級的消息系統，專門爲高吞吐量/低延遲的場景開發，在金融界的應用中常常能夠發現它。與RabbitMQ相比，ZeroMQ支持許多高級消息場景，可是你必須實現ZeroMQ框架中的各個塊（好比Socket或Device等）。

ØMQ(ZeroMQ)可以實現RabbitMQ不擅長的高級/複雜的隊列，可是開發人員須要本身組合多種技術框架，技術上的複雜度是對這MQ可以應用成功的挑戰。ZeroMQ具備一個獨特的非中間件的模式，你不須要安裝和運行一個消息服務器或中間件，由於你的應用程序將扮演了這個服務角色。你只須要簡單的引用ZeroMQ程序庫，可使用NuGet安裝，而後你就能夠愉快的在應用程序之間發送消息了。可是ZeroMQ僅提供非持久性的隊列，也就是說若是down機，數據將會丟失。其中，Twitter的Storm中使用ZeroMQ做爲數據流的傳輸。ZeroMQ很是靈活，可是你必須學習它的80頁的手冊（若是你要寫一個分佈式系統，必定要閱讀它）。

ZeroMQ沒有中間件架構，不須要任何服務進程和運行。事實上，你的應用程序端點扮演了這個服務角色。這讓部署起來很是簡單，但擔憂的是，你沒有地方能夠觀察它是否有問題出現。就目前瞭解到的，ZeroMQ僅提供非持久性的隊列。你能夠在須要的地方實現本身的審計和數據恢復功能。MSMQ
這是微軟的產品裏惟一被認爲有價值的東西。若是MSMQ能證實能夠應對這種任務，他們將選擇使用它。關鍵是這個東西並不複雜，除了接收和發送，沒有別的；它有一些硬性限制，好比最大消息體積是4MB。然而，經過和一些像MassTransit 或 NServiceBus這樣的軟件的鏈接，它徹底能夠解決這些問題。

Jafka/Kafka
kafka（能將消息分散到不一樣的節點上）是LinkedIn於2010年12月開發並開源的一個分佈式MQ系統，如今是Apache的一個孵化項目，是一個高性能跨語言分佈式Publish/Subscribe消息隊列系統，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。具備如下特性：快速持久化，能夠在O(1)的系統開銷下進行消息持久化；高吞吐，在一臺普通的服務器上既能夠達到10W/s的吞吐速率；徹底的分佈式系統，Broker、Producer、Consumer都原生自動支持分佈式，自動實現複雜均衡；支持Hadoop數據並行加載，對於像Hadoop的同樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka經過Hadoop的並行加載機制來統一了在線和離線的消息處理，這一點也是本課題所研究系統所看重的。Apache Kafka相對於ActiveMQ是一個很是輕量級的消息系統，除了性能很是好以外，仍是一個工做良好的分佈式系統。

Apache ActiveMQ
ActiveMQ居於二者(RabbitMQ & ZeroMQ)之間，相似於ZemoMQ，它能夠部署於代理模式和P2P模式。相似於RabbitMQ，它易於實現高級場景，並且只需付出低消耗。
ActiveMQ被譽爲Java世界的中堅力量。它有很長的歷史，並且被普遍的使用。它仍是跨平臺的，給那些非微軟平臺的產品提供了一個自然的集成接入點。然而，它只有跑過了MSMQ纔有可能被考慮。如需配置ActiveMQ則須要在目標機器上安裝Java環境。

 

須要注意一點的是ActiveMQ的下一代產品爲Apollo，Apollo以ActiveMQ原型爲基礎，是一個更快、更可靠、更易於維護的消息代理工具。Apache稱Apollo爲最快、最強健的STOMP（Streaming Text Orientated Message Protocol，流文本定向消息協議）服務器。
Apollo的特性以下：
支持Stomp 1.0和Stomp 1.1協議
主題和隊列
隊列瀏覽器
主題持久訂閱
鏡像隊列
可靠的消息傳遞
消息過時和交換
消息選擇器
JAAS驗證
基於ACL的受權
支持SSL/TLS，證書驗證
REST Management API

 

Redis
是一個Key-Value的NoSQL數據庫，開發維護很活躍，雖然它是一個Key-Value數據庫存儲系統，但它自己支持MQ功能，因此徹底能夠當作一個輕量級的隊列服務來使用。對於RabbitMQ和Redis的入隊和出隊操做，各執行100萬次，每10萬次記錄一次執行時間。測試數據分爲128Bytes、512Bytes、1K和10K四個不一樣大小的數據。實驗代表：入隊時，當數據比較小時Redis的性能要高於RabbitMQ，而若是數據大小超過了10K，Redis則慢的沒法忍受；出隊時，不管數據大小，Redis都表現出很是好的性能，而RabbitMQ的出隊性能則遠低於Redis。

MemcacheQ
持久化消息隊列memcacheq(簡稱mcq)是一個輕量級的消息隊列，MemcacheQ的特性：
1 簡單易用
2 處理速度快
3 多條隊列
4 併發性能好
5 與memcache的協議兼容。這就意味着只要裝了memcache的extension就能夠了，不須要額外的插件。
6 在zend framework中使用也很方便。

---

最終，這幾個產品：
1. 都有各自客戶端API或支持多種編程語言；
2. 都有大量的文檔；
3. 都提供了積極的支持。
4. ActiveMQ、RabbitMQ、MSMQ、Redis都須要啓動服務進程，這些均可以監控和配置，其餘幾個就有問題了
5. 都相對提供了良好的可靠性(一致性)、擴展性和負載均衡，固然還有性能

這裏就不瞎扯了，下面附上一組從網上截取的測試結果。顯示的是發送和接受的每秒鐘的消息數。整個過程共產生1百萬條1K的消息。測試的執行是在一個Windows Vista單機上進行的。

就像你看到的，ZeroMQ和其它的不是一個級別。它的性能驚人的高。儘管這樣，但這個產品不提供消息持久化、沒法方便存儲及監控中間過程，須要本身實現審計和數據恢復，所以在易用性和HA上不是使人滿意。結論很清楚：若是你但願一個應用程序發送消息越快越好，你選擇ZeroMQ。當你不太在乎偶然會丟失某些消息的狀況下更有價值。

本文博主將來往事更但願(也不是很但願很但願)選擇使用的是Rabbit，Rabbitmq內置了ha，若是組建cluster，負載均衡之類的問題就無需擔心了同時能夠設置隊列鏡像。但這種事情是應該作更多的測試，你最終會有一個最愛，我所聽到的、讀到的各類關於Rabbit的事情讓我以爲它應該是最佳選擇。

其餘一些隊列列表，這裏就再也不一一分析，若是須要了解更多可自行google。