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

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

• 經典隊列（Classic Queue）
• 仲裁隊列（Quorum Queue）
• 流隊列（Stream Queue）
• MQTT QoS 0 隊列

什么是 RabbitMQ 隊列？

RabbitMQ 的隊列本質上是一個 先進先出（FIFO）的消息緩沖區，用于臨時存儲生產者發送的消息，并由消費者依次消費。

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

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

1?? 經典隊列（Classic Queue）

基本介紹

經典隊列是 RabbitMQ 中的原始隊列類型，它們使用非復制的 FIFO（先進先出）實現。

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

經典隊列用例

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

核心功能

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

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

存儲實現

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

?? 適用場景

• 對高可用性要求不高的任務分發系統
• 簡單的微服務通信
• 不需要數據復制的輕量級隊列場景

?? 局限性

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

2?? 仲裁隊列（Quorum Queue）

?? 基本介紹

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

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

仲裁隊列用例

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

核心功能

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

存儲實現

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

適用場景

• 關鍵業務系統，如金融交易、訂單處理等
• 對數據一致性、可靠性要求較高的場景
• 需要自動故障轉移和數據恢復的環境

局限性

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

3?? 流隊列（Stream Queue）

基本介紹

RabbitMQ 中的流隊列是一種持久且可復制的數據結構，與傳統隊列類似，它緩沖來自生產者的消息，供消費者讀取。流隊列有兩點不同：

• 生產者如何向他們寫消息
• 以及消費者如何閱讀他們發送的消息

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

核心功能

• ? 持久化 + 復制（默認啟用）
• ? 支持非破壞性讀取（可重復消費）
• ? 高吞吐量（適用于大規模數據流）
• ? 內置惰性行為（消息直接寫入磁盤）
• ? 支持保留策略（按時間或空間）

? 不支持：

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

存儲實現

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

適用場景

• 實時數據分析（如日志聚合、監控指標）
• 消息回溯（Replay）需求
• 高并發寫入 + 多消費者訂閱的場景
• 構建事件溯源（Event Sourcing）系統

4?? MQTT QoS 0 隊列

基本介紹

RabbitMQ 通過 MQTT 插件支持 MQTT 協議。默認情況下，MQTT 插件會創建經典隊列，也可以配置為創建仲裁隊列。

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

這就引出了一個問題：我們如何才能消除這個瓶頸——我們能不能完全不使用隊列？這正是 RabbitMQ 3.12 中引入 MQTT QoS 0 隊列類型的原因。

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

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

核心功能

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

存儲實現

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

適用場景

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

局限性

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

四種隊列類型對比總結

總結

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