大家好，我是君哥。

RabbitMQ 這個(gè)消息隊(duì)列相信很多程序員都用過(guò)，我第一次使用是在 2016 年，確實(shí)是一個(gè)老牌的消息隊(duì)列了，但是為什么一直沒(méi)有被淘汰呢？今天來(lái)聊一聊這個(gè)話題。

老舊差

發(fā)布?xì)v史

為什么說(shuō) RabbitMQ 老呢？下圖是 RabbitMQ 最早的發(fā)布記錄，可以看到 RabbitMQ 在 2007 年已經(jīng)發(fā)布，已經(jīng)有 16 年多的使用歷史了。

小眾

為什么說(shuō) RabbitMQ 比較小眾呢？

一方面 RabbitMQ 使用 Erlang 語(yǔ)言編寫，這是一個(gè)比較小眾的編程語(yǔ)言，學(xué)習(xí)成本非常高，不像 Java、Scala、C 等編程語(yǔ)言學(xué)起來(lái)簡(jiǎn)單。所以雖然 RabbitMQ 也是開(kāi)源的消息隊(duì)列，但基于 RabbitMQ 做擴(kuò)展和二次開(kāi)發(fā)的情況是很少。

另一方面從使用的協(xié)議來(lái)看，RabbitMQ 支持 AMQP（Advanced Message Queuing Protocol） 協(xié)議，這也是主流消息隊(duì)列不支持的。

AMQP 協(xié)議如下圖：

有幾個(gè)概念介紹一下：

• Connection：一個(gè)網(wǎng)絡(luò)連接，AMQP 協(xié)議通常使用長(zhǎng)連接；
• Channel：網(wǎng)絡(luò)信道，建立在 Connection 之上的輕量級(jí)的連接，一個(gè) Connection 可以有多個(gè) Channel；
• Exchange：交換器，接收消息后將消息路由轉(zhuǎn)發(fā)給綁定（Binding）的 Queue；
• Binding：Exchange 和 Queue 之間的虛擬連接；
• Routing Key：這個(gè)概念在圖中沒(méi)有畫，是指路由規(guī)則，用來(lái)確定 Exchange 將消息路由到哪些 Queue。

可以看到，好多概念在主流的消息隊(duì)列比如 Kafka、RocketMQ 是沒(méi)有的，所以說(shuō) RabbitMQ 比較小眾。

性能差

在底層消息持久化的方式上，RabbitMQ 并沒(méi)有使用 MMAP、Sendfile 等零拷貝技術(shù)，這是性能差的一個(gè)重要原因。

在架構(gòu)上，RabbitMQ 提供了鏡像隊(duì)列來(lái)做 Master 的備份。如下圖：

無(wú)論生產(chǎn)者發(fā)送消息，還是消費(fèi)者拉取消息，如果請(qǐng)求發(fā)送到鏡像隊(duì)列，則鏡像隊(duì)列需要把請(qǐng)求轉(zhuǎn)發(fā)到 Master 進(jìn)行處理，Master 處理后再把結(jié)果回復(fù)給鏡像節(jié)點(diǎn)，鏡像隊(duì)列回復(fù)給請(qǐng)求者。

在特定硬件環(huán)境下，RabbitMQ 支持的消息吞吐量在萬(wàn)級(jí)~十萬(wàn)級(jí)，相比 RocketMQ 的十萬(wàn)級(jí)~百萬(wàn)級(jí)和 Kafka 的百萬(wàn)級(jí)以上，吞吐量還是差一些。

受歡迎

從我過(guò)往的公司、身邊的一些朋友、面試過(guò)的候選人簡(jiǎn)歷可以看出，好多公司消息隊(duì)列技術(shù)選型時(shí)選擇了 RabbitMQ，這跟 RabbitMQ 老舊和性能差形成鮮明對(duì)比。

RabbitMQ 為什么這么受歡迎呢？

持續(xù)更新

雖然 RabbitMQ 老舊，但是并沒(méi)有停止更新，而且更新還挺頻繁，下圖是 2023 年最近發(fā)布的幾個(gè)版本：

