目录
-
- [为什么有 RabbitMQ？](#为什么有 RabbitMQ？)
- Queue
- Exchange（消息分发策略）
- 常见的队列类型
-
- [死信队列 （Dead Letter Queue，DLQ）](#死信队列 （Dead Letter Queue，DLQ）)
- [优先级队列 （Priority Queue）](#优先级队列 （Priority Queue）)
-
- 应用场景
-
- [订单处理（VIP 订单优先）](#订单处理（VIP 订单优先）)
- 异常告警（高危告警优先）
- 物流配送（加急包裹优先）
- 客服工单（紧急问题优先）
- 任务调度（关键任务优先）
- 集群模式
- Reference
为什么有 RabbitMQ？
RabbitMQ 是一个开源消息中间件，主要用于解决分布式系统中的异步通信、系统解耦、流量削峰、消息可靠传递等问题。其核心价值体现在以下场景：
- 解耦系统组件：生产者和消费者无需直接交互，通过消息队列实现异步通信，降低系统依赖。
- 异步处理：将耗时操作（如邮件发送、文件处理）放入队列，提升主流程响应速度。
- 流量削峰：突发流量涌入时，队列作为缓冲区避免系统过载。
- 可靠性保障：支持消息持久化、确认机制，确保消息不丢失。
Queue
"消息队列"就是一个类似于链表的独立进程，链表中的每个节点是一个消息，介于生产者和消费者之间。
- 先进先出 (FIFO)：默认情况下，消息按到达顺序被消费（可设置优先级队列改变顺序）。
但是消息也分类很多中类别，比如用户消息、订单消息、邮件消息等等。
为了更好的管理不同种类的消息，可以创建多个类型的队列，生产者可以自定义 Queue 的名字，并且根据需要，将消息投递到不同的 Queue 中。
每个队列都是独立的进程，某一个"队列进程"挂了，也不会影响其他进程的使用。
Exchange（消息分发策略）
"生产者"想要将不同的消息分发给不同的 Queue（甚至广播给所有的 Queue），就需要可以定义消息路由分发的组件"交换机 （Exchange）"，将 Exchange 和 Queue 通过 Bindingkey 进行绑定。
常见的路由机制如下：
- Direct Exchange ：精确匹配
Routing Key，将消息投递到绑定键完全匹配的队列。 - Topic Exchange ：通配符匹配
Routing Key（如user.*匹配user.create、user.delete。 - Fanout Exchange：广播模式，消息发送到所有绑定队列。
- Headers Exchange：基于消息头而非路由键进行匹配（使用较少）。
Direct
精确匹配 Routing Key，将消息投递到绑定键完全匹配的队列。
Topic
通配符匹配 Routing Key，主要的通配符如下：
- "*"，表示匹配一个或多个单词 ，如
user.*Routing Key=user.create和user.delete.id都能够成功匹配。
- "#" ，表示只匹配一个单词，如
email.#Routing Key=email.add可以成功匹配。email.delete.id则无法匹配，无法将消息发送到指定队列。
Fanout
广播模式，消息发送到所有绑定队列。
Headers
基于消息头而非路由键进行匹配（使用较少）。
常见的队列类型
死信队列 （Dead Letter Queue，DLQ）
"死信队列"是 RabbitMQ 中的一种机制，当消息满足某些条件时（如消息被拒绝 、消息过期 、队列达到最大长度等），消息会被重新路由到一个指定的交换器（Dead Letter Exchange, DLX），进而进入死信队列。
- 消息过期：如果消息设置了过期时间（TTL，Time To Live），并且超过了设定的时间没有被消费，这条消息会被认为是"死信"，并被转发到死信队列中。
- 队列满：如果一个队列已经达到其最大长度，新的消息无法进入队列时，RabbitMQ 会将这些无法进入的消息转发到死信队列。
- 消费者拒绝消息 ：当消费者在处理消息时，如果显式地拒绝消息，并且设置了
requeue=false，这条消息就会被丢弃或转发到死信队列中。 - 队列中的消息被丢弃：如果消息由于某些原因（例如队列被删除或消费者无法处理消息）无法被处理，也可以被转发到死信队列。
应用场景
定时任务
📌 场景：
- RabbitMQ 没有原生延迟队列 ，但可以通过 TTL + 死信队列 实现消息的定时消费。
✅ 应用：
- 订单未支付自动取消（30 分钟后检查是否支付）。
- 会员到期提醒（7 天后发送到期通知）。
- 短信验证码过期（10 分钟后清除）。
监控与告警
📌 场景：
- 死信队列可以作为系统的异常监控点，如果短时间内积累了大量死信消息，可能意味着系统存在异常。
✅ 应用：
- 运维告警：死信消息超出 1000 条，触发运维告警。
- 自动化运维：检测到异常消息后，自动分析并重新投递。
消费者拒绝（NACK/Reject）
📌 场景：
- 消费者在消费消息时，调用
basic.reject()或basic.nack()拒绝消息 ，并且不重新入队（requeue=false）。 - 这类消息被 RabbitMQ 转移到死信队列。
✅ 应用：
- 格式错误的消息：JSON 解析失败、数据字段缺失等。
- 非预期异常：业务逻辑错误，如支付订单状态异常。
- API 调用失败：第三方接口不可用，无法完成任务。
优先级队列 （Priority Queue）
"优先级队列（Priority Queue）"是一种特殊的消息队列，它允许消息按照优先级进行排序，高优先级的消息会被优先消费，而不是严格按照 FIFO（先进先出）顺序处理。
应用场景
订单处理（VIP 订单优先）
📌 场景：
- 在电商系统中，普通用户和 VIP 用户的订单同时进入消息队列。
- VIP 订单应该被优先处理，以提供更好的服务体验。
✅ 解决方案：
- 使用 RabbitMQ 优先级队列 ，设置 VIP 订单的高优先级 ，普通订单的低优先级。
- 消费者会先处理 VIP 订单，再处理普通订单。
🔍 示例：
| 订单类型 | 订单ID | 优先级 |
|---|---|---|
| VIP订单 | 1001 | 9 |
| 普通订单 | 1002 | 2 |
| 普通订单 | 1003 | 1 |
🎯 结果： VIP 订单（优先级 9）会先被处理，普通订单稍后处理。
异常告警（高危告警优先）
📌 场景：
- 监控系统中，有不同级别的告警：严重（Critical）、警告（Warning）、信息（Info）。
- 严重告警 （如服务器宕机）需要立即处理，而一般信息性告警可以稍后处理。
✅ 解决方案：
- 设置严重告警 的优先级最高（如
priority=10）。 - 一般告警 优先级较低（如
priority=1）。 - RabbitMQ 会让消费者先处理最紧急的告警，再处理低优先级的告警。
🔍 示例：
| 告警类型 | 告警ID | 优先级 |
|---|---|---|
| 服务器宕机 | A001 | 10 |
| CPU过载 | A002 | 7 |
| 内存使用过高 | A003 | 5 |
🎯 结果 ： 服务器宕机 告警最先被处理，其次是 CPU过载，最后是 内存使用过高。
物流配送（加急包裹优先）
📌 场景：
- 物流系统中，普通包裹和加急包裹都进入同一消息队列。
- 需要先处理加急配送（如当日达），普通配送可以稍后安排。
✅ 解决方案：
- 加急包裹 设置更高的优先级（
priority=8）。 - 普通包裹 设定较低的优先级（
priority=2）。 - 消费者会优先处理加急包裹，然后才处理普通包裹。
🔍 示例：
| 包裹类型 | 订单ID | 优先级 |
|---|---|---|
| 当日达 | P001 | 8 |
| 普通配送 | P002 | 3 |
| 次日达 | P003 | 5 |
🎯 ** 结果**： 当日达订单 P001 会最先处理，其次是 次日达，最后是普通订单。
客服工单（紧急问题优先）
📌 场景：
- 客服系统中，用户提交的工单类型不同：
- 账户被盗（优先级高）
- 订单查询（优先级中等）
- 一般咨询（优先级低）
- 需要优先处理紧急问题，保证用户体验。
✅ 解决方案：
账户被盗设置最高优先级（priority=10）。订单查询设置中等优先级（priority=5）。一般咨询设置最低优先级（priority=1）。
🔍 示例：
| 工单类型 | 工单ID | 优先级 |
|---|---|---|
| 账户被盗 | T001 | 10 |
| 订单查询 | T002 | 5 |
| 一般咨询 | T003 | 1 |
🎯 ** 结果**： 工单 T001（账户被盗）会最先处理，其次是 T002，最后是 T003。
任务调度（关键任务优先）
📌 场景：
- 定时任务 调度系统中，有的任务是关键业务，有的是普通业务。
- 需要确保关键任务优先执行，普通任务稍后执行。
✅ 解决方案：
财务对账任务优先级最高（priority=10）。日志归档任务优先级最低（priority=1）。数据同步任务优先级适中（priority=5）。
🔍 示例：
| 任务类型 | 任务ID | 优先级 |
|---|---|---|
| 财务对账 | J001 | 10 |
| 数据同步 | J002 | 5 |
| 日志归档 | J003 | 1 |
🎯 结果 ： RabbitMQ 会优先执行 J001（财务对账），然后是 J002（数据同步），最后是 J003（日志归档）。
集群模式
todo...