你是一個程序員，假設你維護了兩個服務 A 和 B。

A 服務負責轉發用戶請求到 B 服務，B 服務是個算法服務，GPU 資源有限，當請求量大到 B 服務處理不過來的時候，希望能優先處理會員用戶的請求。

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

怎么做到會員優先

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

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

RabbitMQ是什么

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

Queue 是什么

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

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

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

削峰填谷

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

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

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

Exchange 是什么

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

Exchange是什么

這些維護在 Exchange 里的路由方式和綁定關系，我們稱為元數據。

元數據是什么

RabbitMQ 是什么

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

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

RabbitMQ是什么

大佬們在這個架構的基礎上，為 RabbitMQ 實現了各種豐富的特性，你能想到的 MQ 功能它基本都實現了，比如延時隊列，死信隊列，優先級隊列等等。

RabbitMQ的功能

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

優先級隊列是什么

RabbitMQ 支持在生產者發送消息的時候，為消息標記上優先級，消費者總是消費優先級高的消息。

優先級隊列是什么

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

優先級隊列的應用1

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

優先級隊列的應用

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

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

RabbitMQ 集群

既然單節點存在諸多問題，那就讓多個節點構成集群。

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

RabbitMQ集群

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

多種集群模式

普通集群模式

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

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

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

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

寫操作

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

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

消費消息2

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

但問題也很明顯。

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

單點問題

這跟高可用毫不沾邊。

有更好的方案嗎？

鏡像隊列集群

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

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

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

鏡像隊列集群

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

寫操作

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

消費消息1

• 否則，當前 broker 會從主 queue 所在的 broker 上讀取數據，之后返回給消費者。

消費消息2

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

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

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

Quorum 隊列集群

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

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

基于erlang分布式通信框架同步元數據

但它有個問題，如果broker間通信斷開，鏡像隊列可能出現多個節點都認為自己是主節點的情況，導致數據不一致，也就是所謂的腦裂問題。

腦裂問題

有解法嗎？有！

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

Quorum隊列集群

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

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

現在大家通了嗎？

最后遺留一個問題。

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

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

總結

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

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

b.鏡像隊列模式：主節點將數據同步到從節點，實現高可用性，但會犧牲一定的吞吐量。

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