訊息佇列之-RabbitMQ

歡迎關注 公眾號 dying 擱淺 有音頻版本

1. 什么是 MQ

1.1 概念

MQ 全拼 Message Queue 即 訊息佇列，是在訊息的傳輸程序中保存訊息的容器，多用于分布式系統，

1.2 MQ 帶來的優勢

MQ 所帶來的優勢即我們用 MQ 的理由，如下：

1. 應用解耦：復雜系統增加訊息佇列中間層解耦兩端邏輯，提高系統容錯性和可維護性
2. 異步處理：訊息異步處理，加快服務回應速度，提升用戶體驗和系統吞吐量
3. 削峰填谷，流量控制：系統從訊息佇列中拉取消費請求，由訊息佇列緩沖量并發請求，請求量大可削峰，請求量小可填谷，提高系統穩定性

實際案例場景：

秒殺、聊天、等

1.3 MQ 帶來的問題

所謂 天下沒有免費的午餐，有利就有弊，引入 MQ 同樣也會給我們帶來不少問題：

1. 增加了系統復雜度和維護成本，
2. 引入訊息佇列所帶來的延遲問題，
3. 可能存在的資料不一致問題，

利弊權衡間考慮你的系統是否需要引入訊息佇列，

2. RabbitMQ 簡介

公司/社區: Rabbit
開發語言：Erlang （為高并發和分布式誕生的語言，電信領域使用廣泛）
協議支持：AMQP、XMPP、SMTP、STOMP
客戶端支持語言：官方支持 Erlang、Java、Ruby 等，社區提供幾乎支持所有主流語言，
單機吞吐量： 萬級
訊息延遲： 微秒
功能特性：并發能力強，性能極好，低延遲，社區活躍，完善的管理界面，

下圖是一個簡單的模型，以及一些相關概念

2.1 什么是 AMQP

AMQP 全稱 Advanced Message Queuing Protocol 即 高級訊息佇列協議，是一個應用層網路協議，專門面向訊息佇列的中間件進行設計的協議，基于此協議的客戶端與訊息中間件可以傳遞訊息，不受不同 客戶端/中間件/開發語言等條件限制，是一個通信規范，

2.2 基礎架構模型

名詞解釋：

Broker： 中間件，接收和分發訊息的應用，如 RabbitMQ Server 就是 Message Broker （訊息中間件）

Virtual host：虛擬主機，出于多租戶和安全的考慮，把 AMQP 的基本組件劃分到一個虛擬的分組中，類似于網路中 namespace 命名空間的概念，當多個用戶使用同一個 RabbitMQ server 所提供的服務時，可以劃分出多個 virtual host ，每個用戶在自己的 virtual host 進行 exchange 以及 queue 等，互不干擾，

Connection 鏈接，publisher 發布者 、consumer 訂閱者 與 broker 之間的 TCP 鏈接，

Channel：通道，管道， channel 是在 connection 內部建立的邏輯鏈接，為了避免程式多執行緒而創建多個 connection 做的優化， 如果應用程式支持多執行緒，通常每個 thread 會創建單獨的 channel 進行通訊， AMQP Method 包含了 channelId 幫助客戶端和 message broker 識別 channel ，每個 channel 相互隔離，這個概念有點類似 進行和執行緒的對應關系，正好一個行程對應一個 connection ，一個執行緒對應一個 channel 這樣的感覺，

Exchange：交換機，message 到達 broker 會先進過 交換機 ，根據分發規則，查表匹配 routing key ，將訊息分發到對應的 queue，常用的型別： direct （point-to-point），topic（publish-subscribe）、fanout （multicast）后文會詳細說明，

Queue：佇列，訊息最終存盤位置，等待 consumer 消費，

Binding: exchange 與 queue 之間的虛擬鏈接，binding 中可以包含 routing key，binding 資訊被保存到 exchange 的查詢表中，用于訊息的分發，

RabbitMQ 6 種作業模式

https://www.rabbitmq.com/getstarted.html

1. Hello World 模式

這個模式簡單理解就是 一對一的消費模式，一個生產者對應一個消費者，訊息僅消費一次，

2. Work queues 作業佇列模式

作業佇列模式，與上面的簡單模式區別是 可以多個生產者，然后由多個消費者一起消費訊息，訊息僅消費一次，對應的可以提高訊息的處理速度，

3. Publish/Subscribe 發布訂閱模式

到這里，發布訂閱模式，路由模式，主題模式 其實結構上大同小異，區別僅僅是 交換機 Exchange 的系結路由規則不同罷了，
同時在該模式下，一份訊息會分發給符合條件的多個佇列使用，且比上面的模式多了交換機的概念，
交換機 顧名思義 作用就是將生產者生產的訊息，根據一定的規則分發到對應的佇列中，

發布訂閱模式的 Exchange 交換機是 Fanout 廣播模式，即：將訊息交給所有系結到交換機的佇列

4. Routing 路由模式

路由模式的 Exchange 交換機是 Direct 定向模式，即：把訊息交給 routing key 路由對應的佇列

5. Topics 主題模式

主題模式的 Exchange 交換機是 Topic 通配符模式，即：把訊息交給 routing pattern 路由匹配的佇列

6. RPC 遠程呼叫模式

RPC 不是訊息佇列的重點，這里不做過多解釋，RPC 有更多成熟的框架實作，個人不建議使用訊息佇列來實作，

訊息的可靠性

訊息生產端的可靠投遞

在使用 RabbitMQ 的時候，作為訊息發送方希望杜絕任何訊息丟失或者投遞失敗場景，RabbitMQ 為我們提供了兩種方式用來控制訊息的投遞可靠性模式，

confirm 確認模式
return 退回模式

rabbitmq 整個訊息投遞的路徑為：

producer—>rabbitmq broker—>exchange—>queue—>consumer

訊息從 producer 到 exchange 投遞失敗會回傳一個 confirmCallback ，
訊息從 exchange–>queue 投遞失敗會回傳一個 returnCallback ，

我們將利用這兩個 callback 控制訊息的可靠性投遞

注意這兩個模式需要進行配置開啟，如：

publisher-confirms=“true” 確認模式開啟
publisher-returns=“true” 回退模式開啟

消費端的確認消費 ACK

RabbitMQ 在消費端提供了 3 種確認機制

無需確認 acknowledge = "none" 該模式下無需手動撰寫代碼 ack ，RabbitMQ 默認 consumer 正確處理所有請求，

手動確認 acknowledge="manual" 該模式下需要手動撰寫代碼進行訊息確認 如正常收到訊息 channel.basicAck() 訊息例外 channel.basicNack() 等，

自動確認 acknowledge="auto" consumer 自動應答，處理成功（即沒有發生例外）發出 ack，處理失敗發出 nack，queue 發出訊息后會等待 consumer 端應答，只有收到 ack 確定資訊后才會將訊息在 queue 中清除掉，收到 nack 例外資訊的處理方法由setDefaultRequeueReject() 方法設定，這種模式下，發送錯誤的訊息可以恢復，

Java 代碼撰寫

關于 Java 代碼撰寫使用上，一般有 三種 方式

純 Java 代碼方式

Spring 配置方式

Spring Boot 自動配置方式