各大主流消息中間件有哪些區(qū)別

本篇內(nèi)容主要講解“各大主流消息中間件有哪些區(qū)別”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“各大主流消息中間件有哪些區(qū)別”吧!

創(chuàng)新互聯(lián)公司網(wǎng)站建設(shè)公司，提供成都網(wǎng)站制作、成都做網(wǎng)站，網(wǎng)頁設(shè)計(jì)，建網(wǎng)站，PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);可快速的進(jìn)行網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展；專業(yè)做搜索引擎喜愛的網(wǎng)站，是專業(yè)的做網(wǎng)站團(tuán)隊(duì)，希望更多企業(yè)前來合作!

目錄  

前言

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

1.1 特點(diǎn)      

1.2 架構(gòu)模式      

1.3 小結(jié)      

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

2.1 特點(diǎn)      

2.2 架構(gòu)模式      

2.3 小結(jié)      

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

3.1 特點(diǎn)      

3.2 架構(gòu)模式      

3.3 小結(jié)      

4. 為什么選擇RabbitMQ？

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

5.1 特點(diǎn)      

6. 對比分析圖      

前言

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

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

ActiveMQ是由Apache出品，ActiveMQ是一個(gè)完全支持JMS1.1和J2EE 1.4規(guī)范的JMS Provider實(shí)現(xiàn)。它非?？焖?，支持多種語言的客戶端和協(xié)議，而且可以非常容易的嵌入到企業(yè)的應(yīng)用環(huán)境中，并有許多高級功能。

1.1 特點(diǎn)

• ActiveMQ是Apache出品，最流行的，能力強(qiáng)勁的開源消息總線，并且它是一個(gè)完全支持JMS規(guī)范的消息中間件

• 其豐富的API、多種集群構(gòu)建模式使得他成為業(yè)界老牌消息中間件，在中小型企業(yè)中應(yīng)用廣泛!

• MQ衡量指標(biāo)：服務(wù)性能、數(shù)據(jù)存儲、集群架構(gòu)。

ActiveMQ現(xiàn)在用的比較少，因?yàn)锳ctiveMQ相比其他的MQ的性能來說比較一般。現(xiàn)如今高并發(fā)、大數(shù)據(jù)的應(yīng)用場景隨處可見。如果這時(shí)候在MQ的選擇上，那么ActiveMQ就顯得力不從心了。

衡量一個(gè)MQ的指標(biāo)，主要有三個(gè)方面：服務(wù)性能、數(shù)據(jù)存儲、集群架構(gòu)
服務(wù)性能：ActiveMQ的性能不是特別好，面對超大規(guī)模并發(fā)時(shí)候，總是會出現(xiàn)各種各樣的小問題，比如阻塞，消息堆積過多，產(chǎn)生一些延遲等等一些問題。
數(shù)據(jù)存儲：ActiveMQ默認(rèn)采用KahaDB內(nèi)存存儲方式。也可以采用一些高性能的存儲方式，比如：google的LevelDb 基于內(nèi)c存的。如果是為了保證消息的可靠，也可以采用MySQL或者oracle數(shù)據(jù)庫。
集群架構(gòu)：ActiveMQ流行那么多年，與其他組件集成的Api也是十分完善的。如果不是特別大的并發(fā)場景下，ActiveMQ也是一個(gè)不錯(cuò)的選擇。因?yàn)锳ctiveMQ的集群架構(gòu)模式也是十分好。

1.2 架構(gòu)模式

Masrer-Slave模式
主備模式，利用Zookeeper進(jìn)行兩個(gè)或多個(gè)節(jié)點(diǎn)的協(xié)調(diào)。其中的主節(jié)點(diǎn)是對外提供服務(wù)的，而另外的從節(jié)點(diǎn)啟動著，但是不對外提供服務(wù)。當(dāng)主節(jié)點(diǎn)掛掉，利用Zookeeper進(jìn)行一個(gè)高可用的切換，將Salve節(jié)點(diǎn)切換成主節(jié)點(diǎn)，繼續(xù)對外提供服務(wù)。

NetWork模式

本質(zhì)是兩組主備模式的集成，中間用NewWork網(wǎng)關(guān)，做一個(gè)連接配置，就可以實(shí)現(xiàn)分布式集群。

1.3 小結(jié)

優(yōu)點(diǎn)：

• 跨平臺(JAVA編寫與平臺無關(guān)，ActiveMQ幾乎可以運(yùn)行在任何的JVM上)

• 可以用JDBC：可以將數(shù)據(jù)持久化到數(shù)據(jù)庫。雖然使用JDBC會降低ActiveMQ的性能，但是數(shù)據(jù)庫一直都是開發(fā)人員最熟悉的存儲介質(zhì)

• 支持JMS規(guī)范：支持JMS規(guī)范提供的統(tǒng)一接口

• 支持自動重連和錯(cuò)誤重試機(jī)制

• 有安全機(jī)制：支持基于shiro，jaas等多種安全配置機(jī)制，可以對Queue/Topic進(jìn)行認(rèn)證和授權(quán)

