RabbitMQ 入门

这篇笔记用于梳理 RabbitMQ 的 AMQP 模型、核心组件和常见交换器类型，重点不是安装步骤或客户端 API，而是把 Producer、Exchange、Queue、Binding、Broker 之间的关系放到同一条消息链路中理解。

RabbitMQ 既可以用来做系统解耦和异步削峰，也可以承载较细粒度的业务路由；真正容易混淆的地方往往不是“它能不能发消息”，而是“消息到底发给谁、什么时候算发送成功、失败后如何处理”。

参考资料：

官方文档：RabbitMQ Documentation 、 AMQP 0-9-1 Model Explained 、 Exchanges 、 Queues 、 Consumer Acknowledgements and Publisher Confirms

实践参考：JavaGuide RabbitMQ 、 腾讯云社区：RabbitMQ 的重要概念以及安装 [TOC]

RabbitMQ 简介

RabbitMQ 是采用 Erlang 语言实现的开源消息中间件。它最常见的工作模型基于 AMQP 0-9-1 协议：生产者把消息发布到 Exchange，Exchange 再根据绑定规则把消息路由到一个或多个 Queue，最后由消费者从 Queue 中读取并处理消息。

和“只有一个队列供生产和消费”的直觉模型相比，RabbitMQ 更强调路由能力。生产者并不是直接把消息发给某个消费者，而是先交给交换器，再由交换器根据 RoutingKey、BindingKey 和交换器类型决定消息落到哪个队列。因此 RabbitMQ 特别适合那些“同一条消息可能进入不同业务链路”的场景，例如订单事件要同时通知库存、积分、消息通知等多个下游系统。

下图展示的是 AMQP 0-9-1 视角下最核心的消息链路，绿色的 X 表示 Exchange，红色部分表示 Queue，二者都位于 Broker 一侧，蓝色部分则是生产者和消费者等客户端角色。

RabbitMQ 的核心价值大致可以概括为以下几点：

• 可靠性： 支持消息持久化、消费确认、发布确认等机制，用来降低消息在链路中丢失的风险
• 灵活的路由： 通过交换器、绑定关系和路由键把消息分发到不同队列，适合做多下游业务拆分
• 低延迟与易用性： 适合实时性较高的业务消息场景，并且自带管理界面，便于观察队列、连接和消息堆积情况
• 扩展性： 多个 RabbitMQ 节点可以组成集群，随着业务增长逐步扩容
• 高可用能力： 可以通过集群和队列副本机制提升可用性，而不是把所有消息都压在单节点上
• 协议与客户端生态： 除了 AMQP 0-9-1，还支持 STOMP、MQTT 等协议，并提供多语言客户端
• 插件机制： 提供大量官方或社区插件，可以扩展延迟消息、管理能力、协议适配等特性

RabbitMQ 核心概念

RabbitMQ 整体上是一个生产者与消费者模型，主要负责接收、存储和转发消息。可以把消息传递的过程类比成邮局分拣系统：发件人把包裹交到邮局，邮局按照目的地规则进行分拣，暂存在对应区域，最后再交给投递员派送。从计算机术语角度看，RabbitMQ 更像一个“带路由能力的消息交换系统”，而不只是一个简单的 FIFO 队列。

RabbitMQ 的整体模型架构

sequenceDiagram
    participant P as Producer
    participant B as RabbitMQ Broker
    participant C as Consumer

    P->>B: publish(exchange, routingKey, message)
    B->>B: route by binding
    B-->>P: publisher confirm（可选）
    B-->>C: deliver message
    C-->>B: ack / nack / reject

Producer(生产者) 和 Consumer(消费者)

• Producer(生产者)： 生产消息的一方（邮件投递者）
• Consumer(消费者)： 消费消息的一方（邮件收件人）

消息一般由两部分组成：消息属性和消息体。消息体也可以称为 Payload，通常由业务系统自己定义；消息属性中则可包含 priority、delivery-mode、headers 等元数据，而 routing-key 则是在发布消息时参与路由计算的重要参数。生产者把消息交给 RabbitMQ 后，Broker 会依据这些信息和当前拓扑结构决定消息如何路由与投递。

Connection 和 Channel

RabbitMQ 客户端通常不是每发一条消息就新建一个 TCP 连接，而是先建立 Connection，再在同一个连接上创建多个 Channel。Channel 可以理解为“逻辑上的轻量级通信通道”，大多数发布、消费、确认等操作都发生在 Channel 上。这样设计的原因是 TCP 连接的创建与维护成本更高，而 Channel 复用可以显著降低通信开销。

Exchange（交换器）

