RabbitMQ 日常开发重点学习文档

目标：学完后能够理解 RabbitMQ 的核心工作流程，独立完成消息发送、消费、交换机路由、确认机制、死信队列、延迟消息、可靠性处理及日常排错。
原则：先会用，再理解原理；优先掌握日常项目中真正高频的 RabbitMQ 知识。

📌 目录

RabbitMQ 是什么，为什么要用
核心概念与完整消息流程
- 2.1 Producer（生产者）
- 2.2 Queue（队列）
- 2.3 Consumer（消费者）
- 2.4 Exchange（交换机）
- 2.5 Binding（绑定）
- 2.6 Routing Key（路由键）
RabbitMQ 最基本的消息模型
Exchange 交换机类型
- 4.1 Direct Exchange
- 4.2 Fanout Exchange
- 4.3 Topic Exchange
- 4.4 Headers Exchange
消息确认机制
- 5.1 Consumer ACK
- 5.2 NACK / Reject
- 5.3 自动确认与手动确认
消息持久化
Publisher Confirm 生产者确认
消息消费失败与重试
Dead Letter Queue 死信队列
TTL 与延迟消息
Prefetch 与消费速度控制
RabbitMQ 常见业务场景
RabbitMQ 管理与高频操作
日常排错
常见设计错误
RabbitMQ 高频知识速查表
推荐学习路径

1. RabbitMQ 是什么，为什么要用

RabbitMQ 是一个：

Message Broker（消息代理 / 消息中间件）

它的主要作用是：

在不同服务之间接收、存储并转发消息。

最简单的结构：

Producer
生产者
   ↓
RabbitMQ
   ↓
Consumer
消费者

例如用户下单：

用户下单
  ↓
订单服务

如果订单服务同步完成：

扣库存
发短信
发优惠券
记录日志
推送消息
生成积分

整个请求可能变得很慢。

使用 RabbitMQ 后：

订单服务
   ↓
发送订单创建消息
   ↓
RabbitMQ
   ├── 库存消费者
   ├── 短信消费者
   ├── 积分消费者
   └── 消息推送消费者

订单服务只负责：

创建订单
+
发送消息

其他工作异步执行。

1.1 RabbitMQ 主要解决什么问题

异步处理

Asynchronous Processing：

异步处理

原来：

A
↓
B
↓
C
↓
D

改为：

A
↓
RabbitMQ
├── B
├── C
└── D

可以降低主流程响应时间。

系统解耦

Decoupling：

解耦

例如订单系统不需要知道：

短信系统怎么发送
积分系统怎么计算
消息系统怎么推送

订单系统只负责发送：

order.created

消息。

削峰填谷

Traffic Shaping：

流量削峰

假设突然有：

10000 个请求

而数据库每秒只能处理：

1000 个

RabbitMQ 可以：

先把 10000 条消息存起来
↓
消费者按照自己的能力慢慢处理

避免瞬间把下游服务打垮。

2. 核心概念与完整消息流程

RabbitMQ 最重要的几个概念：

概念	中文	作用
Producer	生产者	发送消息
Exchange	交换机	决定消息发到哪个 Queue
Queue	队列	存储消息
Binding	绑定关系	连接 Exchange 和 Queue
Routing Key	路由键	帮助 Exchange 路由消息
Consumer	消费者	消费消息

完整流程：

Producer
   ↓
Exchange
   ↓
根据 Routing Key + Binding
   ↓
Queue
   ↓
Consumer

这个流程必须记住。

2.1 Producer（生产者）

Producer：

Producer（生产者）

负责发送消息。

例如：

订单服务

发送：

{
  "order_id": 10001,
  "user_id": 20001,
  "amount": 199.00
}

Producer 并不是直接决定：

哪个 Consumer 处理

而是先发送给：

Exchange

2.2 Queue（队列）

Queue：

Queue（消息队列）

负责保存消息。

例如：

order.queue
sms.queue
stock.queue

结构：

Message 1
Message 2
Message 3
Message 4

消费者一般按照进入队列的顺序消费。

2.3 Consumer（消费者）

Consumer：

Consumer（消费者）

负责从 Queue 中取消息并处理。

例如：

order.queue
   ↓
OrderConsumer

处理：

扣库存
生成订单任务
发送通知

2.4 Exchange（交换机）

Exchange：

Exchange（交换机）

Exchange 是 RabbitMQ 非常重要的概念。

Producer 通常不是直接把消息发给 Queue。

而是：

