为什么需要消息队列？

【核心定义】

消息队列是一种异步通信的中间件系统，通过解耦、削峰、异步三大核心能力解决分布式系统中的协作问题。

系统解耦
- 结论：消除系统间的直接依赖
- 原理：生产者只需将消息发送到队列，消费者按需订阅，系统间通过消息协议而非API直接调用，任一系统变更不影响其他系统
异步处理
- 结论：将耗时操作异步化，提升响应速度
- 原理：主流程将非核心操作（如日志记录、短信通知）放入队列后立即返回，后台消费者异步处理，避免用户长时间等待
流量削峰
- 结论：平滑突发流量，保护下游系统
- 原理：当请求量突增时，消息队列作为缓冲区暂存请求，消费者按处理能力匀速消费，避免系统被瞬间流量击垮
数据持久化与可靠性
- 结论：确保消息不丢失，支持重试机制
- 原理：消息持久化到磁盘，配合ACK机制和死信队列，即使消费者故障也能保证消息最终被处理
顺序保证与流量分发
- 结论：支持顺序消费和负载均衡
- 原理：通过分区（Partition）保证局部顺序，多个消费者实例可并行消费不同分区的消息，实现水平扩展

无消息队列的同步调用问题：

用户下单 → 扣库存 → 写订单库 → 发短信 → 记日志 → 返回结果

引入消息队列后的异步优化：

用户下单 → [扣库存 + 写订单库]（同步，核心）→ 返回结果
                    ↓
              [发短信、记日志]（异步，入队列）

假设系统：

无队列场景：

瞬间5000 QPS涌入 → 系统过载 → 拒绝服务/崩溃

有队列场景：

5000 QPS → 队列缓冲（每秒入队5000条）
消费者以1000 QPS匀速消费
峰值期间队列堆积：(5000-1000)×10 = 40000条
但系统保持稳定运行，流量过后逐步消化堆积

消息队列如何保证消息不丢失？
- 生产者端：开启confirm机制，等待Broker确认
- Broker端：消息持久化（磁盘写入）+ 集群复制
- 消费者端：手动ACK，处理完成后再确认
消息重复消费怎么办？
- 业务层做幂等设计（如唯一ID+状态机）
- 利用数据库唯一约束
- 分布式锁控制关键操作
Kafka和RabbitMQ如何选型？
- Kafka：高吞吐、日志场景、顺序保证、持久化存储
- RabbitMQ：复杂路由、低延迟、事务消息、企业级特性
- 选择依据：吞吐量优先选Kafka，功能丰富选RabbitMQ
消息积压如何处理？
- 紧急扩容消费者实例
- 排查消费者处理逻辑（是否存在性能瓶颈）
- 必要时进行消息降级或批量处理优化
为什么说消息队列是“异步”的，但有些场景也支持同步？
- 核心设计是异步解耦，但某些MQ（如RocketMQ）提供同步发送API
- 同步发送会阻塞等待Broker响应，常用于对可靠性要求极高的场景
- 本质是“异步架构中的同步调用选项”

在实际架构设计中，引入消息队列需评估：

核心判断标准：当系统出现耦合过紧、响应慢、怕突发流量三大痛点中的至少两个时，消息队列才是合适的解决方案。