Messges Queue消息隊列詳解
1、什么是消息隊列
消息隊列一般簡稱為 MQ (Messges Queue),是指利用高效可靠的消息傳遞機(jī)制進(jìn)行與平臺無關(guān)的數(shù)據(jù)交流,并基于數(shù)據(jù)通信來進(jìn)行分布式系統(tǒng)的集成,是在消息的傳輸過程中保存消息的容器。
消息隊列本質(zhì)上是一個隊列,而隊列中存放的是一個個消息。
隊列是一個數(shù)據(jù)結(jié)構(gòu),具有先進(jìn)先出的特點。
而消息隊列就是將消息放到隊列里,用隊列做存儲消息的介質(zhì)。
消息的發(fā)送放稱為生產(chǎn)者,消息的接收方稱為消費(fèi)者。
消息隊列由 Broker(消息服務(wù)器,核心部分)、Producer(消息生產(chǎn)者)、Consumer(消息消費(fèi)者)、Topic(主題)、Queue(隊列)和Message(消息體)組成。
2、消息隊列特點
- 流量削峰:主要用于在高并發(fā)情況下,業(yè)務(wù)異步處理,提供高峰期業(yè)務(wù)處理能力,避免系統(tǒng)癱瘓。
假設(shè)系統(tǒng)只能處理1000個請求,但這時突然來了3000個請求,如果不加以限制就會造成系統(tǒng)癱瘓。使用消息隊列做緩沖,將多余的請求存放在消息隊列中,等系統(tǒng)根據(jù)自己處理請求的能力去消息隊列去。
- 應(yīng)用解耦:主要用于當(dāng)一個業(yè)務(wù)需要多個模塊共同實現(xiàn),或者一條消息有多個系統(tǒng)需要對應(yīng)處理時,只需要主業(yè)務(wù)完成以后,發(fā)送一條MQ,其余模塊消費(fèi)MQ消息,即可實現(xiàn)業(yè)務(wù),降低模塊之間的耦合。
假設(shè)某個服務(wù) A 需要調(diào)用服務(wù) B,但是服務(wù) B 突然出現(xiàn)問題,這樣會導(dǎo)致服務(wù) A 也會出現(xiàn)問題。如果使用消息隊列,當(dāng)服務(wù) A 執(zhí)行完成之后,發(fā)送一條消息到隊列中,服務(wù) B 讀取到這條消息,那么它立刻開始進(jìn)行業(yè)務(wù)的執(zhí)行。
- 異步通信:主業(yè)務(wù)執(zhí)行結(jié)束后從屬業(yè)務(wù)通過MQ,異步執(zhí)行,減低業(yè)務(wù)的響應(yīng)時間,提高用戶體驗。
假設(shè)有一個業(yè)務(wù),要先執(zhí)行服務(wù) A ,然后服務(wù) A 去調(diào)用服務(wù) B ,當(dāng)服務(wù) B 完成之后,服務(wù) A 調(diào)用服務(wù) C,這個業(yè)務(wù)需要一步步走下去。當(dāng)使用了消息隊列之后,服務(wù) A 完成之后,可以同時執(zhí)行服務(wù) B 和 服務(wù) C ,這樣就減低業(yè)務(wù)的響應(yīng)時間,提高用戶體驗。
3、消息隊列的的傳輸模式
- 點對點模式:用于消息生產(chǎn)者和消息消費(fèi)者之間點到點的通信。

消息生產(chǎn)者將消息發(fā)送到Queue(隊列)中,然后消息消費(fèi)者從Queue(隊列)找取出消息,當(dāng)消息被消費(fèi)之后就從Queue(隊列)中刪除,消息只能被一個消息消費(fèi)者使用。
- 發(fā)布/訂閱模式:消息生產(chǎn)者向一個特定的Topic(主題)生產(chǎn)消息。0或多個訂閱了該Topic(主題)的消息消費(fèi)者,接收Topic(主題)的消息, 在這種情況下發(fā)布者和訂閱者彼此不知道。