Producer
   ↓
Exchange
   ↓
Queue

Exchange 根据规则决定：

消息应该进入哪个 Queue

2.5 Binding（绑定）

Binding：

Binding（绑定关系）

表示：

Exchange
   ↓
Queue

之间的连接关系。

例如：

order.exchange
   ↓
order.queue

2.6 Routing Key（路由键）

Routing Key：

Routing Key（路由键）

用于帮助 Exchange 判断：

消息应该去哪里

例如：

order.created
order.cancelled
order.paid

3. RabbitMQ 最基本的消息模型

最简单：

Producer
   ↓
Queue
   ↓
Consumer

RabbitMQ 内部实际上仍然可能经过默认 Exchange。

实际开发建议理解完整结构：

Producer
   ↓
Exchange
   ↓
Queue
   ↓
Consumer

4. Exchange 交换机类型

RabbitMQ 日常最重要的是三种：

Direct
Fanout
Topic

Headers 使用频率较低。

4.1 Direct Exchange

Direct Exchange：

Direct Exchange（直连交换机）

根据：

Routing Key

精确匹配。

例如：

Exchange:
order.exchange

绑定：

order.created
→ order-created.queue

order.cancelled
→ order-cancelled.queue

发送：

Routing Key = order.created

消息只会进入：

order-created.queue

适合：

明确、一对一的消息路由

4.2 Fanout Exchange

Fanout Exchange：

Fanout Exchange（广播交换机）

特点：

不关心 Routing Key，消息广播给所有绑定 Queue。

例如：

order.created
        ↓
   Fanout Exchange
     ├── sms.queue
     ├── points.queue
     └── analytics.queue

一个订单创建消息：

短信
积分
统计

三个系统都能收到。

适合：

广播通知
事件分发
一个事件多个系统处理

4.3 Topic Exchange

Topic Exchange：

Topic Exchange（主题交换机）

支持通配符匹配 Routing Key。

例如：

order.created
order.paid
order.cancelled

user.created
user.deleted

通配符：

匹配一个单词。

匹配零个或多个单词。

例如：

order.*

可以匹配：

order.created
order.paid

但不能匹配：

order.payment.success

而：

order.#

可以匹配：

order.created
order.payment.success
order.refund.success

Topic 是实际项目中非常常用的一种 Exchange。

4.4 Headers Exchange

Headers Exchange：

Headers Exchange（请求头交换机）

根据消息 Headers 进行匹配。

例如：

type=order
region=beijing

实际使用频率相对较低。

初学阶段：

理解即可，不需要重点投入。

5. 消息确认机制

RabbitMQ 的核心问题之一：

Consumer 拿到消息后，如果处理失败怎么办？

于是需要：

ACK。

ACK：

Acknowledgement（确认）

5.1 Consumer ACK

流程：

RabbitMQ
   ↓
发送 Message
   ↓
Consumer
   ↓
业务处理成功
   ↓
ACK
   ↓
RabbitMQ 删除消息

也就是说：

消息并不是 Consumer 一拿到就一定删除。

正确情况下：

业务处理成功
↓
ACK

RabbitMQ 才认为消息成功消费。

5.2 NACK / Reject

如果消费失败：

NACK

即：

Negative Acknowledgement（否定确认）

或者：

Reject

消费者可以告诉 RabbitMQ：

消息处理失败

然后决定：

重新入队

或者：

不重新入队

5.3 自动确认与手动确认

Auto ACK：

Automatic Acknowledgement（自动确认）

消费者一收到消息，就认为成功。

风险：

Consumer 收到消息
↓
RabbitMQ 删除消息
↓
Consumer 处理过程中崩溃
↓
消息丢失

因此重要业务一般推荐：

Manual ACK

即：

Manual Acknowledgement（手动确认）

流程：

收到消息
↓
处理业务
↓
成功
↓
ACK

失败：

NACK / Reject

6. 消息持久化

RabbitMQ 重启时，如何尽量避免数据丢失？

需要注意两部分：

Queue 持久化
+
Message 持久化

6.1 Durable Queue

Durable：

Durable（持久化）

Queue 创建时：

durable = true

表示：

RabbitMQ 重启后 Queue 仍然存在

6.2 Persistent Message

Persistent Message：

Persistent Message（持久化消息）

Producer 发送消息时指定：

delivery_mode = persistent

意味着：

消息应该进行持久化

注意：

Queue 持久化，不等于消息一定持久化。

因此重要业务通常要：

