這篇文章主要介紹RabbitMQ中消息中間件是什么意思，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

為呼和浩特等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及呼和浩特網(wǎng)站建設(shè)行業(yè)解決方案。主營(yíng)業(yè)務(wù)為網(wǎng)站制作、成都網(wǎng)站建設(shè)、呼和浩特網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠(chéng)的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！

什么是消息中間件?

消息中間件屬于分布式系統(tǒng)中的一個(gè)子系統(tǒng)，關(guān)注于數(shù)據(jù)的發(fā)送和接收，利用高效可靠的消息傳遞機(jī)制對(duì)分布式系統(tǒng)中的其余各個(gè)子系統(tǒng)經(jīng)進(jìn)行集成

消息中間件的使用場(chǎng)景

1.異步處理非核心流程異步化，提高系統(tǒng)響應(yīng)性能

原來用戶注冊(cè)一下可能得依次寫數(shù)據(jù)庫(kù)，發(fā)送郵件和短信后，才能提示用戶注冊(cè)成功

現(xiàn)在只要寫數(shù)據(jù)庫(kù)，寫消息隊(duì)列后就直接提示用戶注冊(cè)成功，發(fā)送郵件和短信是異步處理，提高了響應(yīng)速度

2.應(yīng)用解耦

系統(tǒng)不是強(qiáng)耦合，消息接受者可以隨意增加，而不需要修改消息發(fā)送者的代碼。消息發(fā)送者的成功不依賴消息接受者

rpc實(shí)現(xiàn)

消息隊(duì)列實(shí)現(xiàn)

如果庫(kù)存系統(tǒng)出了問題，用戶就不能正常下單，這是不合理的?？梢酝ㄟ^消息隊(duì)列來解耦。

當(dāng)有新的系統(tǒng)如廣告系統(tǒng)對(duì)用戶的訂單也感興趣的時(shí)候，只需要從消息隊(duì)列中拿消息即可，訂單系統(tǒng)完全不用改變

3.流量削峰

當(dāng)上下游系統(tǒng)處理能力存在差距的時(shí)候，可以用消息隊(duì)列進(jìn)行緩沖

在這里插入圖片描述

當(dāng)有秒殺業(yè)務(wù)時(shí)，一下有大量請(qǐng)求涌入時(shí)，很可能造成系統(tǒng)癱瘓，此時(shí)可以用消息隊(duì)列緩沖一下

4.日志處理

將消息隊(duì)列用在日志處理中，比如Kafka可以用來解決大量日志傳輸?shù)膯栴}

5.消息通訊

消息隊(duì)列一般都內(nèi)置了高效的通信機(jī)制，因此也可以用于單純的消息通訊，比如實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)消息隊(duì)列或者聊天室等

消息中間件編年史

初見曙光

1.消息中間件其實(shí)誕生的很早，在互聯(lián)網(wǎng)應(yīng)用還是一片荒蕪的年代，有個(gè)在美國(guó)的印度哥們Vivek  Ranadive就設(shè)想了一種通用軟件總線，采用發(fā)布訂閱的模式，像主板上的總線一樣供其他相應(yīng)程序接入。他創(chuàng)辦了一家公司Teknekron，實(shí)現(xiàn)了世界上第一個(gè)消息中間件The  Information Bus(TIB)

各自為戰(zhàn)

2.TIB受到了企業(yè)的歡迎，Teknekron的業(yè)務(wù)發(fā)展引起了當(dāng)時(shí)最牛氣的IT公司IBM的注意，于是他們也開始研發(fā)了自己消息隊(duì)列軟件，于是才有了后來的wesphere  mq，微軟也陸續(xù)加入了戰(zhàn)團(tuán)。由于商業(yè)壁壘，商業(yè)MQ供應(yīng)商想要解決應(yīng)用應(yīng)用互通的問題，而不是去創(chuàng)建標(biāo)準(zhǔn)來實(shí)現(xiàn)不同MQ產(chǎn)品間的互通，或者允許應(yīng)用程序更改MQ平臺(tái)

劫制天下

