实际开发：短信分发，第一次进行预处理用三个消息队列分别存储：移动/联通/电信的号码

RocketMQ

MQ概述

MQ ： Message Queue 消息队列，是在消息传输过程中保存消息的容器

1.优势

应用解耦

耦合度：指的是模块或组件之间的依赖程度。耦合度越高，容错越低。
防止消费者/生产者某一方崩了导致整个流程崩溃。

提高系统容错性以及可维护性

异步提速

生产方发完消息，可以继续下一步业务逻辑。

提升用户体验和系统吞吐量

削峰填谷

相当于数据先打到缓存中，然后消费者从缓存中拿数据，而不是直接打到消费者，如果1w/s打到物流系统会崩溃

提高系统稳定性

2.劣势

系统可用性降低

如果MQ崩了，就会对业务造成影响。

如何保障MQ的高可用？

系统复杂度提高
如何保障消息没有被重复消费，如何处理信息丢失，如何保障信息传递的顺序性
一致性问题
A处理完业务通过MQ发给BCD，BC都成功处理，那D处理失败，如何保障消息处理数据的一致性？

RocketMQ 工作原理总结

RocketMQ 主要由以下四个核心组件组成：

1. Producer（消息生产者）

负责发送消息到 Broker。
启动时向 NameServer 获取 Topic 的路由信息。
根据路由选择合适的 Broker 和队列进行发送。
支持普通消息、顺序消息、事务消息、延迟消息等。

2. NameServer（注册中心）

提供轻量级服务注册与发现。
Broker 启动时将自身信息（Topic、IP、端口等）注册到多个 NameServer。
Producer 和 Consumer 从 NameServer 拉取最新路由信息。
是无状态、可水平扩展的集群。

3. Broker（消息中转与存储）

接收来自 Producer 的消息，进行持久化存储。
按 Topic 和 Queue 分类组织消息。
支持主从架构，提升高可用性。
提供消费进度管理、消息拉取服务等。

4. Consumer（消息消费者）

从 NameServer 获取路由并从指定 Broker 拉取消息。
支持集群模式（负载均衡）和广播模式（每个消费者都收到）。
支持 Push 或 Pull 两种消费方式。
消费成功后提交消费进度（Offset）。

消息流动过程（简述）

Broker 启动并向 NameServer 注册。
Producer 启动并向 NameServer 获取路由信息。
Producer 向 Broker 发送消息。
Consumer 向 NameServer 获取路由，并从 Broker 拉取消息。
Consumer 消费消息并提交 Offset。

特性支持

✅ 高吞吐、低延迟
✅ 顺序消息、事务消息、延迟消息
✅ 主从架构支持高可用
✅ 消费进度可控（精确到队列和偏移量）

面试问题

RabbitMQ 常见的使用场景有哪些？

场景说明
解耦系统比如下单成功 → 发短信、发优惠券 → 通过 MQ 异步解耦处理
流量削峰秒杀高并发请求先进入 MQ 排队，后台异步慢慢处理，防止系统崩溃
异步处理比如上传图片后异步生成缩略图，发邮件、日志存储等
可靠通知比如订单状态变更、库存同步等，需要消息必达
延迟/定时任务利用死信队列实现定时取消订单、超时提醒等业务逻辑

什么是死信队列？

死信队列是用于存放“无法被正常消费的消息”的队列。消息变成“死信”后会被路由到指定的死信交换机，再进入死信队列中，供后续处理或监控。
下单后 15 分钟未支付 → 将消息发送到一个设置了 TTL 的普通队列，TTL 到期后消息变成死信 → 转发到死信队列 → 消费者监听死信队列做“自动取消订单”处理。
死信队列用于接收处理失败或过期的消息，避免消息丢失。在实际项目中我用它实现延迟任务，比如用户下单后15分钟未支付，通过设置 TTL+死信队列来触发订单关闭逻辑，既解耦了业务流程，也保证了消息可靠性。