從 2007 年開(kāi)始，RabbitMQ 已經(jīng)有 16 年的使用歷史，可以稱得上是一個(gè)久經(jīng)考驗(yàn)的戰(zhàn)士，各種問(wèn)題已經(jīng)修復(fù)，學(xué)習(xí)資料豐富，性能穩(wěn)定。

運(yùn)維簡(jiǎn)單

RabbitMQ 是一個(gè)非常輕量級(jí)的消息隊(duì)列，官方宣稱開(kāi)箱即用。在 Docker 上部署 RabbitMQ，三個(gè)命令就可以。

拉取鏡像

docker pull rabbitmq:3.8.2-management

創(chuàng)建路徑

mkdir /var/lib/rabbitmq

啟動(dòng)容器

docker run -d --name rabbitmq3.8.2 -p 5672:5672 -p 15672:15672 -v `pwd`/data:/var/lib/rabbitmq --hostname myRabbit -e RABBITMQ_DEFAULT_VHOST=my_vhost -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin --privileged=true

這種開(kāi)箱即用的效果，大大降低了學(xué)習(xí)成本和運(yùn)維成本。

靈活路由

依托于 AMQP 中的 Exchange，RabbitMQ 提供了靈活的路由配置，有 4 種。

Direct Exchange

生產(chǎn)者將消息發(fā)送給 Exchange 后，Exchange 通過(guò) Routing Key 把消息路由到對(duì)應(yīng)的隊(duì)列。如下圖（來(lái)自官網(wǎng)）：

Fanout Exchange

生產(chǎn)者將消息發(fā)送給 Exchange 后，Exchange 將消息路由到所有綁定的隊(duì)列，類似于廣播模式。如下圖（來(lái)自官網(wǎng)）：

Topic Exchange

這種路由策略首先定義一個(gè) Topic，topic 中可以包含 * 和 #。* 可以代表一個(gè)單詞，# 可以代表 0 或多個(gè)單詞。如下圖（來(lái)自官網(wǎng)）：

圖中 Topic 由三個(gè)單詞<celerity>.<colour>.<species>組成，分別代表特征、顏色和物種，單詞之間用.間隔。這樣 Q1 將接收顏色為 orange 的所有消息，Q2 將接收物種為 rabbit 的消息和特征為 lazy 的消息。

Headers Exchange

這種路由策略要求消息中需要攜帶 Headers(類似 Http 中的消息頭)，隊(duì)列跟 Routing Key 綁定時(shí)也要定義一個(gè) Headers，只有綁定中定義的 Headers 跟消息中的 Header 匹配，才會(huì)路由到相應(yīng)的隊(duì)列。匹配規(guī)則有兩種：

• ALL：要求兩個(gè) Headers 中所有 key 和 value 匹配；
• ANY：要求兩個(gè) Headers 任何一個(gè) key 和 value 匹配。

如下圖：

這種路由方式在定義綁定關(guān)系的時(shí)候就需要定義 Headers，如下代碼：

@Bean
public Binding binding1(HeadersExchange headersExchange,Queue queue1){
 HashMap<String, Object> headers = new HashMap<>();
 headers.put("key1","aaa");
 headers.put("key2","bbb");
 return BindingBuilder.bind(queue1).to(headersExchange).whereAll(headers).match();
}

public Binding binding2(HeadersExchange headersExchange,Queue queue2){
 HashMap<String, Object> headers = new HashMap<>();
 headers.put("key1","aaa");
 headers.put("key2","bbb");
 return BindingBuilder.bind(queue2).to(headersExchange).whereAny(headers).match();
}

客戶端豐富

RabbitMQ 客戶端支持的編程語(yǔ)言是消息隊(duì)列中最多的，很容易兼容自己系統(tǒng)使用的編程語(yǔ)言。參考下圖（來(lái)自官網(wǎng)）：

總結(jié)

RabbitMQ 雖然老舊，但具有運(yùn)維簡(jiǎn)單、靈活路由、客戶端豐富等特性。雖然吞吐量不高，但性能足夠滿足中小企業(yè)的使用需求。這讓 RabbitMQ 成為非常受歡迎的消息隊(duì)列。