文章目錄

• 一 MQ 的作用與基本概念
• • 1 流量削峰
  • 2 應用解耦
  • 3 異步調用
  • 4 四個基本概念
• 二 核心模式
• • 1 工作隊列模式（Work Queue）
  • 2 發布/訂閱模式（Publish / Subscribe）
  • 3 路由模式（Routing）
  • 4 主題模式（Topic）
• 三 RabbitMQ 消息機制
• • 1 消息應答 & 重新入隊
  • 2 預取值
  • 3 持久化
  • 4 發布確認
• 四 交換機
• • 1 Fanout
  • 2 Direct
  • 3 Topic

一 MQ 的作用與基本概念

• 消息隊列的主要功能：流量削峰、應用解耦、異步處理

1 流量削峰

• 先將短時間高并發產生的事務消息存儲在消息隊列中，然后后端服務再慢慢根據自己的能力去消費這些消息，這樣就避免直接把后端服務壓垮
  

2 應用解耦

• 生產者（客戶端）發送消息到消息隊列中去，接受者（服務端）處理消息，需要消費的系統直接去消息隊列取消息進行消費即可而不需要和其他系統有耦合，這顯然也提高了系統的擴展性

3 異步調用

• 將用戶的請求數據存儲到消息隊列之后就立即返回結果，隨后系統再對消息進行消費
• 是流量削峰的基礎
• 使用消息隊列進行異步處理之后，需要適當修改業務流程進行配合。比如用戶在提交訂單之后，訂單數據寫入消息隊列，不能立即返回用戶訂單提交成功，需要在消息隊列的訂單消費者進程真正處理完該訂單之后，再通知用戶訂單成功，以免交易糾紛
  

4 四個基本概念

生產者：產生數據、發送消息的程序
交換機：接收來自生產者的消息，另一方面它將消息推送到隊列中。交換機必須確切知道如何處理它接收到的消息（推送到特定隊列 / 推送到多個隊列 / 丟棄等）
隊列：隊列是 RabbitMQ 內部使用的一種數據結構，本質上是一個大的消息緩沖區
消費者：大多時候是一個等待接收消息的程序

---

二 核心模式

1 工作隊列模式（Work Queue）

• 消費者間是競爭關系，每個消息只被消費一次
• 主要思想是避免立即執行資源密集型任務，把任務封裝為消息并將其發送到隊列
• 默認采用輪詢方式向消費者發送消息，也可以根據消費者的處理能力指定不公平分發

2 發布/訂閱模式（Publish / Subscribe）

• 生產者將消息放入交換機，交換機把消息發送到和該交換機綁定的所有消息隊列中
• 消費者之間是資源共享的
• 使用的交換機類型為 Fanout

3 路由模式（Routing）

• 使用的交換機類型為 Direct

4 主題模式（Topic）

• 使用的交換機類型為 Topic，在路由模式的 routingKey 的基礎上添加了通配符，實現了模糊匹配

---

三 RabbitMQ 消息機制

1 消息應答 & 重新入隊

• 分為自動和手動，自動應答指的是，消息發送后立即被認為已經傳送成功，容易發生消息丟失
• 手動應答的回答方式：ACK（處理成功） / NACK（處理失敗） / REJECT（拒絕處理）
• 手動應答的好處是可以批量應答（批量指應答 channel 上未應答的消息），并且減少網絡擁堵
• 如果消費者由于某些原因失去連接(其通道已關閉，連接已關閉或 TCP 連接丟失)，導致消息未發送 ACK 確認，RabbitMQ 將獲取到消息未完全處理，并對其重新排隊

2 預取值

• 對于每個消費者來說，都有一個存放未處理消息的緩沖區。“預取計數”值定義了通道上允許的未確認消息的最大數量，限制緩沖區的大小，以避免緩沖區里面無限制的未確認消息問題
• 通常增加預取計數值，將提高向消費者傳遞消息的速度
• 據此可以解釋，雖然自動應答傳輸消息速率是最佳的，但在這種情況下已傳遞但尚未處理的消息的數量也會增加

3 持久化

• 默認情況下 RabbitMQ 退出或由于某種原因崩潰時，忽視隊列和消息。確保消息不會丟失需要將隊列和消息都標記為持久化
• 持久化并不能完全保證不會丟失消息，還需要配合發布確認

4 發布確認

• 隊列持久化 + 消息持久化 + 發布確認 = 消息不丟失
• 生產者將信道設置成 confirm 模式，一旦信道進入 confirm 模式，所有在該信道上面發布的消息都將會被指派一個唯一的 ID（從 1 開始），一旦消息被投遞到所有匹配的隊列之后，RabbitMQ 就會發送一個確認給生產者（包含消息的唯一 ID），這就使得生產者知道消息已經正確到達目的隊列了（如果消息和隊列是可持久化的，那么確認消息會在將消息寫入磁盤之后發出）
• 三種發布確認方式的對比

類型工作方式特點

單個發布確認	一次發布一個消息，只有它被確認發布，后續的消息才能繼續發布	發布速度特別慢；同步（阻塞消息的發布）
批量發布確認	一次發布一批消息，一起確認	當發布出現問題時無法定位問題消息，必須將整個批處理保存在內存中，以記錄重要的信息而后重新發布消息；同步（阻塞消息的發布）
異步發布確認	生產者只需發送消息而不用等待確認，RabbitMQ 收到某個消息，調用 ackCallBack 向生產者確認已收到消息，未收到調用 nackCallBack	需要哈希表記錄消息序號和消息內容；可靠性和效率最高；異步（不阻塞消息的發布）

---

四 交換機

• 生產者只能將消息發送到交換機，交換機工作的內容非常簡單，一方面它接收來自生產者的消息，另一方面將它們推入隊列。交換機必須確切知道如何處理收到的消息
• 交換機類型：直接(direct)，主題(topic)，標題(headers) ，扇出(fanout)
• 通過綁定（binding），實現交換機和隊列關系的建立

1 Fanout

• 將接收到的所有消息廣播到它綁定的所有隊列中

2 Direct

• Direct 交換機只把消息發送到具有一致 routingKey 隊列中去，要求生產者在向 MQ 發送消息時指定 routingKey

• 如果發送的消息的 routingKey 不對應任何一個隊列，則丟棄該消息

• 一個 Direct 綁定的多個隊列可以指定相同的 routingKey（類似 Fanout）
  

• 一個隊列可以指定多個 routingKey
  

3 Topic

• 通俗來講，在 Direct 模式上，隊列指定的 routingKey 增加了通配符
• 隊列指定的 routingKey 必須是一個單詞列表，以點號分隔開
• *可以代替一個單詞，#可以替代零個或多個單詞
  

總結

以上是生活随笔為你收集整理的后端学习 - RabbitMQ的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。