3.為了打破這個(gè)壁壘，同時(shí)為了能夠讓消息在各個(gè)消息隊(duì)列平臺(tái)間互融互通， JMS (Java Message Service) 應(yīng)運(yùn)而生 。JMS  試圖通過提供公共 Java API 的方式，隱藏單獨(dú) MQ 產(chǎn)品供應(yīng) 商提供的實(shí)際接口，從而跨越了壁壘，以及解決了互通問題。從技術(shù)上講， Java 應(yīng)用程序只需  針對(duì) JMS API 編程，選擇合適的 MQ 驅(qū)動(dòng)即可， JMS 會(huì)打理好其他部分 。ActiveMQ 就是 JMS 的 一種實(shí)現(xiàn)  。不過嘗試使用單獨(dú)標(biāo)準(zhǔn)化接口來膠合眾多不同的接口，最終會(huì)暴露出問題，使得 應(yīng)用程序變得更加脆弱 。所以急需一種新的消息通信標(biāo)準(zhǔn)化方案 。

一統(tǒng)江湖

4.在 2006 年 6 月，由 Cisco 、 Redhat 、iMatix 等聯(lián)合制定了 AMQP 的公開標(biāo)準(zhǔn)，由此 AMQP 登上了歷史的舞臺(tái)  。它是應(yīng)用層協(xié)議的一個(gè)開放標(biāo)準(zhǔn)，以解決眾多消息中間件的需求和拓?fù)浣Y(jié) 構(gòu)問題 。它為面向消息的中間件設(shè)計(jì)，基于此協(xié)議的客戶端與消息中間件可傳遞消息，并不受  產(chǎn)品、開發(fā)語言等條件的限制 。

合久必分

5.LinkedIn在實(shí)現(xiàn)消息隊(duì)列的時(shí)候覺得AMQP規(guī)范并不適合自己，所以Kafka并不支持AMQP協(xié)議。RocketMQ在實(shí)現(xiàn)上借鑒了Kakfa的思想，所以也不支持AMQP協(xié)議，并且你會(huì)發(fā)現(xiàn)在Kafka和RocketMQ中都有類似Topic和Consumer  Group的概念，而這些概念在AMQP協(xié)議中是不存在的

如何選擇消息中間件

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. ActiveMQ 的社區(qū)算是比較成熟，但是較目前來說，ActiveMQ 的性能比較差，而且版本迭代很慢，不推薦使用。

3. RabbitMQ 在吞吐量方面雖然稍遜于 Kafka 和 RocketMQ ，但是由于它基于 erlang  開發(fā)，所以并發(fā)能力很強(qiáng)，性能極其好，延時(shí)很低，達(dá)到微秒級(jí)。但是也因?yàn)?RabbitMQ 基于 erlang  開發(fā)，所以國(guó)內(nèi)很少有公司有實(shí)力做erlang源碼級(jí)別的研究和定制。如果業(yè)務(wù)場(chǎng)景對(duì)并發(fā)量要求不是太高(十萬級(jí)、百萬級(jí))，那這四種消息隊(duì)列中，RabbitMQ  一定是你的首選。如果是大數(shù)據(jù)領(lǐng)域的實(shí)時(shí)計(jì)算、日志采集等場(chǎng)景，用 Kafka  是業(yè)內(nèi)標(biāo)準(zhǔn)的，絕對(duì)沒問題，社區(qū)活躍度很高，絕對(duì)不會(huì)黃，何況幾乎是全世界這個(gè)領(lǐng)域的事實(shí)性規(guī)范。

4. RocketMQ 阿里出品，Java 系開源項(xiàng)目，源代碼我們可以直接閱讀，然后可以定制自己公司的MQ，并且 RocketMQ  有阿里巴巴的實(shí)際業(yè)務(wù)場(chǎng)景的實(shí)戰(zhàn)考驗(yàn)。RocketMQ 社區(qū)活躍度相對(duì)較為一般，不過也還可以，文檔相對(duì)來說簡(jiǎn)單一些。