在 RabbitMQ 中，消息并不是直接被投递到 Queue（消息队列）中的，中间必须先经过 Exchange（交换器）。Exchange 的职责不是存储消息，而是根据绑定关系把消息路由到合适的目标。

Exchange 用来接收生产者发送的消息，并把这些消息路由到服务器中的队列；如果没有匹配到任何队列，消息可能被直接丢弃，也可能在设置了 mandatory 等参数时返回给生产者。可以把交换器理解为 RabbitMQ 中负责“决定消息发往何处”的路由层。

RabbitMQ 常见的 Exchange 类型有 4 种：direct、fanout、topic、headers。其中“默认交换器”本质上是一个特殊的 direct 类型交换器，只是它由系统预先声明且名称为空字符串。不同类型的交换器，对应的路由策略也不同，后面会专门展开。

生产者将消息发给交换器时，一般会指定一个 RoutingKey（路由键），用于参与路由计算。这个 RoutingKey 需要和交换器类型、绑定关系中的 BindingKey 配合使用，才能决定消息的最终去向。

RabbitMQ 通过 Binding（绑定）把 Exchange 和 Queue 关联起来，绑定时通常会指定一个 BindingKey（绑定键）。可以把绑定理解为一条路由规则，而交换器则像是一张由多条绑定规则组成的路由表。Exchange 和 Queue 的关系可以是多对多。

当生产者发送消息时，只有在当前交换器的路由规则下，RoutingKey 与 BindingKey 匹配成功，消息才会进入对应队列。BindingKey 并不是在所有交换器上都生效，例如 fanout 会忽略 RoutingKey，直接把消息发给所有绑定到该交换器的队列。

Queue(消息队列)

Queue（消息队列）用来保存消息直到发送给消费者。它是消息的容器，也是消息在 RabbitMQ 中最常见的落点。一个消息可以被路由到一个或多个队列中，然后等待消费者从这些队列中获取并处理。

RabbitMQ 中消息通常存储在队列中，这一点和 Kafka 这类“分布式日志”风格的中间件不同。Kafka 更强调 Topic、Partition 和顺序追加日志，而 RabbitMQ 更强调 Exchange 到 Queue 的路由与投递。因此两者都能承载异步通信，但建模方式并不一样。

多个消费者可以同时订阅同一个队列，这时队列中的消息通常会在这些消费者之间分摊处理，而不是每个消费者都收到一份完整消息。这种模式适合做任务分发与横向扩容，但也意味着“同一队列挂多个消费者”时，消费顺序和处理并发度需要额外关注。

RabbitMQ 并不存在“队列自己广播给所有消费者”这一层语义。如果有广播需求，常见做法是把同一条消息通过 fanout 或 topic 交换器路由到多个不同队列，再由各自的消费者独立消费。

Broker（消息中间件的服务节点）

对于 RabbitMQ 来说，一个 RabbitMQ Broker 可以简单理解为一个服务节点或服务实例。通常可以把它看作承载 Exchange、Queue、Binding、Connection 等资源的消息服务端。

Virtual Host（虚拟主机）

Virtual Host（简称 vhost）是 RabbitMQ 中的逻辑隔离单元。不同 vhost 之间的 Exchange、Queue、Binding、权限配置相互隔离，常用于区分测试环境、生产环境，或者区分不同业务线。理解 vhost 很重要，因为很多“为什么明明声明了队列却找不到”的问题，本质上是连接到了错误的 vhost。

下图展示了生产者将消息存入 RabbitMQ Broker，以及消费者从 Broker 中消费数据的整个流程

Exchange Types(交换器类型)

RabbitMQ 常用的 Exchange Type 有 fanout、direct、topic、headers 这四种。不同交换器本质上解决的是不同的路由问题，因此不能只记名字，更要记清楚“它根据什么规则决定消息去向”。

fanout：

fanout 类型的 Exchange 路由规则非常简单：它会把所有发送到该 Exchange 的消息路由到所有与它绑定的 Queue 中，不需要做任何匹配判断，因此常用于广播消息。

direct：

direct 类型的 Exchange 会把消息路由到那些 BindingKey 与 RoutingKey 完全匹配的 Queue 中。这种路由方式最直接，适合把不同类别的消息分到不同队列中。

以上图为例，如果发送消息时设置路由键为 warning，那么消息会路由到 Queue1 和 Queue2。如果设置路由键为 info 或者 debug，消息只会路由到 Queue2。如果使用其他路由键，则消息不会进入这两个队列。

direct 类型常用在精确路由场景中，例如按照日志级别、业务类型、任务优先级把消息分发到不同队列。

