你是一個程序員，假設(shè)你維護了兩個服務(wù) A 和 B。

A 服務(wù)負責(zé)轉(zhuǎn)發(fā)用戶請求到 B 服務(wù)，B 服務(wù)是個算法服務(wù)，GPU 資源有限，當(dāng)請求量大到 B 服務(wù)處理不過來的時候，希望能優(yōu)先處理會員用戶的請求。

那么問題就來了，如果普通用戶和會員用戶同時發(fā)起請求，怎樣才能做到會員優(yōu)先呢？

怎么做到會員優(yōu)先

好辦，沒有什么是加一層中間層不能解決的，如果有，那就再加一層。

這次我們要加的中間層是 消息隊列 RabbitMQ。

RabbitMQ是什么

我們先來看下 RabbitMQ 里的核心概念，Queue。

Queue 是什么

我們知道，消息隊列本質(zhì)上就是一個類似鏈表的獨立進程。鏈表里的每個節(jié)點是一個消息。

隊列是類似鏈表的獨立進程

它介于生產(chǎn)者和消費者之間，在流量高峰時先暫存數(shù)據(jù)，再慢慢消費數(shù)據(jù)，可以很好的保護消費者，也就是所謂的削峰填谷。

削峰填谷

這個類似鏈表的進程，就是Queue，也叫隊列。

但消息也分很多種類，比如訂單消息和用戶消息屬于兩類，為了更好地管理不同種類的數(shù)據(jù)， 可以提供多個 隊列，生產(chǎn)者可以自定義 Queue 的名字，并且根據(jù)需要將消息投遞到不同的 Queue 中。每個 Queue 都設(shè)計為獨立的進程，某個進程掛了，不影響其他進程正常工作。

A進程掛了不影響其他進程

Exchange 是什么

有些生產(chǎn)者想將消息發(fā)到一個 Queue 中，有些則是發(fā)給多個queue，甚至廣播給所有 Queue ，于是 我們還需要一個可以定制消息路由分發(fā)策略的組件，交換器Exchange，將它與 Queue 綁定在一起，通過一個類似正則表達式的字符串 bindingKey 聲明綁定的關(guān)系，讓用戶根據(jù)需要選擇要投遞的隊列。

Exchange是什么

這些維護在 Exchange 里的路由方式和綁定關(guān)系，我們稱為元數(shù)據(jù)。

元數(shù)據(jù)是什么

RabbitMQ 是什么

像這樣一個包含多個 Queue 進程 和 Exchange 組件 的消息隊列，就是所謂的 RabbitMQ。

每一臺服務(wù)器上的 RabbitMQ 實例，就代表一個 Broker。

RabbitMQ是什么

大佬們在這個架構(gòu)的基礎(chǔ)上，為 RabbitMQ 實現(xiàn)了各種豐富的特性，你能想到的 MQ 功能它基本都實現(xiàn)了，比如延時隊列，死信隊列，優(yōu)先級隊列等等。

RabbitMQ的功能

前兩者跟 RocketMQ 的一樣，在之前的視頻里有提到過。這里重點看下優(yōu)先級隊列是什么。

優(yōu)先級隊列是什么

RabbitMQ 支持在生產(chǎn)者發(fā)送消息的時候，為消息標(biāo)記上優(yōu)先級，消費者總是消費優(yōu)先級高的消息。

優(yōu)先級隊列是什么

視頻開頭的問題，就可以通過優(yōu)先級隊列來完成。我們可以在 A 服務(wù)，根據(jù)用戶會員等級，為消息打上對應(yīng)的優(yōu)先級，再投遞到 RabbitMQ 中，B 服務(wù)永遠優(yōu)先消費高優(yōu)消息，當(dāng)高優(yōu)消息處理完后再處理普通消息。

優(yōu)先級隊列的應(yīng)用1