Durable Queue
+
Persistent Message

7. Publisher Confirm 生产者确认

Consumer ACK 解决：

Consumer 有没有成功处理消息

但还有一个问题：

Producer 发出的消息
RabbitMQ 到底有没有收到？

这就需要：

Publisher Confirm。

Publisher Confirm：

Publisher Confirm（生产者发布确认）

流程：

Producer
   ↓
RabbitMQ
   ↓
收到并处理消息
   ↓
ACK
   ↓
Producer

如果失败：

NACK

Producer 可以：

记录日志
重试
告警
补偿

7.1 RabbitMQ 可靠性链路

完整可靠消息链路：

Producer
   ↓
Publisher Confirm
   ↓
Exchange
   ↓
Queue
   ↓
Durable + Persistent
   ↓
Consumer
   ↓
Manual ACK

建议直接记住。

8. 消息消费失败与重试

例如订单消息：

order.created

Consumer 调数据库时：

数据库临时不可用

如果直接：

NACK
+
requeue=true

可能出现：

消费
↓
失败
↓
重新入队
↓
马上又消费
↓
失败
↓
重新入队

形成：

Infinite Retry（无限重试）

这会导致：

CPU 升高
日志爆炸
RabbitMQ 压力增大
业务一直无法恢复

所以不推荐无限重新入队。

8.1 更合理的重试方式

例如：

第 1 次失败
↓
等待 10 秒

第 2 次失败
↓
等待 30 秒

第 3 次失败
↓
等待 5 分钟

仍然失败
↓
Dead Letter Queue

也就是：

有限次数重试
+
延迟
+
最终进入死信队列

9. Dead Letter Queue 死信队列

DLQ：

Dead Letter Queue（死信队列）

用于保存：

无法正常处理的消息

9.1 什么消息会变成死信

常见情况：

Consumer 拒绝消息

Reject / NACK
+
requeue=false

消息 TTL 过期

Message TTL 到期

Queue 超过限制

例如：

Queue max-length

超过队列最大长度。

9.2 死信流程

例如：

order.queue
   ↓
消费失败
   ↓
Dead Letter Exchange
   ↓
order.dlq

其中：

DLX：

Dead Letter Exchange（死信交换机）

DLQ：

Dead Letter Queue（死信队列）

9.3 为什么死信队列重要

如果失败消息直接丢弃：

订单
支付
退款
通知

可能造成业务问题。

进入 DLQ 后：

可以人工检查
可以重新消费
可以告警
可以做补偿

10. TTL 与延迟消息

TTL：

Time To Live（存活时间）

表示：

消息或队列中的消息可以存活多久

例如：

30 秒
5 分钟
1 小时

10.1 常见 TTL 场景

例如：

用户下单
↓
30 分钟没有付款
↓
自动取消订单

这就是典型的：

延迟任务

10.2 TTL + DLX 实现延迟队列

一种经典做法：

Producer
   ↓
Delay Queue
设置 TTL = 30分钟
   ↓
消息过期
   ↓
Dead Letter Exchange
   ↓
Order Cancel Queue
   ↓
Consumer
   ↓
取消订单

这是一种常见延迟消息方案。

11. Prefetch 与消费速度控制

Prefetch：

Prefetch（预取数量）

表示：

RabbitMQ 一次最多给某个 Consumer 多少条尚未 ACK 的消息。

例如：

prefetch = 1

表示：

Consumer 处理完 1 条
↓
ACK
↓
RabbitMQ 再发送下一条

11.1 为什么 Prefetch 很重要

假设：

Consumer A 很慢
Consumer B 很快

如果 RabbitMQ 一次把大量消息都发给 A：

A 堆积大量未处理消息
B 却空闲

就不合理。

合理使用 Prefetch 可以改善：

Consumer 负载均衡

11.2 如何设置

没有固定值。

取决于：

单条任务耗时
Consumer 数量
CPU
数据库压力
网络 IO

经验：

任务很重

例如：

图片处理
复杂计算
第三方接口

Prefetch 可以较小：

1
5
10

任务很轻

例如：

简单日志
简单状态更新

可以适当增大。

12. RabbitMQ 常见业务场景

12.1 异步发送短信

注册成功
↓
send.sms
↓
RabbitMQ
↓
SmsConsumer
↓
短信平台

12.2 下单异步处理

Order Created
↓
RabbitMQ
├── 扣库存
├── 发通知
├── 赠积分
└── 数据统计

12.3 延迟取消订单