• 監(jiān)控完善：擁有完善的監(jiān)控，包括WebConsole，JMX，Shell命令行，Jolokia的RESTful API

• 界面友善：提供的WebConsole可以滿足大部分情況，還有很多第三方的組件可以使用，比如hawtio

缺點(diǎn)：

• 社區(qū)活躍度不及RabbitMQ高

• 根據(jù)其他用戶反饋，會出莫名其妙的問題，會丟失消息

• 目前重心放到activemq6.0產(chǎn)品Apollo，對5.x的維護(hù)較少

• 不適合用于上千個(gè)隊(duì)列的應(yīng)用場景

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

Apache Kafka是一個(gè)分布式消息發(fā)布訂閱系統(tǒng)。它最初由LinkedIn公司基于獨(dú)特的設(shè)計(jì)實(shí)現(xiàn)為一個(gè)分布式的日志提交系統(tǒng)(a distributed commit log)，之后成為Apache項(xiàng)目的一部分。Kafka性能高效、可擴(kuò)展良好并且可持久化。它的分區(qū)特性，可復(fù)制和可容錯(cuò)都是其不錯(cuò)的特性。

2.1 特點(diǎn)

kafka是LinkedIn開源的分布式發(fā)布-定于消息系統(tǒng)，目前歸屬于Apache頂級項(xiàng)目。Kafka主要特點(diǎn)是給予Pull的模式來處理消費(fèi)消息，追求高吞吐量，一開始的目的就是用于日志收集和傳輸。0.8版本開始支持復(fù)制，不支持事務(wù)，對消息的重復(fù)、丟失、錯(cuò)誤沒有嚴(yán)格要求，適合產(chǎn)生大量數(shù)據(jù)的互聯(lián)網(wǎng)服務(wù)的數(shù)據(jù)收集業(yè)務(wù)。這里可以看出kafka只關(guān)注吞吐量。因此，在使用kafka的時(shí)候，注意業(yè)務(wù)是否允許消息重復(fù)、丟失、錯(cuò)誤等。如果允許的話，kafka是最合適的。因?yàn)樗男阅苁亲罡叩摹＜词乖诹畠r(jià)的服務(wù)器上，也能支持單機(jī)每秒100k條以上的數(shù)據(jù)量。所以說它的性能是非常好的。kafka僅僅使用內(nèi)存進(jìn)行存儲，只要有足夠的內(nèi)存，就能夠足夠大的吞吐量。因?yàn)閗afka并沒有在磁盤上進(jìn)行讀寫。

• 快速持久化：可以在O(1)的系統(tǒng)開銷下進(jìn)行消息持久化；

• 高吞吐：在一臺普通的服務(wù)器上既可以達(dá)到10W/s的吞吐速率；

• 完全的分布式系統(tǒng)：Broker、Producer和Consumer都原生自動支持分布式，自動實(shí)現(xiàn)負(fù)載均衡；

• 支持同步和異步復(fù)制兩種高可用機(jī)制；

• 支持?jǐn)?shù)據(jù)批量發(fā)送和拉取；

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

• 數(shù)據(jù)遷移、擴(kuò)容對用戶透明；

• 無需停機(jī)即可擴(kuò)展機(jī)器；

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

2.2 架構(gòu)模式

kafka架構(gòu)模式

主要依賴Zookeeper進(jìn)行協(xié)調(diào)管理，每一個(gè)kafka可以進(jìn)行副本復(fù)制，也就是數(shù)據(jù)同步。假如說：有一條數(shù)據(jù)落在第一個(gè)節(jié)點(diǎn)上，那么就會進(jìn)行repilicate 復(fù)制，這樣在運(yùn)行中每個(gè)節(jié)點(diǎn)就有一份數(shù)據(jù)，一共就有三分?jǐn)?shù)據(jù)。如果說其中一臺宕機(jī)，也能從另外兩個(gè)節(jié)點(diǎn)中獲取數(shù)據(jù)。部署方案建議：跨機(jī)房部署。即使有一臺機(jī)子宕機(jī)，在數(shù)據(jù)上也是沒有問題的。如果在整個(gè)地點(diǎn)宕機(jī)了。那么我們的數(shù)據(jù)也就丟失了。這也是大公司需要考慮的異地災(zāi)備。當(dāng)然kafka主要關(guān)注性能的，對于數(shù)據(jù)的可靠性關(guān)注并高。

2.3 小結(jié)

優(yōu)點(diǎn)：

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

• 高性能：單機(jī)寫入TPS約在100萬條/秒，消息大小10個(gè)字節(jié)；

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

• 支持批量操作；

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

• 有優(yōu)秀的第三方KafkaWeb管理界面Kafka-Manager；

• 在日志領(lǐng)域比較成熟，被多家公司和多個(gè)開源項(xiàng)目使用。

缺點(diǎn)：