這個功能非常有用，現(xiàn)在到處都是 AI，恨不得將一塊 GPU 掰成 10 塊用，比如某聊天 AI，當(dāng)服務(wù)遭到大量訪問時，免費用戶會感覺很慢甚至報錯，但會員用戶依舊響應(yīng)絲滑。

優(yōu)先級隊列的應(yīng)用

到這里，大家估計也發(fā)現(xiàn)了，雖然 RabbitMQ 功能很豐富，但它的架構(gòu)就是個單實例節(jié)點，有些過于簡單了，像什么高可用和高擴展，那是一個都不沾。

我們來看下 RabbitMQ 是怎么擴展這部分能力的。

RabbitMQ 集群

既然單節(jié)點存在諸多問題，那就讓多個節(jié)點構(gòu)成集群。

我們可以在多個服務(wù)器上各部署一個 RabbitMQ 實例，并通過執(zhí)行 RabbitMQ 提供的命令，將這些實例組成一個集群。

RabbitMQ集群

RabbitMQ 支持多種集群模式。我們依次來看下。

多種集群模式

普通集群模式

在普通集群模式中，每個 Broker 都是一個完整功能的 RabbitMQ 實例，都能進行讀寫。

他們之間會互相同步 Exchange 里的元數(shù)據(jù)，但不會同步 Queue 數(shù)據(jù)。

假設(shè) Queue1、Queue2、Queue3 分別部署在 Broker1、Broker2、Broker3中。

• ? 對于寫操作：生產(chǎn)者將消息寫入到 Broker1 的 Queue1 后，Queue1 里的數(shù)據(jù)并不會同步給其他 broker。但如果此時 Broker1 的 Exchange 元數(shù)據(jù)有變化，則會將元數(shù)據(jù)同步到其他兩個 Broker 中。
  

寫操作

• 對于讀操作：消費者想要讀取 Queue1 數(shù)據(jù)時，如果訪問的是 Broker1，則直接返回 Queue1 中的數(shù)據(jù)。
  

消費消息1但如果訪問的是 Broker2，Broker2 則會根據(jù) Exchange 里的元數(shù)據(jù)，從 Broker1 那讀取數(shù)據(jù)，再返回給消費者。

消費消息2

這樣就可以通過增加 Broker，提升 RabbitMQ 集群整體的吞吐量，保證了擴展性。

但問題也很明顯。

• 雖然支持讀寫 Queue 的數(shù)量是增加了，但對于單個Queue 本身的讀寫能力，并沒有提升。
• 而且更重要的是，每個 Broker 依然有單點問題，Broker 之間并不同步 Queue 里的數(shù)據(jù)。某個 Queue 所在的 Broker 要是掛了，就沒法讀寫這個 Queue 了。

單點問題

這跟高可用毫不沾邊。

有更好的方案嗎？

鏡像隊列集群

參考下你那個，手機里有很多沸羊羊的相親對象，沒人比 ta 更懂什么是高可用。

我們可以在普通集群模式的基礎(chǔ)上, 給 queue 在其他 broker 中加幾個副本, 它們有主從關(guān)系，主 queue 負責(zé)讀寫數(shù)據(jù)，從 queue 負責(zé)同步復(fù)制主 queue 數(shù)據(jù), 所以從 Queue 也叫鏡像隊列。

一旦主 Queue 所在的 broker 掛了，從 Queue 就可以頂上成為新的主 Queue，實現(xiàn)高可用。這就是所謂的鏡像隊列集群。

鏡像隊列集群

• 對于寫操作：數(shù)據(jù)寫入主 Queue 后，會將 Exchange 和 Queue 數(shù)據(jù)同步給其他 Broker 上。

寫操作

• 對于讀操作：消費者讀取數(shù)據(jù)時，如果訪問的是主 Queue所在的broker，則直接返回數(shù)據(jù)。

消費消息1

• 否則，當(dāng)前 broker 會從主 queue 所在的 broker 上讀取數(shù)據(jù)，之后返回給消費者。

消費消息2