创建订单
↓
发送 30 分钟延迟消息
↓
30 分钟后
↓
检查是否支付
↓
未支付
↓
取消订单

12.4 流量削峰

例如秒杀：

10000 请求
↓
RabbitMQ
↓
Consumer 每秒处理 500
↓
逐渐消费

保护数据库。

12.5 系统解耦

原来：

OrderService
↓
SmsService
↓
PointsService
↓
StatisticsService

变为：

OrderService
↓
RabbitMQ

其他服务独立消费。

13. RabbitMQ 管理与高频操作

RabbitMQ 日常主要关注：

Connections
Channels
Exchanges
Queues
Consumers
Message Rate

13.1 Connection

Connection：

Connection（连接）

应用与 RabbitMQ 建立的 TCP 长连接。

一般：

不应该每发送一条消息都创建一个 Connection。

Connection 创建成本较高。

13.2 Channel

Channel：

Channel（信道）

Channel 是复用 Connection 的轻量级逻辑连接。

结构：

Application
   ↓
Connection
   ├── Channel 1
   ├── Channel 2
   └── Channel 3

Channel 比 Connection 更轻量。

13.3 RabbitMQ Management

RabbitMQ 通常可以开启：

Management Plugin（管理插件）

用于通过 Web 页面查看：

Queue
Exchange
Connection
Consumer
Message
Message Rate
Memory
Node

排错时非常有用。

14. 日常排错

RabbitMQ 出问题时，不要无头绪地查。

建议按照固定顺序。

14.1 第一看：Queue 有没有消息堆积

重点看：

Ready
Unacked
Total

含义：

Ready

等待 Consumer 消费的消息

Unacked

已经发送给 Consumer
但还没有 ACK 的消息

Total

Ready + Unacked

14.2 Ready 一直很高

例如：

Ready = 100000

可能说明：

Consumer 没启动
Consumer 数量不够
Consumer 太慢
下游数据库太慢
接口阻塞

优先检查：

Consumer 数量
Consumer 日志
消费速度

14.3 Unacked 一直很高

例如：

Unacked = 50000

可能说明：

Consumer 已经拿到消息
但一直没有 ACK

原因可能是：

业务处理太慢
代码卡死
外部接口超时
数据库慢 SQL
Prefetch 太大
ACK 漏掉

14.4 Queue 没有消息

Producer 明明说发送成功，但 Queue：

0 messages

排查：

Exchange 是否正确
Routing Key 是否正确
Binding 是否正确
Queue 是否绑定到了 Exchange
Producer 是否真的 Publish 成功
是否开启 Publisher Confirm
消息是否被其他 Consumer 瞬间消费

14.5 Consumer 不消费

检查：

Consumer 是否启动
Queue Name 是否正确
RabbitMQ Connection 是否正常
Channel 是否正常
ACK 是否卡住
Prefetch 是否限制
Consumer 是否抛异常

15. 常见设计错误

错误 1：所有业务都放到一个 Queue

例如：

order.queue

里面同时放：

创建订单
取消订单
退款
支付
发短信
加积分

这样：

耦合太重
消费者复杂
故障影响范围大

更推荐根据业务拆分。

例如：

order.created.queue
order.cancelled.queue
refund.queue
sms.queue
points.queue

错误 2：消费失败无限 requeue

危险：

NACK
requeue=true

无限循环。

应该：

有限重试
+
延迟重试
+
DLQ

错误 3：业务成功之前先 ACK

错误流程：

收到消息
↓
ACK
↓
执行数据库操作
↓
数据库报错

消息已经被 RabbitMQ 删除。

正确：

收到消息
↓
业务执行成功
↓
ACK

错误 4：Consumer 没有幂等

RabbitMQ 在某些异常情况下可能出现：

同一消息被再次投递

因此 Consumer 必须考虑：

Idempotency（幂等性）

例如：

order_id = 10001

第一次：

扣库存成功

如果第二次重复消费：

不能再次扣库存

常见手段：

唯一业务 ID
数据库唯一索引
消费记录表
Redis 去重
业务状态判断

错误 5：认为消息绝对不会丢

消息可靠性需要多个环节一起保证：

Producer Confirm
Queue Durable
Message Persistent
Consumer ACK
Retry
DLQ
Idempotency

不是：

用了 RabbitMQ
=
永不丢消息

16. RabbitMQ 高频知识速查表

