消息中間件——RabbitMQ（二）各大主流消息中間件綜合對比介紹！

前言

消息隊列已經逐漸成爲企業IT系統內部通訊的核心手段。它具備低耦合、可靠投遞、廣播、流量控制、最終一致性等一系列功能，成爲異步RPC的主要手段之一。當今市面上有不少主流的消息中間件，如老牌的ActiveMQ、RabbitMQ，煊赫一時的Kafka，阿里巴巴自主開發RocketMQ等。今天主要來介紹了下幾大主流消息中間件的區別與聯繫。

1. 主流消息中間件介紹——ActiveMQ

ActiveMQ是由Apache出品，ActiveMQ是一個徹底支持JMS1.1和J2EE 1.4規範的JMS Provider實現。它很是快速，支持多種語言的客戶端和協議，並且能夠很是容易的嵌入到企業的應用環境中，並有許多高級功能。

1.1 特色

• ActiveMQ是Apache出品，最流行的，能力強勁的開源消息總線，而且它是一個徹底支持JMS規範的消息中間件
• 其豐富的API、多種集羣構建模式使得他成爲業界老牌消息中間件，在中小型企業中應用普遍!
• MQ衡量指標：服務性能、數據存儲、集羣架構。

ActiveMQ如今用的比較少，由於ActiveMQ相比其餘的MQ的性能來講比較通常。現現在高併發、大數據的應用場景隨處可見。若是這時候在MQ的選擇上，那麼ActiveMQ就顯得力不從心了。

衡量一個MQ的指標，主要有三個方面：服務性能、數據存儲、集羣架構 服務性能：ActiveMQ的性能不是特別好，面對超大規模併發時候，老是會出現各類各樣的小問題，好比阻塞，消息堆積過多，產生一些延遲等等一些問題。 數據存儲：ActiveMQ默認採用KahaDB內存存儲方式。也能夠採用一些高性能的存儲方式，好比：google的LevelDb 基於內c存的。若是是爲了保證消息的可靠，也能夠採用mysql或者oracle數據庫。 集羣架構：ActiveMQ流行那麼多年，與其餘組件集成的Api也是十分完善的。若是不是特別大的併發場景下，ActiveMQ也是一個不錯的選擇。由於ActiveMQ的集羣架構模式也是十分好。

1.2 架構模式

Masrer-Slave模式 主備模式，利用Zookeeper進行兩個或多個節點的協調。其中的主節點是對外提供服務的，而另外的從節點啓動着，可是不對外提供服務。當主節點掛掉，利用Zookeeper進行一個高可用的切換，將Salve節點切換成主節點，繼續對外提供服務。

NetWork模式

本質是兩組主備模式的集成，中間用NewWork網關，作一個鏈接配置，就能夠實現分佈式集羣。

1.3 小結

優勢：

• 跨平臺(JAVA編寫與平臺無關，ActiveMQ幾乎能夠運行在任何的JVM上)
• 能夠用JDBC：能夠將數據持久化到數據庫。雖然使用JDBC會下降ActiveMQ的性能，可是數據庫一直都是開發人員最熟悉的存儲介質
• 支持JMS規範：支持JMS規範提供的統一接口
• 支持自動重連和錯誤重試機制
• 有安全機制：支持基於shiro，jaas等多種安全配置機制，能夠對Queue/Topic進行認證和受權
• 監控完善：擁有完善的監控，包括WebConsole，JMX，Shell命令行，Jolokia的RESTful API
• 界面友善：提供的WebConsole能夠知足大部分狀況，還有不少第三方的組件可使用，好比hawtio

缺點：

• 社區活躍度不及RabbitMQ高
• 根據其餘用戶反饋，會出莫名其妙的問題，會丟失消息
• 目前重心放到activemq6.0產品Apollo，對5.x的維護較少
• 不適合用於上千個隊列的應用場景

2. 主流消息中間件介紹——Kafka

Apache Kafka是一個分佈式消息發佈訂閱系統。它最初由LinkedIn公司基於獨特的設計實現爲一個分佈式的日誌提交系統(a distributed commit log)，以後成爲Apache項目的一部分。Kafka性能高效、可擴展良好而且可持久化。它的分區特性，可複製和可容錯都是其不錯的特性。

2.1 特色

