RabbitMQ：队列-Queues

最新推荐文章于 2025-05-14 17:20:44 发布

喝醉酒的小白

最新推荐文章于 2025-05-14 17:20:44 发布

阅读量642

点赞数 12

分类专栏： DBA 文章标签： rabbitmq ruby 分布式

本文链接：https://blog.csdn.net/hezuijiudexiaobai/article/details/147950426

版权

DBA 专栏收录该内容

822 篇文章

订阅专栏

目录标题

概览

RabbitMQ 提供三种主要的队列实现类型：Classic、Quorum 和 Stream，它们面向不同的使用场景与可靠性需求。Classic 队列 是最通用、轻量的默认实现，消息存储在单一节点内存/磁盘上，适合低延迟或非关键性任务【(RabbitMQ)】【(CloudAMQP)】。Quorum 队列 基于 Raft 共识算法，将消息复制到多节点，以保证强一致性与高可用，但因同步复制会产生额外延迟，适用于对数据安全性要求极高的关键业务【(RabbitMQ)】【(Amazon Web Services, Inc.)】。Stream 队列 则是一个持久化、可复制的追加日志（append-only log），支持非破坏性消费（consumers 读取时不从日志中移除消息）、随机访问以及灵活的保留策略，非常适合大规模事件流处理与实时分析场景【(RabbitMQ)】【(RabbitMQ)】。

1. Classic 队列

1.1 定义与版本演进

Classic 队列 是 RabbitMQ 的默认队列类型，自 4.0 版本起将旧版 CQV1 与 CQV2 合并，仅保留 CQV2 实现【(RabbitMQ)】【(CloudAMQP)】。

1.2 存储与性能

消息存储在单个节点的内存或（当达到内存阈值或开启 lazy 模式时）磁盘上【(RabbitMQ)】。
不进行多节点复制，吞吐量最高、延迟最低，但节点故障会导致该节点上所有消息丢失【(CloudAMQP)】。

1.3 特性与限制

支持延迟队列、优先级队列、死信队列等丰富扩展【(RabbitMQ)】。
已废弃的镜像队列（Mirrored Queues）在 4.x 中被移除，建议使用 Quorum 队列替代【(RabbitMQ)】。

1.4 典型场景

适用于对节点故障不敏感、需要极低延迟或高吞吐的场景，如实时监控、缓存更新等。

2. Quorum 队列

2.1 定义与协议

Quorum 队列 是基于 Raft 共识算法的复制队列类型，需要在声明时指定 x-queue-type=quorum，不可通过策略动态修改【(RabbitMQ)】。

2.2 复制与一致性

每个队列都有一个 Leader 与多个 Follower（默认节点数可配置，最少 3 节点以容忍单节点故障）【(RabbitMQ)】。
写操作在大多数节点（quorum）写入并持久化后才确认，确保不会出现脑裂或数据丢失【(Amazon Web Services, Inc.)】。

2.3 性能与可用性

相较 Classic，写入和读取延迟略高，但可在节点故障时自动切换 Leader，保证持续可用【(SeventhState.io)】。
不支持级联（Cascade）或多源（Multi-Source）复制，仅本地集群内节点参与复制。

2.4 典型场景

适合金融交易、订单处理等对 “强一致性＋高可用” 有严格要求的业务。

3. Stream 队列

3.1 定义与模型

Stream 队列 是一种持久化的、可复制的追加日志结构（append-only log），在声明时指定 x-queue-type=stream【(RabbitMQ)】。

3.2 存储与消费语义

消息以有序日志块写入磁盘，可跨节点复制，提供数据安全和可用性【(RabbitMQ)】。
消费者通过 offset 随机读取或顺序读取消息；读取不会删除日志，消息保留直至过期策略触发【(RabbitMQ)】。

3.3 保留与回放

支持基于总大小或消息存活时长的 retention 策略，自动丢弃最旧的消息块【(Stack Overflow)】。
允许多次回放、并行消费和 “重置 offset”，非常适合事件溯源（event sourcing）和实时流处理。

3.4 典型场景

适用于物联网（IoT）数据汇聚、日志聚合、实时分析及需要多次消费同一消息集的场景。

4. 特性对比

特性	Classic	Quorum	Stream
复制	无	Raft 同步复制，需大多数节点确认	日志块跨节点复制
一致性保障	单节点存储，节点故障丢失	强一致性（多数确认）	持久化日志 + 多副本
消费模式	FIFO，消费即删除	FIFO，消费即删除	按 offset 读取，非破坏性消费
延迟 & 吞吐	最低延迟、最高吞吐	较高延迟，吞吐略低	较高吞吐，适合大批量写入
故障恢复	消息丢失	Leader 故障自动切换	副本节点继续提供服务
高级特性	优先级、死信、TTL	无，设计简单可靠	回放、随机访问、灵活保留策略
适用场景	低延迟、高吞吐、非关键数据	关键业务、强一致性	事件流处理、日志、IoT 数据、实时分析

以上便是 RabbitMQ 三种队列类型的详细介绍与对比。根据您的业务对 一致性保障、延迟/吞吐 及 消费语义 的需求，可灵活选择最合适的队列类型。

创建

在这里插入图片描述

在 RabbitMQ 的 Management UI（和 HTTP API）里，“Type”下拉框里列出的 Classic、Quorum、Stream，是指 队列的实现类型，而不是之前我们说的 durable、exclusive、auto_delete 这些队列属性。它们各自代表了不同的存储和复制机制：

队列类型	用途 & 特性
Classic	默认、最通用的队列实现。消息存放在一个节点上，支持多种参数（`lazy` 模式、优先级队列、TTL、死信等），性能最优，但单节点故障会丢失该节点上的消息。
Quorum	基于 Raft 协议的队列复制（类似 Kafka 分区），将数据复制到一组节点，保证一致性与高可用；适合对数据可靠性要求高的场景，但延迟略高于 Classic。
Stream	专为大规模、高吞吐的日志/事件流设计（类似 Kafka），支持按消息偏移量（offset）读取、随机访问，并且可以滚动过期；不适合传统点对点消息队列语义，但在实时流处理场景中非常强大。

而 durable（持久化）、exclusive（独占）、auto_delete（自动删除）等，仍然是队列创建时的属性，用来控制队列本身在服务重启、连接断开后的行为，它们和 “Type” 是两组互不冲突的概念：

rabbitmqctl declare_queue \
  --vhost=/my-vhost \
  --name=my-queue \
  --type=quorum \
  --durable=true \
  --auto_delete=false

上面这条命令就创建了一个 Quorum 类型、持久化、非自动删除 的队列。

小结

Type（类型）：决定了队列内部的消息存储 & 复制机制（Classic/Quorum/Stream）。
durable/exclusive/auto_delete：决定了队列在节点重启、连接关闭后是否保留、是否只允许单一连接、是否在空闲时自动删除。

因此，UI 里看到的那几个 “Type” 就是目前 RabbitMQ 核心支持的三种队列实现。