RabbitMQ 4.0：大声说俺中不中

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 协议

📊 四种队列类型对比总结

🧭 总结

如何选择合适的队列类型？