RabbitMQ 4.0 是一個重要的版本更新，主要包括 AMQP 1.0 支持、流隊列（Stream Queues）支、仲裁隊列改進，去除經(jīng)典隊列的 v1 版本支持。在性能、安全和管理界面等方面進行了多項優(yōu)化與改進。

本文將詳細介紹 RabbitMQ 4.0 后新增以及改進的四種主要隊列類型：

• 經(jīng)典隊列（Classic Queue）
• 仲裁隊列（Quorum Queue）
• 流隊列（Stream Queue）
• MQTT QoS 0 隊列

什么是 RabbitMQ 隊列？

RabbitMQ 的隊列本質(zhì)上是一個 先進先出（FIFO）的消息緩沖區(qū)，用于臨時存儲生產(chǎn)者發(fā)送的消息，并由消費者依次消費。

根據(jù)生命周期和使用方式，RabbitMQ 隊列可以分為以下幾類：

接下來，我們深入探討每種隊列類型的實現(xiàn)原理和適用場景。

1?? 經(jīng)典隊列（Classic Queue）

基本介紹

經(jīng)典隊列是 RabbitMQ 中的原始隊列類型，它們使用非復制的 FIFO（先進先出）實現(xiàn)。

經(jīng)典隊列有兩種實現(xiàn)（v1 和 v2）。這兩個版本僅在數(shù)據(jù)在磁盤上的存儲和檢索方式上有所不同，但所有功能在兩種實現(xiàn)中均可用。

經(jīng)典隊列用例

經(jīng)典隊列無需復制，非常適合對高可用性和數(shù)據(jù)安全性要求不高的應用。默認隊列類型就是經(jīng)典隊列。

核心功能

• ? 支持消息和隊列的 TTL（生存時間）
• ? 支持隊列長度限制
• ? 支持消息優(yōu)先級和消費者優(yōu)先級
• ? 支持死信交換（DLX）
• ? 支持 QoS 預取控制
• ? 支持獨占隊列

?? 注意：全局 QoS 預取、v1 版本實現(xiàn)將在 RabbitMQ 4.0 被移除。

存儲實現(xiàn)

• 使用磁盤存儲消息內(nèi)容（消息體）
• 每個隊列維護一個獨立的索引文件，記錄消息位置
• v2 版本引入了“每個隊列獨立的小消息存儲”，提升小消息處理效率

?? 適用場景

• 對高可用性要求不高的任務分發(fā)系統(tǒng)
• 簡單的微服務通信
• 不需要數(shù)據(jù)復制的輕量級隊列場景

?? 局限性

• 缺乏原生復制能力（需依賴鏡像隊列）
• 鏡像隊列存在性能瓶頸和同步阻塞問題
• 不支持消息重放

2?? 仲裁隊列（Quorum Queue）

?? 基本介紹

RabbitMQ Quorum Queue 是一種現(xiàn)代隊列類型，它基于 Raft 共識算法實現(xiàn)了持久、復制的 FIFO 隊列。

RabbitMQ 中的 Quorum 隊列旨在實現(xiàn)高可用性和數(shù)據(jù)安全性。它們在多個節(jié)點之間復制數(shù)據(jù)，以確保即使某些節(jié)點發(fā)生故障，消息也不會丟失。

仲裁隊列用例

Quorum 隊列非常適合那些不接受數(shù)據(jù)丟失的關(guān)鍵應用。它優(yōu)先考慮容錯能力和數(shù)據(jù)安全，而非 Classic 隊列所具備的最低延遲和高級隊列功能。

核心功能

• ? 數(shù)據(jù)復制（多節(jié)點同步）
• ? 持久化存儲（始終啟用）
• ? 支持死信交換（至少一次投遞）
• ? 支持毒藥消息（Poison Message）處理
• ? 更好的故障恢復機制

存儲實現(xiàn)

• 使用預寫日志（WAL）記錄所有操作
• 日志條目同時寫入內(nèi)存和磁盤
• 達到一定大小后寫入段文件并壓縮
• 所有節(jié)點共享 WAL，保證一致性

適用場景

