RabbitMQ 快速入门

为什么有 RabbitMQ？

RabbitMQ 是一个开源消息中间件，主要用于解决分布式系统中的异步通信、系统解耦、流量削峰、消息可靠传递等问题。其核心价值体现在以下场景：

1. 解耦系统组件：生产者和消费者无需直接交互，通过消息队列实现异步通信，降低系统依赖。
2. 异步处理：将耗时操作（如邮件发送、文件处理）放入队列，提升主流程响应速度。
3. 流量削峰：突发流量涌入时，队列作为缓冲区避免系统过载。
4. 可靠性保障：支持消息持久化、确认机制，确保消息不丢失。

---

Queue

“消息队列”就是一个类似于链表的独立进程，链表中的每个节点是一个消息，介于生产者和消费者之间。

1. 先进先出 (FIFO)：默认情况下，消息按到达顺序被消费（可设置优先级队列改变顺序）。

但是消息也分类很多中类别，比如用户消息、订单消息、邮件消息等等。

为了更好的管理不同种类的消息，可以创建多个类型的队列，生产者可以自定义 Queue 的名字，并且根据需要，将消息投递到不同的 Queue 中。

每个队列都是独立的进程，某一个“队列进程”挂了，也不会影响其他进程的使用。

---

Exchange（消息分发策略）

“生产者”想要将不同的消息分发给不同的 Queue（甚至广播给所有的 Queue），就需要可以定义消息路由分发的组件“交换机 （Exchange）”，将 Exchange 和 Queue 通过 Bindingkey 进行绑定。

常见的路由机制如下：

1. Direct Exchange：精确匹配 Routing Key，将消息投递到绑定键完全匹配的队列。
2. Topic Exchange：通配符匹配 Routing Key（如 user.* 匹配 user.create、user.delete。
3. Fanout Exchange：广播模式，消息发送到所有绑定队列。
4. Headers Exchange：基于消息头而非路由键进行匹配（使用较少）。

Direct

精确匹配 Routing Key，将消息投递到绑定键完全匹配的队列。

Topic

通配符匹配 Routing Key，主要的通配符如下：

1. “*”，表示匹配一个或多个单词，如 user.*
   1. Routing Key = user.create和user.delete.id都能够成功匹配。
2. “#”，表示只匹配一个单词，如 email.#
   1. Routing Key = email.add可以成功匹配。
   2. email.delete.id则无法匹配，无法将消息发送到指定队列。

Fanout

广播模式，消息发送到所有绑定队列。

Headers

基于消息头而非路由键进行匹配（使用较少）。

---

常见的队列类型

死信队列 （Dead Letter Queue，DLQ）

“死信队列”是 RabbitMQ 中的一种机制，当消息满足某些条件时（如消息被拒绝、消息过期、队列达到最大长度等），消息会被重新路由到一个指定的交换器（Dead Letter Exchange, DLX），进而进入死信队列。

1. 消息过期：如果消息设置了过期时间（TTL，Time To Live），并且超过了设定的时间没有被消费，这条消息会被认为是"死信"，并被转发到死信队列中。
2. 队列满：如果一个队列已经达到其最大长度，新的消息无法进入队列时，RabbitMQ 会将这些无法进入的消息转发到死信队列。
3. 消费者拒绝消息：当消费者在处理消息时，如果显式地拒绝消息，并且设置了requeue=false，这条消息就会被丢弃或转发到死信队列中。
4. 队列中的消息被丢弃：如果消息由于某些原因（例如队列被删除或消费者无法处理消息）无法被处理，也可以被转发到死信队列。

应用场景

定时任务

📌 场景：

• 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…

---

Reference

1. RabbitMQ是什么？架构是怎么样的？
2. Official document