topic：

前面讲到 direct 类型要求 BindingKey 和 RoutingKey 完全匹配，但这种严格匹配方式在很多场景下不够灵活。topic 类型在匹配规则上做了扩展，它仍然基于 BindingKey 和 RoutingKey 进行路由，只是支持通配符匹配。它约定：

• RoutingKey 是一个由点号 . 分隔的字符串，例如 com.rabbitmq.client、java.util.concurrent、com.hidden.client
• BindingKey 和 RoutingKey 一样，也使用点号 . 进行分段
• BindingKey 中可以使用两种特殊字符：* 用于匹配一个单词，# 用于匹配多个单词（可以是零个）

以上图为例：

• 路由键为 com.rabbitmq.client 的消息会同时路由到 Queue1 和 Queue2
• 路由键为 com.hidden.client 的消息只会路由到 Queue2
• 路由键为 com.hidden.demo 的消息只会路由到 Queue2
• 路由键为 java.rabbitmq.demo 的消息只会路由到 Queue1
• 路由键为 java.util.concurrent 的消息将会被丢弃，或者在设置了 mandatory 参数时返回给生产者，因为它没有匹配任何绑定规则

headers：

headers 类型的交换器不依赖 RoutingKey，而是根据消息属性里的 headers 键值对进行匹配。在绑定队列和交换器时，需要先指定一组键值规则；发送消息时，RabbitMQ 会拿消息里的 headers 和这些规则进行比对，匹配成功才会路由到对应队列。

headers 类型的灵活性较高，但通常配置更复杂，性能和可维护性也不如前面几种交换器，因此在日常业务系统里并不常见。

RabbitMQ 中几个容易混淆的问题

消息持久化并不等于消息绝对不会丢

很多资料会把“队列持久化”直接等同于“消息可靠”。更稳妥的理解是：队列持久化、消息持久化、生产端发布确认、消费者手动确认，分别覆盖的是不同环节的风险。只有把这些环节串起来，消息链路才更完整。

例如：

• 队列是 durable 的，只表示队列元数据会持久化，不代表所有消息都一定安全落盘
• 消息设置为 persistent，可以降低 Broker 重启时丢消息的风险，但它仍然不能代替生产端确认
• 如果生产者没有开启 publisher confirms，就无法准确知道消息是否已经被 Broker 接收并处理
• 如果消费者采用自动确认，业务逻辑还没真正执行完成，消息就可能已经被视为“消费成功”

消费者 ACK 和生产者 Confirm 解决的是两段不同问题

RabbitMQ 中常见的两个确认机制很容易混淆：

• Consumer ACK： 解决“消费者是否已经成功处理消息”的问题
• Publisher Confirm： 解决“生产者发出去的消息，Broker 是否已经收到”的问题

前者站在消费端看数据处理结果，后者站在生产端看投递结果。二者并不互相替代，很多业务场景里需要同时使用。

顺序性通常只在受限并发条件下更容易保证

RabbitMQ 的队列在理想情况下可以按入队顺序投递，但一旦引入多个消费者、重回队列、优先级队列等机制，最终观察到的处理顺序就可能发生变化。因此如果业务强依赖顺序，通常要同时控制以下几个因素：

• 尽量把同一业务键路由到同一个队列
• 控制消费端并发度，必要时采用单消费者串行处理
• 谨慎使用重新入队、优先级队列等会打乱顺序的能力

广播靠的是 Exchange 到多个 Queue 的分发，不是 Queue 自己广播

RabbitMQ 的广播语义应该从交换器层面理解，而不是从队列层面理解。常见做法是把同一条消息通过 fanout 或 topic 交换器路由到多个不同队列，每个队列分别服务一个下游系统。这样既保留了广播效果，也保留了各下游独立扩缩容、独立失败隔离的能力。

TTL、死信队列、重试队列是工程实践里很常见的增强能力

入门阶段掌握 Exchange、Queue、Binding、ACK 已经可以理解 RabbitMQ 的主干模型，但在真实业务里还经常会继续引入以下机制：

• TTL： 控制消息或队列的过期时间
• Dead Letter Exchange / Queue： 承接过期、被拒绝或无法正常消费的消息
• Retry Queue： 利用死信和过期机制实现延迟重试
• Prefetch： 控制消费者一次能拉取多少未确认消息，平衡吞吐和公平分发

这些机制并不改变 RabbitMQ 的核心模型，但决定了系统在失败重试、堆积治理和消费稳定性方面的表现。

• Previous
  RocketMQ入门
• Next
  Java 常见面试问题整理 II