RabbitMQ交換機使用場景和消息可靠性總結(jié)分析

更新時間：2023年01月12日 14:50:05 作者：失敗的面

這篇文章主要為大家介紹了RabbitMQ交換機使用場景和消息可靠性總結(jié)分析，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪

RabbitMQ的一些基本組件

Producer：消息的生產(chǎn)者
Consumer：消息的消費者
Broker：MQ服務(wù)器，管理隊列、消息
Message：消息，程序間通訊的數(shù)據(jù)
Queue：隊列，消息存放的容器，消息先進先出
Exchange：交換機，用于分發(fā)消息

各種類型交換機的使用場景

扇形交換機（Fanout）

發(fā)布/訂閱模式，類似于廣播，交換機將收到的消息發(fā)給多個隊列，消費者如果訂閱了這個隊列的話，就可以收到生產(chǎn)者的消息。生產(chǎn)者不直接與隊列綁定，而且將數(shù)據(jù)發(fā)送至交換機Exchange。

扇形交換機不需要路由鍵，設(shè)置了也沒有作用。

使用場景

如天氣預(yù)報信息，生產(chǎn)者將天氣預(yù)報信息發(fā)送到交換機，網(wǎng)易、新浪等門戶通過各自隊列綁定到該交換機，來獲取推送的消息。

扇形交換機發(fā)布一次可以讓所有消費者收到，但有時候我們需要進行一些數(shù)據(jù)集篩選，比如我只想接收關(guān)于廣東省的天氣預(yù)報，其他省份的忽略，那么我們就需要用到路由或者主題交換機模式。

直連交換機（Direct）

路由模式，通過路由鍵進行匹配，Exchange交換機會根據(jù)路由鍵（RoutingKey）有條件的將數(shù)據(jù)篩選后發(fā)送給隊列

使用場景

日志收集系統(tǒng)，收集了info、warn、error三種類型日志，要發(fā)送給對應(yīng)的隊列做處理，如info隊列做記錄，warn和error隊列在info隊列基礎(chǔ)上還要發(fā)送郵件給運維人員，那么可以創(chuàng)建一個直連交換機（Direct），然后綁定三個路由鍵：INFO、WARN、ERROR到三個隊列。

路由模式是一種精準匹配，只有設(shè)置了RoutingKey才可以分發(fā)消息，在實際應(yīng)用中可能會有一些模糊匹配的情況，這時候我們可以用主題交換機來實現(xiàn)。

主題交換機（Topic）

在路由模式上增加了通配符，可以進行路由鍵的模糊匹配，更加靈活的進行消息分發(fā)

通配符：*和#，*代表單個關(guān)鍵字，#代表多個關(guān)鍵字

在實際使用場景中，路由模式的效率高于主題模式，所以可以使用路由模式的時候優(yōu)先使用路由模式。

關(guān)于延時隊列

在Rabbit MQ中實現(xiàn)延時隊列有兩種方式：

使用官方提供的延時插件

具體操作可以看我的這篇文章：docker-compose安裝RabbitMQ及插件

注意：這個插件的使用還是有一定的限制性，官方說：

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.

這個插件目前的設(shè)計并不適合有大量延遲消息的場景(例如10萬或數(shù)百萬)。詳見第72條。

所以在大消息場景下可以改用Kafka來實現(xiàn)。

通過死信隊列來實現(xiàn)

如訂單超時功能，創(chuàng)建兩個交換機隊列，一個訂單超時消息，一個訂單消息，訂單超時消息不設(shè)置消費者，僅設(shè)置過期時間，這樣在到期后會轉(zhuǎn)發(fā)給一個交換機Exchange（我們設(shè)置為訂單消息交換機），訂單隊列收到這個轉(zhuǎn)發(fā)就會發(fā)送消息，由此曲線救國的來做到延時消息。

但是死信隊列有個大問題：當往隊列放入一條過期時間是10秒的A消息，再放入一條過期時間是５秒的B消息，等待５秒后B消息并不會優(yōu)先進入死信隊列被消費，而是遵循隊列先進先出規(guī)則，在10秒后A消息過期，A和B一起進入死信隊列被消費。

不過這個問題也好解決，就是固定這個死信隊列的延時時間就好了，比如訂單15分鐘后超時，就全部訂單都是15分鐘后超時，不要有A訂單10分鐘超時，B訂單5分鐘超時的情況，