消息生產(chǎn)者和消息消費(fèi)者只有建立了訂閱關(guān)系才能收到消息。
Topic(主題)實現(xiàn)了發(fā)布和訂閱,當(dāng)消息生產(chǎn)者發(fā)布一個消息,所有訂閱這個Topic(主題)的服務(wù)都能得到這個消息。
有兩種訂閱類型:
- 持久訂閱:訂閱關(guān)系建立后,消息就不會消失,不管訂閱者是否都在線;
- 非持久訂閱:訂閱者為了接受消息,必須一直在線。 當(dāng)只有一個訂閱者時約等于點對點模式
4、常用的消息隊列
- ActiveMQ:是Apache下的一個子項目。
- 優(yōu)點:單機(jī)吞吐量每秒萬級,時效性毫秒級,可用性高,基于主從架構(gòu)實現(xiàn)高可用性,消息可靠性較低的概率丟失數(shù)據(jù)。支持多種語言、支持Spring2.0的特性、支持多種傳送協(xié)議、支持通過JDBC和journal提供高速的消息持久化。
- 缺點:官方社區(qū)現(xiàn)在的維護(hù)越來越少;社區(qū)活躍度不高。
- Kafka:是一個分布式消息發(fā)布訂閱系統(tǒng)。為大數(shù)據(jù)而生的消息中間件,大數(shù)據(jù)的殺手锏
- 優(yōu)點:單機(jī)吞吐量每秒百萬級,時效性毫秒級,不會丟失數(shù)據(jù),不會導(dǎo)致不可用
- 缺點:支持消息順序,但是一臺代理宕機(jī)后,就會產(chǎn)生消息亂序;消費(fèi)失敗不支持重試;社區(qū)更新較慢
- RocketMQ:阿里系下開源的一款分布式、隊列模型的消息中間件,3.0版本名稱改為RocketMQ,是阿里參照 kafka 設(shè)計思想使用 java 實現(xiàn)的一套消息隊列。
- 優(yōu)點:單機(jī)吞吐量十萬級,時效性毫秒級,消息可以做到 0 丟失,支持 10 億級別的消息堆積
- 缺點:支持的客戶端語言不多,目前是 java 及 c++;社區(qū)活躍度一般;
- RabbitMQ:是使用Erlang編寫的一個開源的消息隊列
- 優(yōu)點:單機(jī)吞吐量萬級,時效性微秒級,支持多種語言
到此這篇關(guān)于Messges Queue消息隊列詳解的文章就介紹到這了,更多相關(guān)消息隊列詳解內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Java HttpServletResponse響應(yīng)實現(xiàn)過程詳解
這篇文章主要介紹了Java HttpServletResponse響應(yīng)實現(xiàn)過程詳解,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友可以參考下2020-05-05
Java網(wǎng)絡(luò)編程UDP實現(xiàn)多線程在線聊天
這篇文章主要為大家詳細(xì)介紹了Java網(wǎng)絡(luò)編程UDP實現(xiàn)多線程在線聊天,文中示例代碼介紹的非常詳細(xì),具有一定的參考價值,感興趣的小伙伴們可以參考一下2021-07-07
springboot schedule 解決定時任務(wù)不執(zhí)行的問題
這篇文章主要介紹了springboot schedule 解決定時任務(wù)不執(zhí)行的問題,本文給大家介紹的非常詳細(xì),具有一定的參考借鑒價值,需要的朋友可以參考下2019-09-09
IDEA創(chuàng)建SpringBoot項目整合mybatis時mysql-connector-java報錯異常的詳細(xì)分析
最近工作中發(fā)現(xiàn)了個錯誤,分享給同樣遇到這個問題的朋友,這篇文章主要給大家介紹了關(guān)于IDEA創(chuàng)建SpringBoot項目整合mybatis時mysql-connector-j報錯異常的詳細(xì)分析,需要的朋友可以參考下2023-02-02
MyBatis?實現(xiàn)多對多中間表插入數(shù)據(jù)
這篇文章主要介紹了MyBatis?實現(xiàn)多對多中間表插入數(shù)據(jù),具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2022-02-02
基于SpringBoot + Redis實現(xiàn)網(wǎng)站七天免密登錄系統(tǒng)
本文介紹了如何使用SpringBoot和Redis實現(xiàn)七天免密登錄功能,通過合理利用Redis的過期機(jī)制,設(shè)計了Token策略、Redis存儲結(jié)構(gòu)和安全驗證機(jī)制,本文詳細(xì)描述了登錄控制器、攔截器實現(xiàn)和用戶上下文管理,展示了如何在實際業(yè)務(wù)中應(yīng)用此功能,需要的朋友可以參考下2026-04-04

