您好,登錄后才能下訂單哦!
本篇內容主要講解“各大主流消息中間件有哪些區(qū)別”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“各大主流消息中間件有哪些區(qū)別”吧!
目錄
前言
1. 主流消息中間件介紹——ActiveMQ
1.1 特點
1.2 架構模式
1.3 小結
2. 主流消息中間件介紹——Kafka
2.1 特點
2.2 架構模式
2.3 小結
3. 主流消息中間件介紹——RocketMQ
3.1 特點
3.2 架構模式
3.3 小結
4. 為什么選擇RabbitMQ?
5. 主流消息中間件介紹——RabbitMQ
5.1 特點
6. 對比分析圖
消息隊列已經逐漸成為企業(yè)IT系統(tǒng)內部通信的核心手段。它具有低耦合、可靠投遞、廣播、流量控制、最終一致性等一系列功能,成為異步RPC的主要手段之一。當今市面上有很多主流的消息中間件,如老牌的ActiveMQ、RabbitMQ,炙手可熱的Kafka,阿里巴巴自主開發(fā)RocketMQ等。今天主要來介紹了下幾大主流消息中間件的區(qū)別與聯(lián)系。
ActiveMQ是由Apache出品,ActiveMQ是一個完全支持JMS1.1和J2EE 1.4規(guī)范的JMS Provider實現(xiàn)。它非常快速,支持多種語言的客戶端和協(xié)議,而且可以非常容易的嵌入到企業(yè)的應用環(huán)境中,并有許多高級功能。
ActiveMQ是Apache出品,最流行的,能力強勁的開源消息總線,并且它是一個完全支持JMS規(guī)范的消息中間件
其豐富的API、多種集群構建模式使得他成為業(yè)界老牌消息中間件,在中小型企業(yè)中應用廣泛!
MQ衡量指標:服務性能、數(shù)據(jù)存儲、集群架構。
ActiveMQ現(xiàn)在用的比較少,因為ActiveMQ相比其他的MQ的性能來說比較一般。現(xiàn)如今高并發(fā)、大數(shù)據(jù)的應用場景隨處可見。如果這時候在MQ的選擇上,那么ActiveMQ就顯得力不從心了。
衡量一個MQ的指標,主要有三個方面:服務性能、數(shù)據(jù)存儲、集群架構
服務性能:ActiveMQ的性能不是特別好,面對超大規(guī)模并發(fā)時候,總是會出現(xiàn)各種各樣的小問題,比如阻塞,消息堆積過多,產生一些延遲等等一些問題。
數(shù)據(jù)存儲:ActiveMQ默認采用KahaDB內存存儲方式。也可以采用一些高性能的存儲方式,比如:google的LevelDb 基于內c存的。如果是為了保證消息的可靠,也可以采用mysql或者oracle數(shù)據(jù)庫。
集群架構:ActiveMQ流行那么多年,與其他組件集成的Api也是十分完善的。如果不是特別大的并發(fā)場景下,ActiveMQ也是一個不錯的選擇。因為ActiveMQ的集群架構模式也是十分好。
Masrer-Slave模式
主備模式,利用Zookeeper進行兩個或多個節(jié)點的協(xié)調。其中的主節(jié)點是對外提供服務的,而另外的從節(jié)點啟動著,但是不對外提供服務。當主節(jié)點掛掉,利用Zookeeper進行一個高可用的切換,將Salve節(jié)點切換成主節(jié)點,繼續(xù)對外提供服務。
NetWork模式
本質是兩組主備模式的集成,中間用NewWork網關,做一個連接配置,就可以實現(xiàn)分布式集群。
優(yōu)點:
跨平臺(JAVA編寫與平臺無關,ActiveMQ幾乎可以運行在任何的JVM上)
可以用JDBC:可以將數(shù)據(jù)持久化到數(shù)據(jù)庫。雖然使用JDBC會降低ActiveMQ的性能,但是數(shù)據(jù)庫一直都是開發(fā)人員最熟悉的存儲介質
支持JMS規(guī)范:支持JMS規(guī)范提供的統(tǒng)一接口
支持自動重連和錯誤重試機制
有安全機制:支持基于shiro,jaas等多種安全配置機制,可以對Queue/Topic進行認證和授權
監(jiān)控完善:擁有完善的監(jiān)控,包括WebConsole,JMX,Shell命令行,Jolokia的RESTful API
界面友善:提供的WebConsole可以滿足大部分情況,還有很多第三方的組件可以使用,比如hawtio
缺點:
社區(qū)活躍度不及RabbitMQ高
根據(jù)其他用戶反饋,會出莫名其妙的問題,會丟失消息
目前重心放到activemq6.0產品Apollo,對5.x的維護較少
不適合用于上千個隊列的應用場景
Apache Kafka是一個分布式消息發(fā)布訂閱系統(tǒng)。它最初由LinkedIn公司基于獨特的設計實現(xiàn)為一個分布式的日志提交系統(tǒng)(a distributed commit log),之后成為Apache項目的一部分。Kafka性能高效、可擴展良好并且可持久化。它的分區(qū)特性,可復制和可容錯都是其不錯的特性。
kafka是LinkedIn開源的分布式發(fā)布-定于消息系統(tǒng),目前歸屬于Apache頂級項目。Kafka主要特點是給予Pull的模式來處理消費消息,追求高吞吐量,一開始的目的就是用于日志收集和傳輸。0.8版本開始支持復制,不支持事務,對消息的重復、丟失、錯誤沒有嚴格要求,適合產生大量數(shù)據(jù)的互聯(lián)網服務的數(shù)據(jù)收集業(yè)務。這里可以看出kafka只關注吞吐量。因此,在使用kafka的時候,注意業(yè)務是否允許消息重復、丟失、錯誤等。如果允許的話,kafka是最合適的。因為它的性能是最高的。即使在廉價的服務器上,也能支持單機每秒100k條以上的數(shù)據(jù)量。所以說它的性能是非常好的。kafka僅僅使用內存進行存儲,只要有足夠的內存,就能夠足夠大的吞吐量。因為kafka并沒有在磁盤上進行讀寫。
快速持久化:可以在O(1)的系統(tǒng)開銷下進行消息持久化;
高吞吐:在一臺普通的服務器上既可以達到10W/s的吞吐速率;
完全的分布式系統(tǒng):Broker、Producer和Consumer都原生自動支持分布式,自動實現(xiàn)負載均衡;
支持同步和異步復制兩種高可用機制;
支持數(shù)據(jù)批量發(fā)送和拉?。?/p>
零拷貝技術(zero-copy):減少IO操作步驟,提高系統(tǒng)吞吐量;
數(shù)據(jù)遷移、擴容對用戶透明;
無需停機即可擴展機器;
其他特性:豐富的消息拉取模型、高效訂閱者水平擴展、實時的消息訂閱、億級的消息堆積能力、定期刪除機制
kafka架構模式
主要依賴Zookeeper進行協(xié)調管理,每一個kafka可以進行副本復制,也就是數(shù)據(jù)同步。假如說:有一條數(shù)據(jù)落在第一個節(jié)點上,那么就會進行repilicate 復制,這樣在運行中每個節(jié)點就有一份數(shù)據(jù),一共就有三分數(shù)據(jù)。如果說其中一臺宕機,也能從另外兩個節(jié)點中獲取數(shù)據(jù)。部署方案建議:跨機房部署。即使有一臺機子宕機,在數(shù)據(jù)上也是沒有問題的。如果在整個地點宕機了。那么我們的數(shù)據(jù)也就丟失了。這也是大公司需要考慮的異地災備。當然kafka主要關注性能的,對于數(shù)據(jù)的可靠性關注并高。
優(yōu)點:
客戶端語言豐富:支持Java、.Net、PHP、Ruby、Python、Go等多種語言;
高性能:單機寫入TPS約在100萬條/秒,消息大小10個字節(jié);
提供完全分布式架構,并有replica機制,擁有較高的可用性和可靠性,理論上支持消息無限堆積;
支持批量操作;
消費者采用Pull方式獲取消息。消息有序,通過控制能夠保證所有消息被消費且僅被消費一次;
有優(yōu)秀的第三方KafkaWeb管理界面Kafka-Manager;
在日志領域比較成熟,被多家公司和多個開源項目使用。
缺點:
Kafka單機超過64個隊列/分區(qū)時,Load時會發(fā)生明顯的飆高現(xiàn)象。隊列越多,負載越高,發(fā)送消息響應時間變長;
使用短輪詢方式,實時性取決于輪詢間隔時間;
消費失敗不支持重試;
支持消息順序,但是一臺代理宕機后,就會產生消息亂序;
社區(qū)更新較慢。
RocketMQ是阿里開源的消息中間件,目前也已經孵化為Apache頂級項目。用Java語言實現(xiàn),在設計時參考了Kafka,并做出了自己的一些改進,消息可靠性上比Kafka更好。RocketMQ在阿里內部被廣泛應用在訂單,交易,充值,流計算,消息推送,日志流式處理,binglog分發(fā)等場景。
核心的特點如下:
保證消息的順序性,消息按順序消費。
提供了豐富的拉取和處理模式。
高效的訂閱者,也可以進行水平擴展。
承載上億級別的消息堆積能力。
RocketMQ集群架構模式
1.Master-Slave(主從)模式
2.雙Master模式。
3.雙主雙從模式。
4.多主多從模式。
5.一主多從模式。
可選方案許多種可供選擇。
等等,參考了許多開源的設方式。
集群拓撲
阿里覺得Zookeeper性能太低,自己搭建了NameServer,這個NameServer代碼也十分精簡,一共也就幾百行代碼。有興趣可以去讀源碼。
優(yōu)點:
單機支持1萬以上持久化隊列;
RocketMQ的所有消息都是持久化的,先寫入系統(tǒng)PAGECACHE,然后刷盤,可以保證內存與磁盤都有一份數(shù)據(jù),而訪問時,直接從內存讀取。
模型簡單,接口易用(JMS的接口很多場合并不太實用);
性能非常好,可以允許大量堆積消息在Broker中;
支持多種消費模式,包括集群消費、廣播消費等;
各個環(huán)節(jié)分布式擴展設計,支持主從和高可用;
開發(fā)度較活躍,版本更新很快。
缺點:
支持的 客戶端語言不多,目前是Java及C++,其中C++還不成熟
維護RocketMQ需要專業(yè)的團隊
商業(yè)版收費,有許多功能是不對外提供的。
沒有在MQ核心里實現(xiàn)JMS等接口
1.ActiveMQ,性能不是很好,因此在高并發(fā)的場景下,直接被pass掉了。它的Api很完善,在中小型互聯(lián)網公司可以去使用。
2.kafka,主要強調高性能,如果對業(yè)務需要可靠性消息的投遞的時候。那么就不能夠選擇kafka了。但是如果做一些日志收集呢,kafka還是很好的。因為kafka的性能是十分好的。
3.RocketMQ,它的特點非常好。它高性能、滿足可靠性、分布式事物、支持水平擴展、上億級別的消息堆積、主從之間的切換等等。MQ的所有優(yōu)點它基本都滿足。但是它最大的缺點:商業(yè)版收費。因此它有許多功能是不對外提供的。
那么說完這三種MQ還有沒有其他MQ能夠選擇呢?有的,也是這次學習的MQ——RabbitMQ。
RabbitMQ于2007年發(fā)布,是一個在AMQP(高級消息隊列協(xié)議)基礎上完成的,可復用的企業(yè)消息系統(tǒng),是當前最主流的消息中間件之一。
RabbitMQ是使用Erlang語言開發(fā)的開源消息隊列系統(tǒng),基于AMQP協(xié)議來實現(xiàn)。
AMQP的主要特征是面向消息、隊列、路由(包括點對點和發(fā)布/訂閱)、可靠性、安全。
AMQP協(xié)議更多用在企業(yè)系統(tǒng)內,對數(shù)據(jù)一致性、穩(wěn)定性和可靠性要求很高的場景,對性能和吞吐量的要求還在其次。
RabbitMQ的可靠性是非常好的,數(shù)據(jù)能夠保證百分之百的不丟失??梢允褂苗R像隊列,它的穩(wěn)定性非常好。所以說在我們互聯(lián)網的金融行業(yè)。對數(shù)據(jù)的穩(wěn)定性和可靠性要求都非常高的情況下,我們都會選擇RabbitMQ。當然沒有kafka性能好,但是要比AvtiveMQ性能要好很多。也可以自己做一些性能的優(yōu)化。
RabbitMQ可以構建異地雙活架構,包括每一個節(jié)點存儲方式可以采用磁盤或者內存的方式。
RabbitMQ的集群架構
圖中說的就是,我們可以采用三個節(jié)點作為RabbitMQ的一組集群,當然可以有許多組。節(jié)點與節(jié)點之間采用mirror queue?;谶@種方式,能夠保證數(shù)據(jù)百分之百的不丟失。
前端可以去做負載均衡,比如負載均衡組件:HA-proxy ,進行TCP級別的負載。
如果想做一個高可用的話,就需要借助keepAlived做一個高可用的配置。
比如前端加一個虛擬的VIP,通過VIP路由到指定的負載均衡組件,再有它路由到RabbtMQ的某一個節(jié)點。
這就是整個RabbitMQ集群架構。
能夠實現(xiàn)非常完善,高可用并且性能也十分好,穩(wěn)定性超強。并且有各種集群恢復手段。
比如:某一個節(jié)點掛了,或者某個磁盤損壞了,它也能進行一個消息修復?;谶@么多優(yōu)點,我們一定要把RabbitMQ學好。
到此,相信大家對“各大主流消息中間件有哪些區(qū)別”有了更深的了解,不妨來實際操作一番吧!這里是億速云網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續(xù)學習!
免責聲明:本站發(fā)布的內容(圖片、視頻和文字)以原創(chuàng)、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經查實,將立刻刪除涉嫌侵權內容。