kafka是LinkedIn開源的分佈式發佈-定於消息系統，目前歸屬於Apache頂級項目。Kafka主要特色是給予Pull的模式來處理消費消息，追求高吞吐量，一開始的目的就是用於日誌收集和傳輸。0.8版本開始支持複製，不支持事務，對消息的重複、丟失、錯誤沒有嚴格要求，適合產生大量數據的互聯網服務的數據收集業務。這裏能夠看出kafka只關注吞吐量。所以，在使用kafka的時候，注意業務是否容許消息重複、丟失、錯誤等。若是容許的話，kafka是最合適的。由於它的性能是最高的。即便在廉價的服務器上，也能支持單機每秒100k條以上的數據量。因此說它的性能是很是好的。kafka僅僅使用內存進行存儲，只要有足夠的內存，就可以足夠大的吞吐量。由於kafka並無在磁盤上進行讀寫。

• 快速持久化：能夠在O(1)的系統開銷下進行消息持久化；
• 高吞吐：在一臺普通的服務器上既能夠達到10W/s的吞吐速率；
• 徹底的分佈式系統：Broker、Producer和Consumer都原生自動支持分佈式，自動實現負載均衡；
• 支持同步和異步複製兩種高可用機制；
• 支持數據批量發送和拉取；
• 零拷貝技術(zero-copy)：減小IO操做步驟，提升系統吞吐量；
• 數據遷移、擴容對用戶透明；
• 無需停機便可擴展機器；
• 其餘特性：豐富的消息拉取模型、高效訂閱者水平擴展、實時的消息訂閱、億級的消息堆積能力、按期刪除機制

2.2 架構模式

kafka架構模式

主要依賴Zookeeper進行協調管理，每個kafka能夠進行副本複製，也就是數據同步。假如說：有一條數據落在第一個節點上，那麼就會進行repilicate 複製，這樣在運行中每一個節點就有一份數據，一共就有三分數據。若是說其中一臺宕機，也能從另外兩個節點中獲取數據。部署方案建議：跨機房部署。即便有一臺機子宕機，在數據上也是沒有問題的。若是在整個地點宕機了。那麼咱們的數據也就丟失了。這也是大公司須要考慮的異地災備。固然kafka主要關注性能的，對於數據的可靠性關注並高。

2.3 小結

優勢：

• 客戶端語言豐富：支持Java、.Net、PHP、Ruby、Python、Go等多種語言；
• 高性能：單機寫入TPS約在100萬條/秒，消息大小10個字節；
• 提供徹底分佈式架構，並有replica機制，擁有較高的可用性和可靠性，理論上支持消息無限堆積；
• 支持批量操做；
• 消費者採用Pull方式獲取消息。消息有序，經過控制可以保證全部消息被消費且僅被消費一次；
• 有優秀的第三方KafkaWeb管理界面Kafka-Manager；
• 在日誌領域比較成熟，被多家公司和多個開源項目使用。

缺點：

• Kafka單機超過64個隊列/分區時，Load時會發生明顯的飆高現象。隊列越多，負載越高，發送消息響應時間變長；
• 使用短輪詢方式，實時性取決於輪詢間隔時間；
• 消費失敗不支持重試；
• 支持消息順序，可是一臺代理宕機後，就會產生消息亂序；
• 社區更新較慢。

3. 主流消息中間件介紹——RocketMQ

RocketMQ是阿里開源的消息中間件，目前也已經孵化爲Apache頂級項目。用Java語言實現，在設計時參考了Kafka，並作出了本身的一些改進，消息可靠性上比Kafka更好。RocketMQ在阿里內部被普遍應用在訂單，交易，充值，流計算，消息推送，日誌流式處理，binglog分發等場景。

3.1 特色

核心的特色以下：

• 保證消息的順序性，消息按順序消費。
• 提供了豐富的拉取和處理模式。
• 高效的訂閱者，也能夠進行水平擴展。
• 承載上億級別的消息堆積能力。

3.2 架構模式

RocketMQ集羣架構模式 1.Master-Slave（主從）模式 2.雙Master模式。 3.雙主雙從模式。 4.多主多從模式。 5.一主多從模式。 可選方案許多種可供選擇。

等等，參考了許多開源的設方式。

集羣拓撲

阿里以爲Zookeeper性能過低，本身搭建了NameServer，這個NameServer代碼也十分精簡，一共也就幾百行代碼。有興趣能夠去讀源碼。

3.3 小結

優勢：

