您好,登錄后才能下訂單哦!
這篇文章主要介紹RabbitMQ中消息中間件是什么意思,文中介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們一定要看完!
什么是消息中間件?
消息中間件屬于分布式系統(tǒng)中的一個子系統(tǒng),關(guān)注于數(shù)據(jù)的發(fā)送和接收,利用高效可靠的消息傳遞機制對分布式系統(tǒng)中的其余各個子系統(tǒng)經(jīng)進行集成
消息中間件的使用場景
1.異步處理非核心流程異步化,提高系統(tǒng)響應(yīng)性能
原來用戶注冊一下可能得依次寫數(shù)據(jù)庫,發(fā)送郵件和短信后,才能提示用戶注冊成功
現(xiàn)在只要寫數(shù)據(jù)庫,寫消息隊列后就直接提示用戶注冊成功,發(fā)送郵件和短信是異步處理,提高了響應(yīng)速度
2.應(yīng)用解耦
系統(tǒng)不是強耦合,消息接受者可以隨意增加,而不需要修改消息發(fā)送者的代碼。消息發(fā)送者的成功不依賴消息接受者
rpc實現(xiàn)
消息隊列實現(xiàn)
如果庫存系統(tǒng)出了問題,用戶就不能正常下單,這是不合理的??梢酝ㄟ^消息隊列來解耦。
當(dāng)有新的系統(tǒng)如廣告系統(tǒng)對用戶的訂單也感興趣的時候,只需要從消息隊列中拿消息即可,訂單系統(tǒng)完全不用改變
3.流量削峰
當(dāng)上下游系統(tǒng)處理能力存在差距的時候,可以用消息隊列進行緩沖
在這里插入圖片描述
當(dāng)有秒殺業(yè)務(wù)時,一下有大量請求涌入時,很可能造成系統(tǒng)癱瘓,此時可以用消息隊列緩沖一下
4.日志處理
將消息隊列用在日志處理中,比如Kafka可以用來解決大量日志傳輸?shù)膯栴}
5.消息通訊
消息隊列一般都內(nèi)置了高效的通信機制,因此也可以用于單純的消息通訊,比如實現(xiàn)點對點消息隊列或者聊天室等
消息中間件編年史
初見曙光
1.消息中間件其實誕生的很早,在互聯(lián)網(wǎng)應(yīng)用還是一片荒蕪的年代,有個在美國的印度哥們Vivek Ranadive就設(shè)想了一種通用軟件總線,采用發(fā)布訂閱的模式,像主板上的總線一樣供其他相應(yīng)程序接入。他創(chuàng)辦了一家公司Teknekron,實現(xiàn)了世界上第一個消息中間件The Information Bus(TIB)
各自為戰(zhàn)
2.TIB受到了企業(yè)的歡迎,Teknekron的業(yè)務(wù)發(fā)展引起了當(dāng)時最牛氣的IT公司IBM的注意,于是他們也開始研發(fā)了自己消息隊列軟件,于是才有了后來的wesphere mq,微軟也陸續(xù)加入了戰(zhàn)團。由于商業(yè)壁壘,商業(yè)MQ供應(yīng)商想要解決應(yīng)用應(yīng)用互通的問題,而不是去創(chuàng)建標準來實現(xiàn)不同MQ產(chǎn)品間的互通,或者允許應(yīng)用程序更改MQ平臺
劫制天下
3.為了打破這個壁壘,同時為了能夠讓消息在各個消息隊列平臺間互融互通, JMS (Java Message Service) 應(yīng)運而生 。JMS 試圖通過提供公共 Java API 的方式,隱藏單獨 MQ 產(chǎn)品供應(yīng) 商提供的實際接口,從而跨越了壁壘,以及解決了互通問題。從技術(shù)上講, Java 應(yīng)用程序只需 針對 JMS API 編程,選擇合適的 MQ 驅(qū)動即可, JMS 會打理好其他部分 。ActiveMQ 就是 JMS 的 一種實現(xiàn) 。不過嘗試使用單獨標準化接口來膠合眾多不同的接口,最終會暴露出問題,使得 應(yīng)用程序變得更加脆弱 。所以急需一種新的消息通信標準化方案 。
一統(tǒng)江湖
4.在 2006 年 6 月,由 Cisco 、 Redhat 、iMatix 等聯(lián)合制定了 AMQP 的公開標準,由此 AMQP 登上了歷史的舞臺 。它是應(yīng)用層協(xié)議的一個開放標準,以解決眾多消息中間件的需求和拓撲結(jié) 構(gòu)問題 。它為面向消息的中間件設(shè)計,基于此協(xié)議的客戶端與消息中間件可傳遞消息,并不受 產(chǎn)品、開發(fā)語言等條件的限制 。
合久必分
5.LinkedIn在實現(xiàn)消息隊列的時候覺得AMQP規(guī)范并不適合自己,所以Kafka并不支持AMQP協(xié)議。RocketMQ在實現(xiàn)上借鑒了Kakfa的思想,所以也不支持AMQP協(xié)議,并且你會發(fā)現(xiàn)在Kafka和RocketMQ中都有類似Topic和Consumer Group的概念,而這些概念在AMQP協(xié)議中是不存在的
如何選擇消息中間件
鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)
ActiveMQ 的社區(qū)算是比較成熟,但是較目前來說,ActiveMQ 的性能比較差,而且版本迭代很慢,不推薦使用。
RabbitMQ 在吞吐量方面雖然稍遜于 Kafka 和 RocketMQ ,但是由于它基于 erlang 開發(fā),所以并發(fā)能力很強,性能極其好,延時很低,達到微秒級。但是也因為 RabbitMQ 基于 erlang 開發(fā),所以國內(nèi)很少有公司有實力做erlang源碼級別的研究和定制。如果業(yè)務(wù)場景對并發(fā)量要求不是太高(十萬級、百萬級),那這四種消息隊列中,RabbitMQ 一定是你的首選。如果是大數(shù)據(jù)領(lǐng)域的實時計算、日志采集等場景,用 Kafka 是業(yè)內(nèi)標準的,絕對沒問題,社區(qū)活躍度很高,絕對不會黃,何況幾乎是全世界這個領(lǐng)域的事實性規(guī)范。
RocketMQ 阿里出品,Java 系開源項目,源代碼我們可以直接閱讀,然后可以定制自己公司的MQ,并且 RocketMQ 有阿里巴巴的實際業(yè)務(wù)場景的實戰(zhàn)考驗。RocketMQ 社區(qū)活躍度相對較為一般,不過也還可以,文檔相對來說簡單一些。
Kafka 的特點其實很明顯,就是僅僅提供較少的核心功能,但是提供超高的吞吐量,ms 級的延遲,極高的可用性以及可靠性,而且分布式可以任意擴展。同時 Kafka 最好是支撐較少的 topic 數(shù)量即可,保證其超高吞吐量。Kafka 唯一的一點劣勢是有可能消息重復(fù)消費,那么對數(shù)據(jù)準確性會造成極其輕微的影響,在大數(shù)據(jù)領(lǐng)域中以及日志采集中,這點輕微影響可以忽略。Kafka天然適合大數(shù)據(jù)實時計算以及日志收集。
消息模型
如果讓你設(shè)計一個消息隊列?你會怎么實現(xiàn)呢?
可能你立馬就會想到用隊列,一邊放,一邊取。這其實就是消息隊列常見的一種消息模型,隊列模型
所以一個簡單的消息隊列用Redis中的List就能實現(xiàn)。當(dāng)然Redis5.0版本之后針對消息隊列這種場景專門設(shè)計了一個數(shù)據(jù)結(jié)構(gòu)Streams。
隊列模型有哪些缺點呢?
如果將一類消息發(fā)送給不同的消費者,每個消費者都要接收全量的消息,此時就很不方便。因為你要將相同的消息發(fā)送到不同的隊列,多一個消費者就得多發(fā)一份隊列。這樣生產(chǎn)者必須知道有多少個消費者,不利于解耦。
那么該如何解決這個問題呢?
想想RabbitMQ的結(jié)構(gòu)圖
RabbitMQ并不是直接把消息發(fā)送到隊列中的,而是發(fā)送到Exchange中,Exchange和Queue進行關(guān)聯(lián),消息由Exchange根據(jù)規(guī)則發(fā)送到對應(yīng)的隊列。這樣生產(chǎn)者和消費者完成了解耦。
還有哪種方式能解決這種多消費者的問題呢?
答對了,就是發(fā)布訂閱模型
RocketMQ和Kafka都是基于發(fā)布訂閱模型實現(xiàn)的,RocketMQ的消息模型圖如下
生產(chǎn)者是發(fā)布者,消費者是訂閱者,消息是主題
為了提高消費的并行度,一類消息會被分發(fā)到多個隊列中,在RocketMQ中叫Queue,在Kafka中叫做Partition(分區(qū)),都是類似的概念。
AMQP協(xié)議詳解
前面說到消息中間件有2種協(xié)議,JMS和AMQP。JMS你可以類比為JDBC,搞了一套接口讓不同廠商來實現(xiàn)這個接口,但是這個協(xié)議設(shè)計的確實不夠優(yōu)雅,因此就不介紹這個協(xié)議了,除非你用ActiveMQ,不然學(xué)了真沒啥用。詳細說一下AMQP協(xié)議,畢竟現(xiàn)在用RabbitMQ的公司還是很多的,要想學(xué)好RabbitMQ,AMQP協(xié)議是必須要清楚的。
AMQP協(xié)議模型
上圖是AMQP協(xié)議中一個消息的流轉(zhuǎn)過程,畫的的很清楚,不詳細介紹了。
AMQP核心概念介紹一些AMQP協(xié)議常見的概念。
概念解釋
概念 | 解釋 |
---|---|
Server | 又稱Broker,接受客戶端的連接,實現(xiàn)AMQP實體服務(wù) |
Connection | 一個網(wǎng)絡(luò)連接,比如TCP/IP套接字連接 |
Channel | 多路復(fù)用連接中的一條獨立的雙向數(shù)據(jù)流通道。為會話提供物理傳輸介質(zhì) |
Message | 消息,服務(wù)器和應(yīng)用程序之間傳送的數(shù)據(jù),由Properties和Body組成。Properties可以對消息進行修飾,比如消息的優(yōu)先級,延遲等高級特性,Body則就是消息體內(nèi)容 |
Virtual Host | 虛擬地址,用于進行邏輯隔離,最上層的消息路由。一個Virtual Host里面可以有若干個Exchange和Queue,同一個Virtual Host里面不能有相同名稱的Exchange或Queue |
Binding | 消息隊列和交換器之間的關(guān)聯(lián) |
Routing Key | 一個消息頭,交換器可以用這個消息頭決定如何路由某條消息 |
Message Queue | 消息隊列,用來保存消息直到發(fā)送給消費者 |
以上是“RabbitMQ中消息中間件是什么意思”這篇文章的所有內(nèi)容,感謝各位的閱讀!希望分享的內(nèi)容對大家有幫助,更多相關(guān)知識,歡迎關(guān)注億速云行業(yè)資訊頻道!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。