• 關(guān)鍵業(yè)務系統(tǒng)，如金融交易、訂單處理等
• 對數(shù)據(jù)一致性、可靠性要求較高的場景
• 需要自動故障轉(zhuǎn)移和數(shù)據(jù)恢復的環(huán)境

局限性

• 不支持 TTL、隊列長度限制等高級特性
• 相比經(jīng)典隊列，延遲略高
• 不支持非持久或獨占隊列

3?? 流隊列（Stream Queue）

基本介紹

RabbitMQ 中的流隊列是一種持久且可復制的數(shù)據(jù)結(jié)構(gòu)，與傳統(tǒng)隊列類似，它緩沖來自生產(chǎn)者的消息，供消費者讀取。流隊列有兩點不同：

• 生產(chǎn)者如何向他們寫消息
• 以及消費者如何閱讀他們發(fā)送的消息

Streams 的底層模型是一種不可變的僅追加日志。這意味著寫入 Stream 的消息無法被擦除，只能被讀取。要在 RabbitMQ 中讀取 Stream 中的消息，需要一個或多個消費者訂閱該 Stream，并根據(jù)需要多次讀取同一條消息。

核心功能

• ? 持久化 + 復制（默認啟用）
• ? 支持非破壞性讀?。芍貜拖M）
• ? 高吞吐量（適用于大規(guī)模數(shù)據(jù)流）
• ? 內(nèi)置惰性行為（消息直接寫入磁盤）
• ? 支持保留策略（按時間或空間）

? 不支持：

• TTL 或隊列長度限制
• 獨占或臨時隊列

存儲實現(xiàn)

• 使用固定大小的段文件（Segment Files）存儲消息
• 每個段文件默認大小為 512MB
• 消息寫入磁盤后建立索引，便于快速查找
• 支持高效的數(shù)據(jù)壓縮和檢索

適用場景

• 實時數(shù)據(jù)分析（如日志聚合、監(jiān)控指標）
• 消息回溯（Replay）需求
• 高并發(fā)寫入 + 多消費者訂閱的場景
• 構(gòu)建事件溯源（Event Sourcing）系統(tǒng)

4?? MQTT QoS 0 隊列

基本介紹

RabbitMQ 通過 MQTT 插件支持 MQTT 協(xié)議。默認情況下，MQTT 插件會創(chuàng)建經(jīng)典隊列，也可以配置為創(chuàng)建仲裁隊列。

這些傳統(tǒng)隊列將數(shù)據(jù)寫入磁盤，有時會跨節(jié)點復制數(shù)據(jù)，這可能會導致消息流瓶頸。在某些 MQTT 場景中，要求只需將消息發(fā)送給在線訂閱者，而無需持久化和/或復制的開銷。

這就引出了一個問題：我們?nèi)绾尾拍芟@個瓶頸——我們能不能完全不使用隊列？這正是 RabbitMQ 3.12 中引入 MQTT QoS 0 隊列類型的原因。

與經(jīng)典隊列、仲裁隊列和流不同，MQTT QoS 0 隊列類型充當“偽”隊列，這反而消除了底層隊列進程。換句話說，它不作為單獨的 Erlang 進程運行，也不將消息存儲在磁盤上。相反，它使用訂閱客戶端的連接進程郵箱。

這意味著消息將直接發(fā)送到訂閱客戶端的 MQTT 連接進程，繞過傳統(tǒng)的隊列機制，確保立即送達任何“在線”的 MQTT 訂閱者。這種方法顯著降低了延遲和資源占用。

核心功能

• ? 極低延遲（無隊列中轉(zhuǎn)）
• ? 無需持久化或復制
• ? 適用于扇出廣播（一對多）場景
• ? 資源占用極低

存儲實現(xiàn)

• 不使用磁盤存儲
• 消息直接發(fā)送給在線訂閱者的連接郵箱
• 不創(chuàng)建獨立 Erlang 進程

適用場景

• IoT 設備大規(guī)模廣播通知（如固件更新）
• 臨時性消息（可接受丟失）
• 對延遲敏感、但對可靠性要求較低的場景

局限性

• 不支持離線訂閱者
• 無法持久化或重放消息
• 僅適用于 MQTT 協(xié)議

四種隊列類型對比總結(jié)

總結(jié)

如何選擇合適的隊列類型？