• 單機支持1萬以上持久化隊列；
• RocketMQ的全部消息都是持久化的，先寫入系統PAGECACHE，而後刷盤，能夠保證內存與磁盤都有一份數據，而訪問時，直接從內存讀取。
• 模型簡單，接口易用（JMS的接口不少場合並不太實用）；
• 性能很是好，能夠容許大量堆積消息在Broker中；
• 支持多種消費模式，包括集羣消費、廣播消費等；
• 各個環節分佈式擴展設計，支持主從和高可用；
• 開發度較活躍，版本更新很快。

缺點：

• 支持的 客戶端語言很少，目前是Java及C++，其中C++還不成熟
• 維護RocketMQ須要專業的團隊
• 商業版收費，有許多功能是不對外提供的。
• 沒有在MQ核內心實現JMS等接口

4. 爲何選擇RabbitMQ？

1.ActiveMQ，性能不是很好，所以在高併發的場景下，直接被pass掉了。它的Api很完善，在中小型互聯網公司能夠去使用。 2.kafka，主要強調高性能，若是對業務須要可靠性消息的投遞的時候。那麼就不可以選擇kafka了。可是若是作一些日誌收集呢，kafka仍是很好的。由於kafka的性能是十分好的。 3.RocketMQ，它的特色很是好。它高性能、知足可靠性、分佈式事物、支持水平擴展、上億級別的消息堆積、主從之間的切換等等。MQ的全部優勢它基本都知足。可是它最大的缺點：商業版收費。所以它有許多功能是不對外提供的。

那麼說完這三種MQ還有沒有其餘MQ可以選擇呢？有的，也是此次學習的MQ——RabbitMQ。

5. 主流消息中間件介紹——RabbitMQ

RabbitMQ於2007年發佈，是一個在AMQP(高級消息隊列協議)基礎上完成的，可複用的企業消息系統，是當前最主流的消息中間件之一。

5.1 特色

RabbitMQ是使用Erlang語言開發的開源消息隊列系統，基於AMQP協議來實現。 AMQP的主要特徵是面向消息、隊列、路由（包括點對點和發佈/訂閱）、可靠性、安全。 AMQP協議更多用在企業系統內，對數據一致性、穩定性和可靠性要求很高的場景，對性能和吞吐量的要求還在其次。 RabbitMQ的可靠性是很是好的，數據可以保證百分之百的不丟失。可使用鏡像隊列，它的穩定性很是好。因此說在咱們互聯網的金融行業。對數據的穩定性和可靠性要求都很是高的狀況下，咱們都會選擇RabbitMQ。固然沒有kafka性能好，可是要比AvtiveMQ性能要好不少。也能夠本身作一些性能的優化。 RabbitMQ能夠構建異地雙活架構，包括每個節點存儲方式能夠採用磁盤或者內存的方式。

RabbitMQ的集羣架構

圖中說的就是，咱們能夠採用三個節點做爲RabbitMQ的一組集羣，固然能夠有許多組。節點與節點之間採用mirror queue。基於這種方式，可以保證數據百分之百的不丟失。 前端能夠去作負載均衡，好比負載均衡組件：HA-proxy ，進行TCP級別的負載。 若是想作一個高可用的話，就須要藉助keepAlived作一個高可用的配置。 好比前端加一個虛擬的VIP，經過VIP路由到指定的負載均衡組件，再有它路由到RabbtMQ的某一個節點。 這就是整個RabbitMQ集羣架構。 可以實現很是完善，高可用而且性能也十分好，穩定性超強。而且有各類集羣恢復手段。 好比:某一個節點掛了，或者某個磁盤損壞了，它也能進行一個消息修復。基於這麼多優勢，咱們必定要把RabbitMQ學好。

6. 對比分析圖

圖片來自網絡~

文末

歡迎關注我的微信公衆號：Coder編程 獲取最新原創技術文章和免費學習資料，更有大量精品思惟導圖、面試資料、PMP備考資料等你來領，方便你隨時隨地學習技術知識！ 新建了一個qq羣：315211365，歡迎你們進羣交流一塊兒學習。謝謝了！也能夠介紹給身邊有須要的朋友。

文章收錄至

Github: github.com/CoderMerlin…

Gitee: gitee.com/573059382/c… 歡迎關注並star~

參考文章：

my.oschina.net/blogByRzc/b…

《RabbitMQ消息中間件精講》

推薦文章：

RabbitMQ（一）Windows/Linux環境搭建（完整版）