前言
上一篇對RabbitMQ的流程和相關(guān)的理論進行初步的概述，如果小伙伴之前對消息隊列不是很了解，那么在看理論時會有些困惑，這里以消息模式為切入點，結(jié)合理論細節(jié)和代碼實踐的方式一起來學習。
正文
常用的模式有Simple、Work、Fanout、Direct、Topic、Headers，可以通過設(shè)置交換機類型和配置參數(shù)來實現(xiàn)各個模式；接下來就分別進行實操演示吧。
以下演示都是通過管理員的賬號進行。其實每種模式其實很大一部分操作都是一樣的，所以公共部分不會重復截圖說明，不過會針對不同的配置進行說明。
1. 簡單模式(Simple)
簡單模式顧名思義就是簡單，不用配置太多的東西，如下圖所示：
上圖解析：
P：表示生產(chǎn)者，負責推送消息；
C：表示消費者，負責接收消息；
中間紅色部分：代表的是隊列(Queue)；
小伙伴可能會奇怪，這里沒有交換機嗎？
其實是有的，上一篇說流程的時候，消息肯定是要通過交換機轉(zhuǎn)發(fā)到隊列中的，這里沒有指定，那是因為用到了默認的交換機，具體看以下演示。
1.1 Web管理界面進行演示
對于Web界面演示來說，只需要將消息能生產(chǎn)、投遞、消費即可，我們不用去弄一個生產(chǎn)者和消費者，生產(chǎn)者和消費者都是業(yè)務處理邏輯用的，所以通常都是根據(jù)業(yè)務需求就行實現(xiàn)的；話不多說開始演示吧。
根據(jù)上圖所示，我們只需要創(chuàng)建一個隊列即可，然后就可以進行消息模擬發(fā)送和消費了。
此時并沒有指定交換機綁定，點擊隊列名看詳情中的Bindings，有一個默認的交換機已經(jīng)和隊列進行綁定：
隊列詳情頁面的說明，在上篇文章中就已經(jīng)標注了，這里就不再贅述。
有了綁定關(guān)系之后，就可以在默認的交換機頁面開始模擬轉(zhuǎn)發(fā)消息；首先進入Exchanges管理頁面，點擊默認交換機(AMQP default）進入詳情開始發(fā)布消息：
消息發(fā)送成功之后就會在隊列界面看到消息情況：
隊列里面有了消息之后，就可以模擬消費者進行消息消費，點擊隊列名進入詳情，可在詳情也模擬消費：
如上所示，簡單模式整個消費流程就通過Web頁面模擬完了。但在消費消息時，提供了Ack Mode模式(消息確認模式)選擇來進行消費，可選擇的模式如下：
Nack message requeue true：獲取消息，但是不會向Server做ack應答確認(即不告訴服務器消息被消費了)，消息重新入隊。即隊列中的消息不會被刪除掉；
Automatic Ack：獲取消息，向Server做應答確認(即會告訴服務器消息被消費了)，消息不重新入隊，將會從隊列中刪除；
Reject requeue true：拒絕獲取消息(即拒絕處理消息)，消息重新入隊；
Reject requeue false：拒絕獲取消息(即拒絕處理消息)，消息不重新入隊，將會被刪除；
到這關(guān)于簡單模式下的界面演示就結(jié)束了，其中描述的細節(jié)內(nèi)容是共用的，在其他模式下的操作也類似，后續(xù)不做重復說明。
1.2 代碼進行演示
這里就用控制臺的方式，一步一步的實現(xiàn)。這里需要引入Nuget包：RabbitMQ.Client。生產(chǎn)者的整體代碼如下：
接下來就一步一步來調(diào)試，看看消息是怎么一步一步發(fā)出去的；
創(chuàng)建連接
剛開始沒有任何連接，如下：
代碼繼續(xù)下一步，連接就有了：
此時就可以理解為網(wǎng)絡(luò)連接上了，但通道還沒有創(chuàng)建出來，如下：
根據(jù)連接創(chuàng)建通道
通道根據(jù)連接進行創(chuàng)建，目的是為了提高傳輸效率，共用一個連接，不然頻繁的創(chuàng)建和銷毀連接會占資源，影響性能。
定義隊列
有連接和通道之后理論就可以直接發(fā)消息了，但直接通信會相互依賴比較強，達不到解耦合的效果。所以需要定義一個隊列將消息存放到里面，客戶端想用了自己來消費就行，另外隊列還可以達到一定的削峰作用。
創(chuàng)建隊列的時候需要傳幾個參數(shù)，分別意思如下：
參數(shù)1：queue， 隊列的名稱；
參數(shù)2：durable， 隊列是否持久化；如果為true，服務器重啟之后隊列還在，不會被清除；否則就被清掉。
參數(shù)3：exclusive ，是否排他，即是否私有的，如果為true,會對當前隊列加鎖，其他的通道不能訪問，并且連接自動關(guān)閉；
參數(shù)4：autodelete， 是否自動刪除，當最后一個消費者斷開連接之后是否自動刪除消息；
參數(shù)5：arguments， 用來設(shè)置隊列附加參數(shù)，如設(shè)置隊列的有效期、隊列的消息生命周期、消息的最大長度等；
發(fā)送消息
經(jīng)過以上步驟，就可以發(fā)送消息了，如上沒有定義交換機，那就是綁定了默認交換機。
發(fā)送時的幾個參數(shù)意思如下：
參數(shù)1：exchange,交換機，這里沒有指定交換機。
參數(shù)2：routingKey，路由key，即指定隊列，簡單模式下，路由key默認就是隊列名
參數(shù)3：basicProperties， 配置其他相關(guān)屬性
參數(shù)4：body ，需要發(fā)送的消息內(nèi)容
以上的生產(chǎn)者完成了，現(xiàn)在再來一個消費者演示一下消息消費，消費者整體代碼如下：
效果如下：
在整個過程中，還是會先建立連接，創(chuàng)建通道，指定隊列；不同的是增加對接收數(shù)據(jù)的處理。
是不是用起來比較簡單方便，主要是在復雜項目中，消息隊列的作用真的很大。來，接著往下說說其他模式。
2. 工作模式(Work)
工作模式是考慮到多個消費者情況下，消息如何被消費的，主要有兩種方案，輪詢分發(fā)和公平分發(fā)；
上圖解析：
這兩種方式需要多個消費者，在界面不太好模擬，所以就直接上代碼演示了。
2.1 輪詢分發(fā)
在簡單模式基礎(chǔ)上稍微改動一下代碼即可。在生產(chǎn)者中發(fā)多條消息出來，然后啟用多個消費者就可以進行模擬如下：
生產(chǎn)者代碼整體如下：
消費者代碼整體如下：
兩個消費者的代碼都是一樣，沒有變動；兩個消費者的都是在消費同一個隊列的消息，可以先啟動兩個消費者，然后在啟動生產(chǎn)者，效果如下：
由上可見，默認情況下其實采用的是輪詢方式。
2.2 公平分發(fā)
在實際業(yè)務中，有些業(yè)務處理比較耗時，有些處理耗時不長，如上案例，假如奇數(shù)消息需要處理比較耗時，那么對應的消費者就壓力比較大。這種情況可以通過公平分發(fā)的方式進行業(yè)務處理，處理快點的就多處理點。
如何才能知道消費者處理業(yè)務完成呢？消費者處理完成之后主動上報是最好不過的，所以只需要在消費者端將自動確認機制改為手動確認即可，即：業(yè)務處理完成之后，手動上報確認狀態(tài)。
生產(chǎn)者的代碼不需要變動，只需要稍微改改消費者代碼即可，這里模擬兩個不同處理能力的消費者：
消費者1處理一條消息業(yè)務需要500毫秒；
消費者2處理一條消息業(yè)務需要2秒；
消費者1整體代碼如下：
消費者2整體代碼如下，主要是模擬時間不一樣：
先啟動兩個消費者，再啟動生產(chǎn)者，看看消費情況，如下：
以上演示就是公平分發(fā)模式的演示，其中有兩個關(guān)鍵的步驟：
設(shè)置每次消費的消息條數(shù)，可以根據(jù)實際業(yè)務情況配置，這里設(shè)置的是每次取一條。通過 channel.BasicQos進行設(shè)置。
將消息確認模式改為自動模式，這樣就可以根據(jù)實際業(yè)務處理情況反饋確認信息，服務器就會將消息處理掉，即刪除消息。所以一般在實際業(yè)務場景大都會推薦使用手動確認的方式，這樣避免業(yè)務未處理導致消息就被服務器給清掉的情況。
3. 發(fā)布訂閱模式(Fanout)
Fanout模式是一種發(fā)布訂閱模式，是一種廣播機制，不需要指定路由Key。這種模式的交換機就會將消息廣播到綁定的所有隊列上去，只要有消費者訂閱對應的隊列，就會收到消息。如下圖：
上圖解析：
在這種模式下，消息會一次性被多個消費者消費。
3.1 Web管理界面進行演示
先創(chuàng)建一個Fanout模式的交換機；
創(chuàng)建兩個隊列(根據(jù)實際需要創(chuàng)建多個)，并將隊列綁定到上一步創(chuàng)建的交換機上；
這里演示就創(chuàng)建兩個隊列，分別是FanoutQ1和FanoutQ2
在隊列詳情頁或交換機詳情頁都可以進行交換機和隊列的綁定，這里分別在FanoutQ1和FanoutQ2隊列詳情頁進行綁定，如下：
同樣的方式綁定FanoutQ2, 綁定完成之后，可以在交換機詳情頁看到對應的綁定隊列：
通過交換機上投遞消息，看效果；
此時通過FanoutExchange交換機投遞消息，綁定到此交換機上的隊列都能收到：
查看隊列消息情況，可以看到兩個隊列都接收到消息了。
3.2 代碼進行演示
其實代碼和操作Web一樣，只是用代碼實現(xiàn)生產(chǎn)者和消費者而已。
生產(chǎn)者的代碼
因為Fanout交換機不用關(guān)注RoutingKey，所以在發(fā)布消息時，第二個參數(shù)不需要傳遞RoutingKey。
消費者1的代碼
消費者比較關(guān)注的是交換機需要和生產(chǎn)者指定的是同一個，隊列和交換機有綁定。
消費者2的代碼，其實和消費者1基本一樣，只是定義的隊列不一樣
先啟動消費者，然后啟動生產(chǎn)者，看效果
這里是控制臺程序，為了顯示方便就先啟動消費者，后期的生產(chǎn)者，實際應用場景先啟動誰都行。
4. 路由模式(Direct)
Direct模式是在Fanout基礎(chǔ)增加RoutingKey條件， 即交換機不會將消息現(xiàn)全部投遞到所有隊列，而是只投遞到對應RoutingKey下的隊列。如圖：
上圖解析：
P：表示生產(chǎn)者，負責推送消息；
X：表示交換機，指定類型為direct，圖中表示一個交換機綁定了多個隊列；
中間箭頭上的error、info、warning代表具體的RoutingKey；
C1、C2：表示多個消費者，都可以從同一個隊列接收消息；
中間紅色部分：代表的是隊列(Queue)；
Direct模式其實在實際應用場景中用的比較多的，默認的Exhanges也是Direct模式， 很多關(guān)于消息隊列的框架，默認也是采用這種模式，主要原因是根據(jù)RoutingKey精確的處理對應的業(yè)務，不會由于考慮不周到，導致消息處理有不確定性，性能相對也不錯。
4.1 Web管理界面進行演示
先創(chuàng)建一個Direct模式的交換機；
創(chuàng)建兩個隊列，然后將隊列綁定到上一步創(chuàng)建的交換機上，并指定對應的RoutingKey；
創(chuàng)建隊列完成之后，還需要綁定到交換機上，上一種模式演示的是從隊列詳情中維護綁定關(guān)系，這次從交換機詳情中進行演示，如下：
綁定第1個隊列，指定RoutingKey是order，模擬處理訂單的：
綁定第2個隊列，指定RoutingKey是msg，模擬處理消息的：
有了綁定關(guān)系，就可以測試驗證了。
注：這里的RoutingKey可以根據(jù)實際情況隨意指定的。
向交換機上投遞消息，看效果；
模擬發(fā)布一個RoutingKey為order的消息：
再發(fā)布一個消息，指定RoutingKey為msg，如下：
兩個消息都發(fā)布成功，而是指定對應的RoutingKey進行投遞，所以現(xiàn)在綁定到此交換機上兩個隊列中分別有一條數(shù)據(jù)，查看隊列的消息概況：
可以進入隊列詳情，通過GetMessage獲取到具體的消息內(nèi)容，這里就不截圖了，上面已經(jīng)演示過。
4.2 代碼進行演示
在Fanout的代碼基礎(chǔ)上稍微改動即可，主要改動點就是改變交換機的類型，并在隊列和交換機綁定時設(shè)置對應的RoutingKey，發(fā)布消息的時候指定交換機和RoutingKey。
生產(chǎn)者代碼
消費者1代碼，主要是綁定隊列時指定的RoutingKey為order
消費者2代碼，主要是綁定隊列時指定的RoutingKey為msg
運行起來看效果:
如上演示效果，和Web演示一樣，只有精確匹配到RoutingKey才能消費到對應的消息數(shù)據(jù)。
5. 主題模式(Topic)
Topic模式是在Direct模式基礎(chǔ)增加模糊匹配RoutingKey，Direct精確匹配RoutingKey，Topic可以通*或#進行模糊匹配，從而把消息投遞到對應的隊列中，如圖：
上圖解析：
P：表示生產(chǎn)者，負責推送消息；
X：表示交換機，指定類型為topic，圖中表示一個交換機綁定了多個隊列；
中間箭頭上的文字代表模糊匹配的RoutingKey；其中*表示匹配RoutingKey中的一個詞，#號表示匹配RoutingKey的零個或多個詞，匹配符需要與點號（.）搭配使用。*.orange.test.# 示例中orange算一個詞，test算一個詞，即通過點號（.）分開的就稱為一個詞。
C1、C2：表示多個消費者，都可以從同一個隊列接收消息；
中間紅色部分：代表的是隊列(Queue)；
5.1 Web管理界面進行演示
先創(chuàng)建一個Topic模式的交換機；
創(chuàng)建兩個隊列，然后將隊列綁定到上一步創(chuàng)建的交換機上，并指定對應的RoutingKey；
將隊列綁定到交換機上，這里還是在交換機詳情中進行演示，如下：
同樣的步驟分別對TopicQ1和TopicQ2進行規(guī)則綁定，如下：
現(xiàn)在的TopicExchange的綁定關(guān)系如下：
有了關(guān)系之后就可以進行驗證效果了。
向交換機上投遞消息，會根據(jù)RoutingKey的模糊匹配規(guī)則將消息投遞到對應的隊列中，看效果；
先指定order.create.test發(fā)布消息，看看會匹配哪些隊列：
TopicQ2接收到消息，匹配到路由規(guī)則order.#
再指定RoutingKey 為order.update 發(fā)布一個消息，如下：
TopicQ1和TopicQ2都收到消息了，匹配到路由規(guī)則order.#和order.*，如下：
再指定RoutingKey 為order發(fā)布一個消息，就會匹配到order.#，這里就不截圖了。
以上測試說明：在Topic類型交換機和隊列綁定關(guān)系時，可以指定RoutingKey的匹配規(guī)則，星號、#號、點號搭配使用，其中*表示匹配RoutingKey中的一個詞，#號表示匹配RoutingKey的零個或多個詞。
更多情況，小伙伴們自己動手試試。
5.2 代碼進行演示
在Direct的代碼基礎(chǔ)上稍微改動即可，主要改動點就是改變交換機的類型，并在隊列和交換機綁定時設(shè)置對應的RoutingKey，這里的RoutingKey是一個規(guī)則，是星號、#號、點號和每個詞的組合，發(fā)布消息的時候指定交換機和RoutingKey，RoutingKey會去匹配綁定的規(guī)則。
生產(chǎn)者代碼
消費者1代碼，指定路由匹配規(guī)則為order.#
消費者2代碼，指定路由匹配規(guī)則為order.*
演示效果，將生產(chǎn)者和消費者都啟動
如上圖，和Web演示一樣，#號匹配0個和多個詞，*號只能匹配一個詞。 符號可以與詞任意組合，小伙伴可以根據(jù)業(yè)務情況自行發(fā)揮。
6. 參數(shù)模式（Headers）
Headers模式不是通過RoutingKey進行匹配投遞消息，而是匹配請求頭中所帶的鍵值進行消息投遞，所以創(chuàng)建隊列是需要設(shè)置綁定的頭部信息，有兩種模式：全部匹配和部分匹配。
5.1 Web管理界面進行演示
先創(chuàng)建一個Headers模式的交換機；
創(chuàng)建兩個隊列，然后將隊列綁定到上一步創(chuàng)建的交換機上，可以指定Headers的參數(shù)；
將隊列綁定到交換機上，這里還是在交換機詳情中進行演示，如下：
這里不使用RoutingKey的方式，而是通過設(shè)置參數(shù)的形式進行綁定，后續(xù)投遞消息的時候就匹配參數(shù)，如果能匹配上，就將消息投遞到對應的隊列。
綁定HeaderQ1隊列：
同樣的方式綁定HeaderQ2隊列，只是只添加了一個鍵值對，order:111，最后HeaderExchange交換機的綁定關(guān)系如下：
關(guān)系綁定好之后就可以進行測試效果了。
向交換機上投遞消息，會根據(jù)檢查Headers參數(shù)的條件是否符合，若符合將消息投遞到對應的隊列中，看效果；
設(shè)置兩個參數(shù)進行發(fā)布，如下：
可以看到兩個隊列都匹配到了，因為order和msg鍵值對匹配到HeaderQ1,order的鍵值對匹配到HeaderQ2，如果只設(shè)置一個order簡直對呢：
此時只有HeaderQ2才能精確匹配，HeaderQ1沒有全部匹配，所以對應隊列沒有收到消息，如下：
由此可見，在界面上沒有指定x-match綁定的話，默認是all，就是要全部匹配才投遞消息到對應隊列。
這里繼續(xù)新增一個HeaderQ3的隊列，創(chuàng)建方式和上面不一樣，只是在綁定交換機的時候增加x-match 為 any，如下：
綁定成功之后，現(xiàn)在關(guān)系如下，其中order的鍵值對是在每個綁定中都有，如下：
測試發(fā)消息之前，把之前消息都清空了，也就是隊列中的消息都是空的，這次我們再指定order為111的參數(shù)進行發(fā)布消息，看看有哪些隊列收到消息呢：
消息發(fā)出后，之后HeaderQ2和HeaderQ3收到消息，HeaderQ2只有一個order參數(shù)，精確匹配上了，HeaderQ3有多個參數(shù)，但設(shè)置了x-match為any，所以只要匹配其中一個即可。HeaderQ1多個參數(shù)需要全部匹配才行，所以沒有接收到消息：
5.2 代碼進行演示
Headers模式是根據(jù)參數(shù)進行匹配，不是通過RoutingKey，所以只需要在綁定隊列時設(shè)置好參數(shù)，在發(fā)送消息的時候也設(shè)置好參數(shù)，這樣就會根據(jù)匹配原則去匹配參數(shù)，如果匹配上，消息就投遞到對應的隊列，供消費者進行消費。這里為了演示比較清晰一點，使用一個生產(chǎn)者，三個消費者的形式進行演示。
生產(chǎn)者
代碼中關(guān)鍵的部分是指定交換機的類型為Headers，然后模擬了兩類參數(shù)的形式投遞消息，方便用于測試參數(shù)匹配模式的測試。
消費者1，綁定參數(shù)為order:111和msg：222
消費者2，和消費者1代表基本一樣，只是綁定參數(shù)不一樣；
消費者3，代表基本和消費者1一樣，只是在參數(shù)指定的時候增加了x-match來指定匹配模式，這里指定為any，也就是只要其中有部分匹配上也可以消費到消息。
演示效果，啟動生產(chǎn)者和消費者：
如上圖，消費者3指定了匹配模式為部分匹配，所以可以接收到一個參數(shù)的消息，而消費者1需要精確匹配，所以不能接收到。
關(guān)于常用的消息模式就聊到這吧，小伙伴們可以根據(jù)自己的業(yè)務場景進行使用，相關(guān)演示代碼的地址如下：
碼云：https://gitee.com/CodeZoe/dot-net-core-study-demo/tree/main/RabbitMQDemo
總結(jié)
RabbitMQ提供了多種模式應對各種業(yè)務，但匹配條件越是模糊或者參數(shù)化，那性能相對比較弱。再回顧一些常用的消息隊列組件，是不是很多都是默認使用Direct模式，精確匹配的RoutingKey可以針對具體不同業(yè)務處理，匹配性能也相對比較高；當然其他模式小伙伴也可以針對業(yè)務情況進行使用。
后續(xù)的文章將繼續(xù)分享RabbitMQ消息確認機制、死信隊列、磁盤監(jiān)控等相關(guān)知識點的應用，關(guān)注“Code綜藝圈”，和我一起學習吧。
----------------------------------
原文：https://mp.weixin.qq.com/s/LP_aAf_fODUPOtiikVwvTw
該文章在 2023/5/20 8:18:33 編輯過
400 186 1886
