摘要：主流消息中間件介紹是由出品，是一個完全支持和規范的實現。主流消息中間件介紹是阿里開源的消息中間件，目前也已經孵化為頂級項目。

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

ActiveMQ是由Apache出品，ActiveMQ是一個完全支持JMS1.1和J2EE 1.4規范的JMS Provider實現。它非常快速，支持多種語言的客戶端和協議，而且可以非常容易的嵌入到企業的應用環境中，并有許多高級功能。

ActiveMQ是Apache出品，最流行的，能力強勁的開源消息總線，并且它是一個完全支持JMS規范的消息中間件

其豐富的API、多種集群構建模式使得他成為業界老牌消息中間件，在中小型企業中應用廣泛!

MQ衡量指標：服務性能、數據存儲、集群架構。

ActiveMQ現在用的比較少，因為ActiveMQ相比其他的MQ的性能來說比較一般。現如今高并發、大數據的應用場景隨處可見。如果這時候在MQ的選擇上，那么ActiveMQ就顯得力不從心了。

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

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

NetWork模式

本質是兩組主備模式的集成，中間用NewWork網關，做一個連接配置，就可以實現分布式集群。

優點：

跨平臺(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的維護較少

不適合用于上千個隊列的應用場景

Apache Kafka是一個分布式消息發布訂閱系統。它最初由LinkedIn公司基于獨特的設計實現為一個分布式的日志提交系統(a distributed commit log)，之后成為Apache項目的一部分。Kafka性能高效、可擴展良好并且可持久化。它的分區特性，可復制和可容錯都是其不錯的特性。

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

快速持久化：可以在O(1)的系統開銷下進行消息持久化；

高吞吐：在一臺普通的服務器上既可以達到10W/s的吞吐速率；

完全的分布式系統：Broker、Producer和Consumer都原生自動支持分布式，自動實現負載均衡；

支持同步和異步復制兩種高可用機制；

支持數據批量發送和拉取；

零拷貝技術(zero-copy)：減少IO操作步驟，提高系統吞吐量；

數據遷移、擴容對用戶透明；

無需停機即可擴展機器；

其他特性：豐富的消息拉取模型、高效訂閱者水平擴展、實時的消息訂閱、億級的消息堆積能力、定期刪除機制

kafka架構模式

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

優點：

客戶端語言豐富：支持Java、.Net、PHP、Ruby、Python、Go等多種語言；

高性能：單機寫入TPS約在100萬條/秒，消息大小10個字節；

提供完全分布式架構，并有replica機制，擁有較高的可用性和可靠性，理論上支持消息無限堆積；

支持批量操作；

消費者采用Pull方式獲取消息。消息有序，通過控制能夠保證所有消息被消費且僅被消費一次；

有優秀的第三方KafkaWeb管理界面Kafka-Manager；

在日志領域比較成熟，被多家公司和多個開源項目使用。

缺點：

Kafka單機超過64個隊列/分區時，Load時會發生明顯的飆高現象。隊列越多，負載越高，發送消息響應時間變長；

使用短輪詢方式，實時性取決于輪詢間隔時間；

消費失敗不支持重試；

支持消息順序，但是一臺代理宕機后，就會產生消息亂序；

社區更新較慢。

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

核心的特點如下：

保證消息的順序性，消息按順序消費。

提供了豐富的拉取和處理模式。

高效的訂閱者，也可以進行水平擴展。

承載上億級別的消息堆積能力。

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

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

集群拓撲

阿里覺得Zookeeper性能太低，自己搭建了NameServer，這個NameServer代碼也十分精簡，一共也就幾百行代碼。有興趣可以去讀源碼。

優點：

單機支持1萬以上持久化隊列；

RocketMQ的所有消息都是持久化的，先寫入系統PAGECACHE，然后刷盤，可以保證內存與磁盤都有一份數據，而訪問時，直接從內存讀取。

模型簡單，接口易用（JMS的接口很多場合并不太實用）；

性能非常好，可以允許大量堆積消息在Broker中；

支持多種消費模式，包括集群消費、廣播消費等；

各個環節分布式擴展設計，支持主從和高可用；

開發度較活躍，版本更新很快。

缺點：

支持的 客戶端語言不多，目前是Java及C++，其中C++還不成熟

維護RocketMQ需要專業的團隊

商業版收費，有許多功能是不對外提供的。

沒有在MQ核心里實現JMS等接口

1.ActiveMQ，性能不是很好，因此在高并發的場景下，直接被pass掉了。它的Api很完善，在中小型互聯網公司可以去使用。
2.kafka，主要強調高性能，如果對業務需要可靠性消息的投遞的時候。那么就不能夠選擇kafka了。但是如果做一些日志收集呢，kafka還是很好的。因為kafka的性能是十分好的。
3.RocketMQ，它的特點非常好。它高性能、滿足可靠性、分布式事物、支持水平擴展、上億級別的消息堆積、主從之間的切換等等。MQ的所有優點它基本都滿足。但是它最大的缺點：商業版收費。因此它有許多功能是不對外提供的。

那么說完這三種MQ還有沒有其他MQ能夠選擇呢？有的，也是這次學習的MQ——RabbitMQ。

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

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

RabbitMQ的集群架構

圖中說的就是，我們可以采用三個節點作為RabbitMQ的一組集群，當然可以有許多組。節點與節點之間采用mirror queue。基于這種方式，能夠保證數據百分之百的不丟失。
前端可以去做負載均衡，比如負載均衡組件：HA-proxy ，進行TCP級別的負載。
如果想做一個高可用的話，就需要借助keepAlived做一個高可用的配置。
比如前端加一個虛擬的VIP，通過VIP路由到指定的負載均衡組件，再有它路由到RabbtMQ的某一個節點。
這就是整個RabbitMQ集群架構。
能夠實現非常完善，高可用并且性能也十分好，穩定性超強。并且有各種集群恢復手段。
比如:某一個節點掛了，或者某個磁盤損壞了，它也能進行一個消息修復。基于這么多優點，我們一定要把RabbitMQ學好。

圖片來自網絡~

歡迎關注個人微信公眾號：Coder編程
獲取最新原創技術文章和免費學習資料，更有大量精品思維導圖、面試資料、PMP備考資料等你來領，方便你隨時隨地學習技術知識！
新建了一個qq群：315211365，歡迎大家進群交流一起學習。謝謝了！也可以介紹給身邊有需要的朋友。
文章收錄至
Github: https://github.com/CoderMerli...
Gitee: https://gitee.com/573059382/c...
歡迎關注并star~

參考文章：

https://my.oschina.net/blogBy...

《RabbitMQ消息中間件精講》

推薦文章：

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