MQ 选型对比与常见问题
❓ 面试官：RocketMQ、RabbitMQ、Kafka 这三个消息队列有什么区别？你们项目为什么选择 RocketMQ？
频率：🔥🔥🔥🔥
💡 一句话总结（先抛结论）：
- Kafka：吞吐量最高，适合大数据场景（日志收集、流式处理），但功能相对简单。
- RabbitMQ：功能最丰富，支持多种消息模式，但性能一般，适合中小型项目。
- RocketMQ：阿里开源，性能和功能平衡最好，适合电商、金融等对可靠性要求高的业务场景。
📝 详细对比表：
| 特性 | RocketMQ | RabbitMQ | Kafka |
|---|---|---|---|
| 吞吐量 | 10万+ QPS | 几万 QPS | 百万级 QPS |
| 延迟 | 毫秒级 | 微秒级 | 毫秒级 |
| 可靠性 | 极高（支持事务消息） | 高 | 高 |
| 功能丰富度 | 丰富（延迟消息、顺序消息） | 最丰富 | 较简单 |
| 运维复杂度 | 中等 | 简单 | 复杂 |
| 适用场景 | 电商、金融 | 中小型项目 | 大数据、日志 |
🌟 实战选型建议（面试加分项）： "在我们公司的电商项目中，我们选择了 RocketMQ，主要考虑以下几点：
- 事务消息：下单后需要发优惠券、发短信，如果订单失败，这些操作要回滚。RocketMQ 的事务消息机制完美解决了这个问题。
- 顺序消息：订单状态变更（待支付→已支付→已发货）必须按顺序处理，RocketMQ 支持顺序消息。
- 延迟消息：订单超时未支付自动取消，RocketMQ 原生支持延迟消息，不需要自己实现。
- 性能足够：虽然 Kafka 吞吐量更高，但我们的业务量 RocketMQ 完全够用，且功能更贴合业务需求。"
❓ 面试官：MQ 在项目中解决了哪些实际问题？不用 MQ 会有什么问题？
频率：🔥🔥🔥🔥🔥
💡 一句话总结（先抛结论）： MQ 主要解决了系统解耦、异步处理、流量削峰三大问题。不用 MQ 会导致系统耦合严重、接口响应慢、高并发时系统崩溃。
📝 三大核心应用场景：
1. 系统解耦（最常用）：
- 场景：用户下单后，需要扣库存、发短信、发优惠券、记录日志。
- 不用 MQ 的问题：订单服务需要调用库存服务、短信服务、优惠券服务、日志服务。如果某个服务挂了，整个下单流程就失败了。
- 用 MQ 的解决方案：订单服务只负责创建订单，然后把消息发到 MQ。其他服务各自订阅 MQ，异步处理。即使短信服务挂了，也不影响下单。
2. 异步处理（提升用户体验）：
- 场景：用户上传大文件，需要生成缩略图、转码、审核。
- 不用 MQ 的问题：用户要等所有处理完成才能返回，接口响应时间很长（可能几十秒）。
- 用 MQ 的解决方案：接口立刻返回“上传成功，正在处理中...”，后台异步处理，处理完成后推送通知。
3. 流量削峰（抗高并发）：
- 场景：双十一零点，瞬间涌入百万订单请求。
- 不用 MQ 的问题：数据库瞬间被打爆，系统崩溃。
- 用 MQ 的解决方案：所有请求先发到 MQ，MQ 作为缓冲池。后台消费者以数据库能承受的速度（比如每秒 1000 个）慢慢消费，把流量削平。
🌟 面试加分项（常见误区）： "很多同学以为 MQ 能提升性能，其实 MQ 本身也会消耗资源（网络传输、序列化、持久化）。MQ 的核心价值是解耦和削峰，而不是提升单次请求的性能。如果只是简单的同步调用，用 MQ 反而会增加延迟。"