概述

之前已經對rabbitMQ的一些基本概念做了介紹和不同MQ之間的比較，今天主要對rabbitMQ的一些方面做擴展。

---

01

消息隊列

Broker：簡單來說就是消息隊列服務器實體。

Exchange：消息交換機，它指定消息按什么規則，路由到哪個隊列。

Queue：消息隊列載體，每個消息都會被投入到一個或多個隊列。

Binding：綁定，它的作用就是把exchange和queue按照路由規則綁定起來。

Routing Key：路由關鍵字，exchange根據這個關鍵字進行消息投遞。

vhost：虛擬主機，一個broker里可以開設多個vhost，用作不同用戶的權限分離。每個虛擬主機是隔離的,互不影響.

producer：消息生產者，就是投遞消息的程序。

consumer：消息消費者，就是接受消息的程序。

channel：消息通道，在客戶端的每個連接里，可建立多個channel，每個channel代表一個會話任務。

---

02

消息隊列的工作過程

(1)客戶端連接到消息隊列服務器，打開一個channel。

(2)客戶端聲明一個exchange，并設置相關屬性。

(3)客戶端聲明一個queue，并設置相關屬性。

(4)客戶端使用routing key，在exchange和queue之間建立好綁定關系。

(5)客戶端投遞消息到exchange。

---

03

消費模式 :推(push)模式和拉(pull)模式。

Pull(推模式)是指由Broker(中介,這里是隊列),主動推送消息至消費端，實時性較好，不過需要一定的流制機制來確保服務端推送過來的消息不會壓垮消費端。

而拉模式是指消費端主動向Broker端請求拉取(一般是定時或者定量)消息，實時性較推模式差，但是可以根據自身的處理能力而控制拉取的消息量。

---

04

消息持久化

rabbit如何進行消息持久化操作呢？exchange是實現發布訂閱的基礎，其類型包含fanout、headers、direct、、topic。我們本次僅討論類型為topic。

發布訂閱模式執行消息發送的流程：

RabbitMQ要實現發布訂閱持久化，按照消息的傳輸流程，可以分成三類：

Exchange 持久化：如果不設定Exchange持久化，那么在RabbitMQ由于某些異常等原因重啟之后，Exchange會丟失。Exchange丟失， 會影響發送端發送消息到RabbitMQ。

Queue持久化：發送端將消息發送至Exchange，Exchange將消息轉發至關聯的Queue。如果Queue不設置持久化，那么在RabbitMQ重啟之后，Queue信息會丟失。導致消息發送至Exchange，但Exchange不知道需要將該消息發送至哪些具體的隊列。

Message持久化：發送端將消息發送至Exchange，Exchange將消息轉發至關聯的Queue，消息存儲于具體的Queue中。如果RabbitMQ重啟之后，由于Message未設置持久化，那么消息會在重啟之后丟失。

為了保證發布訂閱的持久化，必須設置Exchange、Queue、Message的持久化，才可以保證消息最終不會丟失。雖然持久化會造成性能損耗，但為了生產環境的數據一致性，這是我們必須做出的選擇。但我們可以通過設置消息過期時間、降低發送消息大小等其他方式來盡可能的降低MQ性能的降低。

消息隊列持久化包括3個部分：

(1)exchange持久化，在聲明時指定durable => 1

(2)queue持久化，在聲明時指定durable => 1

(3)消息持久化，在投遞時指定delivery_mode => 2(1是非持久化)

如果exchange和queue都是持久化的，那么它們之間的binding也是持久化的。如果exchange和queue兩者之間有一個持久化，一個非持久化，就不允許建立綁定。

---

05

消息發送步驟

exchange接收到消息后，就根據消息的key和已經設置的binding，進行消息路由，將消息投遞到一個或多個隊列里。

exchange也有幾個類型，完全根據key進行投遞的叫做Direct交換機，例如，綁定時設置了routing key為”abc”，那么客戶端提交的消息，只有設置了key為”abc”的才會投遞到隊列。對key進行模式匹配后進行投遞的叫做Topic交換 機，符號”#”匹配一個或多個詞，符號”*”匹配正好一個詞。

例如”abc.#”匹配”abc.def.ghi”，”abc.*”只匹配”abc.def”。還有一種不需要key的，叫做Fanout交換機，它采取廣播模式，一個消息進來時，投遞到與該交換機綁定的所有隊列。

---

RabbitMQ的Connection是昂貴的，但Channel是廉價的，在多線程環境下，盡量創建少數Connection，然后在每個Connection中創建多個Channel，利用Channel實現Connection復用，從而提高系統性能。很像Java NIO里的Selector到Channel的多路復用。

生產端發送消息時，同一個Channel的basicPublish方法并不是線程安全的，因此更加體現出多Channel的重要性。如果生產端需要使用多線程發送消息，那么必須創建多個Channel，每一個線程單獨使用一個Channel，但是這些Channel可以來自同一個Connection。假如線程數量過多，那么也不可以無限制的創建Channel，需要使用Channel Pool(連接池)的思路去控制并發。

后面會分享更多devops和DBA方面的內容，感興趣的朋友可以關注一下~

總結

以上是生活随笔為你收集整理的rabbitmq 不同的消费者消费同一个队列_消息队列王者--rabbitMQ深入理解--工作过程、消费模式、持久化等...的全部內容，希望文章能夠幫你解決所遇到的問題。

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