场景	重点
发送消息	Producer
路由消息	Exchange
存消息	Queue
Exchange 与 Queue 连接	Binding
控制消息去向	Routing Key
消费消息	Consumer
消费成功确认	ACK
消费失败	NACK / Reject
生产发送确认	Publisher Confirm
队列持久化	Durable
消息持久化	Persistent
失败消息保存	DLQ
死信转发	DLX
消息过期	TTL
延迟消息	TTL + DLX / 延迟插件
控制消费并发	Prefetch
防重复消费	Idempotency

17. 推荐学习路径

不要一开始把 RabbitMQ 所有功能都学完。

按下面顺序学。

第一阶段：先把消息跑通

掌握：

Producer
Queue
Consumer

目标：

能发送一条消息，并被消费者成功消费。

第二阶段：理解完整路由

学习：

Exchange
Binding
Routing Key

重点：

Direct
Fanout
Topic

目标：

能控制一条消息进入指定 Queue。

第三阶段：掌握可靠消费

学习：

Manual ACK
NACK
Reject

目标：

消费成功才 ACK，失败能够正确处理。

第四阶段：掌握消息可靠性

学习：

Durable Queue
Persistent Message
Publisher Confirm

目标：

知道 Producer → RabbitMQ → Consumer 每个环节如何降低消息丢失风险。

第五阶段：掌握异常处理

学习：

Retry
TTL
DLX
DLQ

目标：

消费失败不会无限循环，也不会直接丢弃。

第六阶段：掌握性能控制

学习：

Prefetch
Consumer 数量
Message Rate
Ready
Unacked

目标：

能判断到底是 RabbitMQ 堆积，还是 Consumer 处理能力不足。

第七阶段：做完整业务实战

建议至少完成以下 4 个场景：

实战 1：异步发送通知

Producer
↓
notification.queue
↓
Consumer

学习基础消息发送。

实战 2：订单事件广播

order.created
↓
Fanout / Topic Exchange
├── sms.queue
├── points.queue
└── statistics.queue

学习 Exchange。

实战 3：消费失败重试

业务异常
↓
Retry
↓
DLQ

学习可靠性。

实战 4：30 分钟未付款取消订单

订单创建
↓
延迟消息
↓
30 分钟
↓
检查支付状态
↓
自动取消

学习：

TTL
DLX
DLQ
Consumer 幂等

18. RabbitMQ 日常学习重点总结

RabbitMQ 真正需要重点掌握的不是所有高级功能，而是下面这条主线：

Producer
   ↓
Exchange
   ↓
Routing Key + Binding
   ↓
Queue
   ↓
Consumer
   ↓
ACK

然后补上可靠性：

Publisher Confirm
+
Durable Queue
+
Persistent Message
+
Manual ACK
+
Retry
+
DLQ
+
Idempotency

最后补上性能和排错：

Prefetch
Consumer 数量
Ready
Unacked
Message Rate

如果你能独立解释并处理：

消息为什么没进 Queue
为什么 Queue 一直堆积
为什么 Unacked 很高
Consumer 为什么重复消费
消费失败怎么重试
消息失败后怎么进 DLQ
如何实现延迟订单
如何避免重复扣库存

那么 RabbitMQ 日常项目中最核心的能力基本已经掌握。

🎯 最终知识地图

                         RabbitMQ
                            │
            ┌───────────────┼───────────────┐
            │               │               │
         Producer        Routing         Consumer
            │               │               │
Publisher Confirm       Exchange            ACK
            │           /   |   \            │
            │       Direct Fanout Topic     NACK
            │               │               │
            └──────────── Queue ─────────────┘
                            │
                     Durable Queue
                            │
                   Persistent Message
                            │
               ┌────────────┼────────────┐
               │            │            │
             Retry         TTL          DLQ
               │            │            │
               └────────── DLX ──────────┘
                            │
                         Prefetch
                            │
                       Idempotency
                            │
                         Monitoring
                            │
                    Ready / Unacked

RabbitMQ 可以浓缩为一句话：

RabbitMQ 通过 Producer（生产者）发送消息，由 Exchange（交换机）根据 Routing Key（路由键）和 Binding（绑定关系）将消息路由到 Queue（队列），Consumer（消费者）负责处理消息，再通过 ACK、Publisher Confirm、消息持久化、重试、死信队列和幂等机制保证整个异步消息链路尽可能可靠。

这份可以直接作为你的 RabbitMQ 主学习文档。后续最值得继续拆的不是更多理论，而是这 4 个专题：Exchange 路由模型、ACK/可靠性、死信与重试、延迟订单实战。