大家好，我是君哥。

RabbitMQ 這個消息隊列相信很多程序員都用過，我第一次使用是在 2016 年，確實是一個老牌的消息隊列了，但是為什么一直沒有被淘汰呢？今天來聊一聊這個話題。

老舊差

發布歷史

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

小眾

為什么說 RabbitMQ 比較小眾呢？

一方面 RabbitMQ 使用 Erlang 語言編寫，這是一個比較小眾的編程語言，學習成本非常高，不像 Java、Scala、C 等編程語言學起來簡單。所以雖然 RabbitMQ 也是開源的消息隊列，但基于 RabbitMQ 做擴展和二次開發的情況是很少。

另一方面從使用的協議來看，RabbitMQ 支持 AMQP（Advanced Message Queuing Protocol） 協議，這也是主流消息隊列不支持的。

AMQP 協議如下圖：

有幾個概念介紹一下：

• Connection：一個網絡連接，AMQP 協議通常使用長連接；
• Channel：網絡信道，建立在 Connection 之上的輕量級的連接，一個 Connection 可以有多個 Channel；
• Exchange：交換器，接收消息后將消息路由轉發給綁定（Binding）的 Queue；
• Binding：Exchange 和 Queue 之間的虛擬連接；
• Routing Key：這個概念在圖中沒有畫，是指路由規則，用來確定 Exchange 將消息路由到哪些 Queue。

可以看到，好多概念在主流的消息隊列比如 Kafka、RocketMQ 是沒有的，所以說 RabbitMQ 比較小眾。

性能差

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

在架構上，RabbitMQ 提供了鏡像隊列來做 Master 的備份。如下圖：

無論生產者發送消息，還是消費者拉取消息，如果請求發送到鏡像隊列，則鏡像隊列需要把請求轉發到 Master 進行處理，Master 處理后再把結果回復給鏡像節點，鏡像隊列回復給請求者。

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

受歡迎

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

RabbitMQ 為什么這么受歡迎呢？

持續更新

雖然 RabbitMQ 老舊，但是并沒有停止更新，而且更新還挺頻繁，下圖是 2023 年最近發布的幾個版本：

從 2007 年開始，RabbitMQ 已經有 16 年的使用歷史，可以稱得上是一個久經考驗的戰士，各種問題已經修復，學習資料豐富，性能穩定。

運維簡單

RabbitMQ 是一個非常輕量級的消息隊列，官方宣稱開箱即用。在 Docker 上部署 RabbitMQ，三個命令就可以。

拉取鏡像

docker pull rabbitmq:3.8.2-management

創建路徑

mkdir /var/lib/rabbitmq

啟動容器

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

這種開箱即用的效果，大大降低了學習成本和運維成本。

靈活路由

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

Direct Exchange

生產者將消息發送給 Exchange 后，Exchange 通過 Routing Key 把消息路由到對應的隊列。如下圖（來自官網）：

Fanout Exchange

生產者將消息發送給 Exchange 后，Exchange 將消息路由到所有綁定的隊列，類似于廣播模式。如下圖（來自官網）：

Topic Exchange

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

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

Headers Exchange

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

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

如下圖：

這種路由方式在定義綁定關系的時候就需要定義 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 客戶端支持的編程語言是消息隊列中最多的，很容易兼容自己系統使用的編程語言。參考下圖（來自官網）：

總結

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