5. Kafka 的特點(diǎn)其實(shí)很明顯，就是僅僅提供較少的核心功能，但是提供超高的吞吐量，ms 級(jí)的延遲，極高的可用性以及可靠性，而且分布式可以任意擴(kuò)展。同時(shí)  Kafka 最好是支撐較少的 topic 數(shù)量即可，保證其超高吞吐量。Kafka  唯一的一點(diǎn)劣勢(shì)是有可能消息重復(fù)消費(fèi)，那么對(duì)數(shù)據(jù)準(zhǔn)確性會(huì)造成極其輕微的影響，在大數(shù)據(jù)領(lǐng)域中以及日志采集中，這點(diǎn)輕微影響可以忽略。Kafka天然適合大數(shù)據(jù)實(shí)時(shí)計(jì)算以及日志收集。

消息模型

如果讓你設(shè)計(jì)一個(gè)消息隊(duì)列?你會(huì)怎么實(shí)現(xiàn)呢?

可能你立馬就會(huì)想到用隊(duì)列，一邊放，一邊取。這其實(shí)就是消息隊(duì)列常見的一種消息模型，隊(duì)列模型

所以一個(gè)簡(jiǎn)單的消息隊(duì)列用redis中的List就能實(shí)現(xiàn)。當(dāng)然Redis5.0版本之后針對(duì)消息隊(duì)列這種場(chǎng)景專門設(shè)計(jì)了一個(gè)數(shù)據(jù)結(jié)構(gòu)Streams。

隊(duì)列模型有哪些缺點(diǎn)呢?

如果將一類消息發(fā)送給不同的消費(fèi)者，每個(gè)消費(fèi)者都要接收全量的消息，此時(shí)就很不方便。因?yàn)槟阋獙⑾嗤南l(fā)送到不同的隊(duì)列，多一個(gè)消費(fèi)者就得多發(fā)一份隊(duì)列。這樣生產(chǎn)者必須知道有多少個(gè)消費(fèi)者，不利于解耦。

那么該如何解決這個(gè)問題呢?

想想RabbitMQ的結(jié)構(gòu)圖

RabbitMQ并不是直接把消息發(fā)送到隊(duì)列中的，而是發(fā)送到Exchange中，Exchange和Queue進(jìn)行關(guān)聯(lián)，消息由Exchange根據(jù)規(guī)則發(fā)送到對(duì)應(yīng)的隊(duì)列。這樣生產(chǎn)者和消費(fèi)者完成了解耦。

還有哪種方式能解決這種多消費(fèi)者的問題呢?

答對(duì)了，就是發(fā)布訂閱模型

RocketMQ和Kafka都是基于發(fā)布訂閱模型實(shí)現(xiàn)的，RocketMQ的消息模型圖如下

生產(chǎn)者是發(fā)布者，消費(fèi)者是訂閱者，消息是主題

為了提高消費(fèi)的并行度，一類消息會(huì)被分發(fā)到多個(gè)隊(duì)列中，在RocketMQ中叫Queue，在Kafka中叫做Partition(分區(qū))，都是類似的概念。

AMQP協(xié)議詳解

前面說到消息中間件有2種協(xié)議，JMS和AMQP。JMS你可以類比為JDBC，搞了一套接口讓不同廠商來實(shí)現(xiàn)這個(gè)接口，但是這個(gè)協(xié)議設(shè)計(jì)的確實(shí)不夠優(yōu)雅，因此就不介紹這個(gè)協(xié)議了，除非你用ActiveMQ，不然學(xué)了真沒啥用。詳細(xì)說一下AMQP協(xié)議，畢竟現(xiàn)在用RabbitMQ的公司還是很多的，要想學(xué)好RabbitMQ，AMQP協(xié)議是必須要清楚的。

AMQP協(xié)議模型

上圖是AMQP協(xié)議中一個(gè)消息的流轉(zhuǎn)過程，畫的的很清楚，不詳細(xì)介紹了。

AMQP核心概念介紹一些AMQP協(xié)議常見的概念。

概念解釋

以上是“RabbitMQ中消息中間件是什么意思”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對(duì)大家有幫助，更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！