Springboot使用RabbitMQ看這幾篇就夠了(模式詳解篇)！

各位看官可以關注博主個人博客，瞭解更多信息。
作者:Surpasser
鏈接地址：https://surpass.org.cn

前言

前面說到在Windows主機上安裝RabbitMQ,和三種大類模式，那麼這裏就比較詳細的解釋模式中的情況。這裏只涉及概念，不展示測試Demo。

RabbitMQ模式

點對點的隊列

圖例

模式描述

一個生產者P對應一個隊列Q，一個隊列Q由一個消費者C監聽。

消費者確認模式有自動確認消息和手動確認消息兩種模式。

• true:表示自動確認，只要消息從隊列中獲取，無論消費者獲取到消息後是否成功消費，都會認爲消息已經成功消費。

• false:表示手動確認，消費者獲取消息後，服務器會將該消息標記爲不可用狀態，等待消費者的反饋，如果消費者一直沒有反饋，那麼該消息將一直處於不可用狀態，並且服務器會認爲該消費者已經掛掉，不會再給其發送消息，直到該消費者反饋。

work模式

圖例

模式描述

一個生產者P對應一個隊列Q，一個隊列被多個消費者監聽消費。一條消息只能被一個消費這消費。

這裏有兩種方式：

• 輪詢方式：隊列通過循環的方式將消息對消費者進行分發，總體來說，各個消費者消費的消息是均等的。比如說，當有 C₁ 和 C₂ 兩個消費者，C₁ 只會消費奇數消息，C₂ 只會消費偶數消息。平均每個消費者獲得相同數量的消息。
• 公平分發：出現一種現象就是當奇數消息被消費者 C₁ 消費時間過長，且偶數消息被消費者 C₂ 消費時間過短時，那麼 C₁ 就會顯得很煩忙，而 C₂ 就會顯得很悠閒，很顯然這很影響工作效率。那麼這種方式就用來解決這個問題，當任何一個消費者消費完周都會應答，而後隊列直接分發該消費者信息進行消費。那麼在相同時間內 C₁ 消費的消息肯定沒有 C₂ 多。也叫做"能者多勞"。

注：使用basicQos( prefetchCount = 1)方法，來限制RabbitMQ只發不超過1條的消息給同一個消費者。當消息處理完畢後，有了反饋，纔會進行第二次發送。
還有一點需要注意，使用公平分發，必須關閉自動應答，改爲手動應答。

發佈/訂閱者模式（Publish/Subscribe）

圖例

模式描述

1. 1個生產者，多個消費者
2. 每一個消費者都有自己的一個隊列
3. 生產者沒有將消息直接發送到隊列，而是發送到了交換機
4. 每個隊列都要綁定到交換機(不指定Routing Key)
5. 生產者發送的消息，通過交換機發送到綁定交換機隊列，實現一個消息被多個消費者獲取的目的。

注：交換機沒有儲存數據的能力，如果該交換機沒有綁定任何隊列時，這條消息就會被拋棄。

路由模式

圖例

模式描述

根據上述訂閱模式類似，跟交換機綁定的隊列指定了Routing Key，消息進入交換機後會根據Routing Key，判斷將該條消息分發到哪些隊列中。

如圖舉例，當Routing Key爲error時，交換機會將消息分發到兩條隊列中，當Routing Key爲info時，交換機只會將消息分發給下方的隊列。

主題模式(Topic)

圖例

模式描述

符號 # 匹配一個或多個詞，符號 * 匹配不多不少一個詞。

任何發送到Topic Exchange的消息都會被轉發到所有關心Routing Key中指定話題的Queue上。

usa.# 能夠匹配到 usa.news.XXX，但是 usa.* 只會匹配到 usa.XXX 。

如果Exchange沒有發現能夠與RouteKey匹配的Queue，則會拋棄此消息 。