• Kafka單機(jī)超過64個(gè)隊(duì)列/分區(qū)時(shí)，Load時(shí)會發(fā)生明顯的飆高現(xiàn)象。隊(duì)列越多，負(fù)載越高，發(fā)送消息響應(yīng)時(shí)間變長；

• 使用短輪詢方式，實(shí)時(shí)性取決于輪詢間隔時(shí)間；

• 消費(fèi)失敗不支持重試；

• 支持消息順序，但是一臺代理宕機(jī)后，就會產(chǎn)生消息亂序；

• 社區(qū)更新較慢。

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

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

3.1 特點(diǎn)

核心的特點(diǎn)如下：

• 保證消息的順序性，消息按順序消費(fèi)。

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

• 高效的訂閱者，也可以進(jìn)行水平擴(kuò)展。

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

3.2 架構(gòu)模式

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

等等，參考了許多開源的設(shè)方式。

集群拓?fù)?/strong>

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

3.3 小結(jié)

優(yōu)點(diǎn)：

• 單機(jī)支持1萬以上持久化隊(duì)列；

• RocketMQ的所有消息都是持久化的，先寫入系統(tǒng)PAGECACHE，然后刷盤，可以保證內(nèi)存與磁盤都有一份數(shù)據(jù)，而訪問時(shí)，直接從內(nèi)存讀取。

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

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

• 支持多種消費(fèi)模式，包括集群消費(fèi)、廣播消費(fèi)等；

• 各個(gè)環(huán)節(jié)分布式擴(kuò)展設(shè)計(jì)，支持主從和高可用；

• 開發(fā)度較活躍，版本更新很快。

缺點(diǎn)：

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

• 維護(hù)RocketMQ需要專業(yè)的團(tuán)隊(duì)

• 商業(yè)版收費(fèi)，有許多功能是不對外提供的。

• 沒有在MQ核心里實(shí)現(xiàn)JMS等接口

4. 為什么選擇RabbitMQ？

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

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

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

RabbitMQ于2007年發(fā)布，是一個(gè)在AMQP(高級消息隊(duì)列協(xié)議)基礎(chǔ)上完成的，可復(fù)用的企業(yè)消息系統(tǒng)，是當(dāng)前最主流的消息中間件之一。

5.1 特點(diǎn)

RabbitMQ是使用Erlang語言開發(fā)的開源消息隊(duì)列系統(tǒng)，基于AMQP協(xié)議來實(shí)現(xiàn)。
AMQP的主要特征是面向消息、隊(duì)列、路由（包括點(diǎn)對點(diǎn)和發(fā)布/訂閱）、可靠性、安全。
AMQP協(xié)議更多用在企業(yè)系統(tǒng)內(nèi)，對數(shù)據(jù)一致性、穩(wěn)定性和可靠性要求很高的場景，對性能和吞吐量的要求還在其次。
RabbitMQ的可靠性是非常好的，數(shù)據(jù)能夠保證百分之百的不丟失?？梢允褂苗R像隊(duì)列，它的穩(wěn)定性非常好。所以說在我們互聯(lián)網(wǎng)的金融行業(yè)。對數(shù)據(jù)的穩(wěn)定性和可靠性要求都非常高的情況下，我們都會選擇RabbitMQ。當(dāng)然沒有kafka性能好，但是要比AvtiveMQ性能要好很多。也可以自己做一些性能的優(yōu)化。
RabbitMQ可以構(gòu)建異地雙活架構(gòu)，包括每一個(gè)節(jié)點(diǎn)存儲方式可以采用磁盤或者內(nèi)存的方式。

RabbitMQ的集群架構(gòu)

圖中說的就是，我們可以采用三個(gè)節(jié)點(diǎn)作為RabbitMQ的一組集群，當(dāng)然可以有許多組。節(jié)點(diǎn)與節(jié)點(diǎn)之間采用mirror queue?；谶@種方式，能夠保證數(shù)據(jù)百分之百的不丟失。
前端可以去做負(fù)載均衡，比如負(fù)載均衡組件：HA-proxy ，進(jìn)行TCP級別的負(fù)載。
如果想做一個(gè)高可用的話，就需要借助keepAlived做一個(gè)高可用的配置。
比如前端加一個(gè)虛擬的VIP，通過VIP路由到指定的負(fù)載均衡組件，再有它路由到RabbtMQ的某一個(gè)節(jié)點(diǎn)。
這就是整個(gè)RabbitMQ集群架構(gòu)。
能夠?qū)崿F(xiàn)非常完善，高可用并且性能也十分好，穩(wěn)定性超強(qiáng)。并且有各種集群恢復(fù)手段。
比如:某一個(gè)節(jié)點(diǎn)掛了，或者某個(gè)磁盤損壞了，它也能進(jìn)行一個(gè)消息修復(fù)?；谶@么多優(yōu)點(diǎn)，我們一定要把RabbitMQ學(xué)好。

6. 對比分析圖

到此，相信大家對“各大主流消息中間件有哪些區(qū)別”有了更深的了解，不妨來實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！