Classic Queue

Classic Queue 是 RabbitMQ 最早的队列类型。理解它是理解 Quorum Queue 的基础。

1. Classic Queue 的存储结构

┌──────────────────────────────────────────┐
│            Classic Queue                 │
│                                          │
│  ┌─────────────────────────────────────┐ │
│  │  Q1 (内存，未消费)                   │ │
│  │  [msg1][msg2][msg3]                 │ │
│  └─────────────────────────────────────┘ │
│  ┌─────────────────────────────────────┐ │
│  │  Q2 (内存引用，指向磁盘)               │ │
│  │  [ref1][ref2][ref3]                 │ │
│  └─────────────────────────────────────┘ │
│  ┌─────────────────────────────────────┐ │
│  │  Delta (磁盘，未读)                   │ │
│  │  [msg4][msg5][msg6]...              │ │
│  └─────────────────────────────────────┘ │
│  ┌─────────────────────────────────────┐ │
│  │  Q3 (磁盘索引)                       │ │
│  └─────────────────────────────────────┘ │
└──────────────────────────────────────────┘

Classic Queue 使用一种混合存储：热数据在内存（Q1），冷数据在磁盘（Delta），中间有索引（Q2/Q3）。

上面的 Q1/Q2/Delta/Q3 是特定历史实现的简化模型，不是所有版本的通用布局。Classic Queue 存储实现有版本演进：CQv2（Classic Queue version 2）在 RabbitMQ 3.10 引入，3.12 起成为新建队列的默认实现。排查内存占用、磁盘 I/O 与消息堆积时，应以目标版本的实际行为为准。

2. 消息流转

下面的流转同样基于 §1 的历史实现模型，不代表当前所有版本的通用行为。

消息进入 → Q1（内存）
  │
  ├─ 内存够 → 一直在 Q1，直接消费
  └─ 内存不够 → 换页到磁盘（Delta），Q2 存引用
  
消费时：
  Q1 有消息 → 直接从 Q1 取
  Q1 空了 → 从 Delta 读磁盘 → 加载到 Q1

3. Classic Queue 的局限

问题	说明
镜像队列已移除	Classic Queue 镜像自 3.9 弃用、4.0 移除；Quorum Queue 自 3.8 引入，成为高可用方案
内存瓶颈	消息堆积时换页到磁盘，消费性能下降
无队列级速率整形	生产速度远大于消费速度时消息持续堆积；队列本身不自动整形生产速率。内存达高水位时 Broker 对发布端限速，磁盘空间不足时触发告警并阻塞发布
故障恢复	Broker 崩溃后需从磁盘恢复索引与消息状态，恢复耗时与消息量、持久化配置相关

4. Classic Queue 参数

以下为常用队列声明参数简表。

参数	默认值	说明
x-max-length	不限	Queue 最大消息数
x-max-length-bytes	不限	Queue 最大字节数
x-overflow	drop-head	超限时行为：drop-head（丢队头）/ reject-publish / reject-publish-dlx
x-message-ttl	不限	消息 TTL（毫秒）
x-expires	不限	Queue 一段时间未使用后自动删除
x-max-priority	未启用	最大优先级；启用时设为正整数
x-dead-letter-exchange	无	死信 Exchange
x-dead-letter-routing-key	未指定	死信 routing key；未指定时保留原 routing key，显式配置则覆盖

5. 什么时候还用 Classic Queue

• 已有系统在用 Classic Queue，且运行稳定
• 不需要高可用（单节点场景）
• 临时队列（排他、自动删除）
• 需要优先级队列（Classic Queue 原生支持 x-max-priority）

需要复制与节点故障后的高可用时，优先考虑 Quorum Queue；临时、排他或不需要复制的队列，仍可用 Classic Queue。

6. Classic Queue vs Quorum Queue

维度	Classic Queue	Quorum Queue
高可用	无内置复制（镜像已移除）	Raft 多数派复制
数据持久化	队列需声明 durable，消息需设 deliveryMode=2	队列默认 durable，消息经多数派复制后确认
性能	无共识开销；实际吞吐与延迟需在目标负载下测量	Raft 共识有开销；实际吞吐与延迟需在目标负载下测量
数据安全	队列数据不复制，节点丢失即丢失	消息被多数副本接收后才向发布者确认；已确认消息在多数派存活的前提下安全
适用场景	临时、排他、单节点	生产环境、高可用

详细机制见 Quorum Queue。