又老效能又差，為什麼好多公司依然選擇 RabbitMQ？

來源：君哥聊技術

大家好，我是君哥。

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，三個命令就可以。

1. 拉取映象

docker pull rabbitmq:3.8.2-management

1. 建立路徑

mkdir /var/lib/rabbitmq

1. 啟動容器

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 種。

1. Direct Exchange

生產者將訊息傳送給 Exchange 後，Exchange 透過 Routing Key 把訊息路由到對應的佇列。如下圖（來自官網）：

1. Fanout Exchange

生產者將訊息傳送給 Exchange 後，Exchange 將訊息路由到所有繫結的佇列，類似於廣播模式。如下圖（來自官網）：

1. Topic Exchange

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

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

1. 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 成為非常受歡迎的訊息佇列。