但這個方案的缺點也很明顯，broker 間同步的數(shù)據(jù)量會變大，集群節(jié)點越多帶寬壓力越大，本質(zhì)上鏡像隊列模式是通過犧牲吞吐量換取的高可用。

反觀前面的普通集群模式，雖然吞吐高但卻犧牲了高可用

還是那句話，做架構(gòu)做到最后，都是在做折中。又升華了。

Quorum 隊列集群

看到這里不知道大家有沒有發(fā)現(xiàn)一個問題，RabbitMQ 集群中每個節(jié)點都能知道某個 Queue 具體在哪個 Broker 上，說明 Broker 間有個機制可以互相同步元數(shù)據(jù)，但架構(gòu)中卻沒有一個類似 kafka 的 zookeeper 那樣的中心節(jié)點。那它是怎么在多個節(jié)點間同步數(shù)據(jù)的呢？

這是因為 RabbitMQ 基于 erlang 進行開發(fā)，這是個很特別的語言，它自帶虛擬機和分布式通信框架，RabbitMQ 通過這個分布式通信框架，在 Broker 間同步元數(shù)據(jù)。

基于erlang分布式通信框架同步元數(shù)據(jù)

但它有個問題，如果broker間通信斷開，鏡像隊列可能出現(xiàn)多個節(jié)點都認(rèn)為自己是主節(jié)點的情況，導(dǎo)致數(shù)據(jù)不一致，也就是所謂的腦裂問題。

腦裂問題

有解法嗎？有！

我們可以使用更靠譜的一致性算法 raft ，來同步多個 broker 的元數(shù)據(jù)和隊列數(shù)據(jù)，通過引入選舉機制來解決網(wǎng)絡(luò)分區(qū)問題，這就是所謂的 Quorum 隊列集群。

Quorum隊列集群

雖然官方推薦大家使用 Quorum 隊列集群，并宣布鏡像隊列集群已被棄用，但目前大部分公司還是用的鏡像隊列集群。

嘿嘿，做架構(gòu)，又不是追時髦，在成本和效率可控的情況下，人和系統(tǒng)，有一個能跑就行。

現(xiàn)在大家通了嗎？

最后遺留一個問題。

想必你聽說過互聯(lián)網(wǎng)三大消息隊列，kafka、rocketMQ、RabbitMQ。曾經(jīng)阿里云團隊對它們做過壓測，同等條件下，kafka 吞吐量是每秒 17w ，rocketMQ 每秒 10w，而 RabbitMQ 則是 5w。

這就很奇怪了，RabbitMQ 雖然比 RocketMQ 功能要豐富些，但差異卻并不大，為什么性能比 RocketMQ 差這么多？

總結(jié)

• RabbitMQ 是一個消息隊列系統(tǒng)，它通過隊列（Queue）來暫存數(shù)據(jù)，實現(xiàn)生產(chǎn)者和消費者之間的解耦，以及流量高峰時的削峰填谷。
• Queue（隊列）是 RabbitMQ 中的基本存儲單元，用于存儲消息。Exchange 是路由分發(fā)組件，用于將消息分發(fā)到一個或多個隊列。
• RabbitMQ 原生支持多種高級特性，如延時隊列、死信隊列和優(yōu)先級隊列。特別是優(yōu)先級隊列，允許根據(jù)消息的優(yōu)先級進行消費，在 GPU 資源緊俏的 AI 服務(wù)場景中非常好用。
• RabbitMQ 集群：為了提高性能和可用性，RabbitMQ 可以通過多節(jié)點構(gòu)成集群：

a.普通集群模式：每個節(jié)點都有完整的 RabbitMQ 實例，可以實現(xiàn)讀寫分離，但單個隊列的讀寫能力沒有提升，且存在單點問題。

b.鏡像隊列模式：主節(jié)點將數(shù)據(jù)同步到從節(jié)點，實現(xiàn)高可用性，但會犧牲一定的吞吐量。

c.Quorum 隊列模式：通過 raft 的一致性算法來同步多個 broker 間的 queue 和元數(shù)據(jù)。