RabbitMQ交換機(jī)使用場景和消息可靠性總結(jié)分析
RabbitMQ的一些基本組件
- Producer:消息的生產(chǎn)者
- Consumer:消息的消費(fèi)者
- Broker:MQ服務(wù)器,管理隊(duì)列、消息
- Message:消息,程序間通訊的數(shù)據(jù)
- Queue:隊(duì)列,消息存放的容器,消息先進(jìn)先出
- Exchange:交換機(jī),用于分發(fā)消息
各種類型交換機(jī)的使用場景
扇形交換機(jī)(Fanout)
發(fā)布/訂閱模式,類似于廣播,交換機(jī)將收到的消息發(fā)給多個(gè)隊(duì)列,消費(fèi)者如果訂閱了這個(gè)隊(duì)列的話,就可以收到生產(chǎn)者的消息。生產(chǎn)者不直接與隊(duì)列綁定,而且將數(shù)據(jù)發(fā)送至交換機(jī)Exchange。
扇形交換機(jī)不需要路由鍵,設(shè)置了也沒有作用。
使用場景
如天氣預(yù)報(bào)信息,生產(chǎn)者將天氣預(yù)報(bào)信息發(fā)送到交換機(jī),網(wǎng)易、新浪等門戶通過各自隊(duì)列綁定到該交換機(jī),來獲取推送的消息。
扇形交換機(jī)發(fā)布一次可以讓所有消費(fèi)者收到,但有時(shí)候我們需要進(jìn)行一些數(shù)據(jù)集篩選,比如我只想接收關(guān)于廣東省的天氣預(yù)報(bào),其他省份的忽略,那么我們就需要用到路由或者主題交換機(jī)模式。
直連交換機(jī)(Direct)
路由模式,通過路由鍵進(jìn)行匹配,Exchange交換機(jī)會(huì)根據(jù)路由鍵(RoutingKey)有條件的將數(shù)據(jù)篩選后發(fā)送給隊(duì)列
使用場景
日志收集系統(tǒng),收集了info、warn、error三種類型日志,要發(fā)送給對(duì)應(yīng)的隊(duì)列做處理,如info隊(duì)列做記錄,warn和error隊(duì)列在info隊(duì)列基礎(chǔ)上還要發(fā)送郵件給運(yùn)維人員,那么可以創(chuàng)建一個(gè)直連交換機(jī)(Direct),然后綁定三個(gè)路由鍵:INFO、WARN、ERROR到三個(gè)隊(duì)列。
路由模式是一種精準(zhǔn)匹配,只有設(shè)置了RoutingKey才可以分發(fā)消息,在實(shí)際應(yīng)用中可能會(huì)有一些模糊匹配的情況,這時(shí)候我們可以用主題交換機(jī)來實(shí)現(xiàn)。
主題交換機(jī)(Topic)
在路由模式上增加了通配符,可以進(jìn)行路由鍵的模糊匹配,更加靈活的進(jìn)行消息分發(fā)
通配符:*和#,*代表單個(gè)關(guān)鍵字,#代表多個(gè)關(guān)鍵字
在實(shí)際使用場景中,路由模式的效率高于主題模式,所以可以使用路由模式的時(shí)候優(yōu)先使用路由模式。
關(guān)于延時(shí)隊(duì)列
在Rabbit MQ中實(shí)現(xiàn)延時(shí)隊(duì)列有兩種方式:
使用官方提供的延時(shí)插件
具體操作可以看我的這篇文章:docker-compose安裝RabbitMQ及插件
注意:這個(gè)插件的使用還是有一定的限制性,官方說:
Current design of this plugin doesn't really fit scenarios with a high number of delayed messages (e.g. 100s of thousands or millions). See #72 for details.
這個(gè)插件目前的設(shè)計(jì)并不適合有大量延遲消息的場景(例如10萬或數(shù)百萬)。詳見第72條。
所以在大消息場景下可以改用Kafka來實(shí)現(xiàn)。
通過死信隊(duì)列來實(shí)現(xiàn)
如訂單超時(shí)功能,創(chuàng)建兩個(gè)交換機(jī)隊(duì)列,一個(gè)訂單超時(shí)消息,一個(gè)訂單消息,訂單超時(shí)消息不設(shè)置消費(fèi)者,僅設(shè)置過期時(shí)間,這樣在到期后會(huì)轉(zhuǎn)發(fā)給一個(gè)交換機(jī)Exchange(我們設(shè)置為訂單消息交換機(jī)),訂單隊(duì)列收到這個(gè)轉(zhuǎn)發(fā)就會(huì)發(fā)送消息,由此曲線救國的來做到延時(shí)消息。
但是死信隊(duì)列有個(gè)大問題:當(dāng)往隊(duì)列放入一條過期時(shí)間是10秒的A消息,再放入一條過期時(shí)間是5秒的B消息,等待5秒后B消息并不會(huì)優(yōu)先進(jìn)入死信隊(duì)列被消費(fèi),而是遵循隊(duì)列先進(jìn)先出規(guī)則,在10秒后A消息過期,A和B一起進(jìn)入死信隊(duì)列被消費(fèi)。
不過這個(gè)問題也好解決,就是固定這個(gè)死信隊(duì)列的延時(shí)時(shí)間就好了,比如訂單15分鐘后超時(shí),就全部訂單都是15分鐘后超時(shí),不要有A訂單10分鐘超時(shí),B訂單5分鐘超時(shí)的情況,
消息監(jiān)聽
通過監(jiān)聽消息,我們可以實(shí)現(xiàn)消息的確認(rèn),是一種實(shí)現(xiàn)消息可靠性的方案。
如何保證消息不重復(fù)消費(fèi)
- 接口 做防重和冪等性保證
- 保存唯一索引到Redis中,設(shè)置一個(gè)短一點(diǎn)的過期時(shí)間,消費(fèi)消息前判斷緩存中是否有數(shù)據(jù),有就說明剛剛已經(jīng)處理過了,這是一條重復(fù)消費(fèi)
消息可靠性如何保證
- 生產(chǎn)者提供消息給消費(fèi)者時(shí)使用消息確認(rèn)機(jī)制
- 消息服務(wù)器的隊(duì)列、交換機(jī)都進(jìn)行持久化,保證數(shù)據(jù)不丟失
在消息可靠性上,沒有方法可以保證完全絕對(duì)的可靠,所以必要的日志收集一定要做好,實(shí)時(shí)監(jiān)控,在運(yùn)維上也要下一些功夫。
參考資料
以上就是RabbitMQ交換機(jī)使用場景和消息可靠性總結(jié)分析的詳細(xì)內(nèi)容,更多關(guān)于RabbitMQ交換機(jī)消息可靠性的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
基于Java8 Stream API實(shí)現(xiàn)數(shù)據(jù)抽取收集
這篇文章主要介紹了基于Java8 Stream API實(shí)現(xiàn)數(shù)據(jù)抽取收集,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2020-03-03Java 普通代碼塊靜態(tài)代碼塊執(zhí)行順序(實(shí)例講解)
下面小編就為大家?guī)硪黄狫ava 普通代碼塊靜態(tài)代碼塊執(zhí)行順序(實(shí)例講解)。小編覺得挺不錯(cuò)的,現(xiàn)在就分享給大家,也給大家做個(gè)參考。一起跟隨小編過來看看吧2017-08-08詳細(xì)學(xué)習(xí)Java Cookie技術(shù)(用戶登錄、瀏覽、訪問權(quán)限)
這篇文章主要為大家詳細(xì)介紹了Java Cookie技術(shù),顯示用戶上次登錄的時(shí)間、顯示用戶最近瀏覽的若干個(gè)圖片(按比例縮放)等,感興趣的小伙伴們可以參考一下2016-08-08Java設(shè)計(jì)模塊系列之書店管理系統(tǒng)單機(jī)版(三)
這篇文章主要為大家詳細(xì)介紹了Java單機(jī)版的書店管理系統(tǒng)設(shè)計(jì)模塊和思想第三章,感興趣的小伙伴們可以參考一下2016-08-08使用MyBatis攔截器實(shí)現(xiàn)sql查詢權(quán)限動(dòng)態(tài)修改代碼實(shí)例
這篇文章主要介紹了使用MyBatis攔截器實(shí)現(xiàn)sql查詢權(quán)限動(dòng)態(tài)修改代碼實(shí)例,為了不耦合,現(xiàn)在的方案是在需要鑒權(quán)的Mybatis?Mapper方法上增加一個(gè)注解,在運(yùn)行過程中判斷該注解存在即對(duì)sql進(jìn)行修改,需要的朋友可以參考下2023-08-08詳細(xì)理解JAVA面向?qū)ο蟮姆庋b,繼承,多態(tài),抽象
這篇文章主要介紹了Java基礎(chǔ)之面向?qū)ο髾C(jī)制(多態(tài)、繼承)底層實(shí)現(xiàn),文中有非常詳細(xì)的代碼示例,對(duì)正在學(xué)習(xí)java的小伙伴們有非常好的幫助,需要的朋友可以參考下2021-07-07