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

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

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

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

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

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

RabbitMQ是什么

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

Queue 是什么

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

隊(duì)列是類似鏈表的獨(dú)立進(jìn)程

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

削峰填谷

這個(gè)類似鏈表的進(jìn)程，就是Queue，也叫隊(duì)列。

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

A進(jìn)程掛了不影響其他進(jìn)程

Exchange 是什么

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

Exchange是什么

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

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

RabbitMQ 是什么

像這樣一個(gè)包含多個(gè) Queue 進(jìn)程 和 Exchange 組件 的消息隊(duì)列，就是所謂的 RabbitMQ。

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

RabbitMQ是什么

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

RabbitMQ的功能

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

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

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

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

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

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

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

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

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

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

RabbitMQ 集群

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

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

RabbitMQ集群

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

多種集群模式

普通集群模式

在普通集群模式中，每個(gè) Broker 都是一個(gè)完整功能的 RabbitMQ 實(shí)例，都能進(jìn)行讀寫。

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

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

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

寫操作

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

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

消費(fèi)消息2

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

但問題也很明顯。

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

單點(diǎn)問題

這跟高可用毫不沾邊。

有更好的方案嗎？

鏡像隊(duì)列集群

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

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

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

鏡像隊(duì)列集群

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

寫操作

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

消費(fèi)消息1

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

消費(fèi)消息2

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

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

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

Quorum 隊(duì)列集群

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

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

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

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

腦裂問題

有解法嗎？有！

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

Quorum隊(duì)列集群

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

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

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

最后遺留一個(gè)問題。

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

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

總結(jié)

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

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

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

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