消息队列（Message Queue，MQ）是基于异步通信的中间件，核心是在生产者与消费者之间搭建缓冲队列，实现系统解耦、削峰填谷、异步通信，提升架构稳定性与性能。
一、核心架构与角色
- 生产者（Producer）
- 负责生成并发送消息到队列。
- 发送后无需等待消费者处理，直接返回，提升响应速度。
- 队列（Queue）
- 存储消息的容器，常见读写规则为FIFO（先进先出），部分 MQ 支持优先级队列。
- 核心能力：消息暂存、持久化、路由分发。
- 消费者（Consumer）
- 从队列拉取 / 订阅消息并执行业务逻辑。
- 支持集群消费 （多个消费者分摊消息）和广播消费（每条消息发给所有消费者）。
- Broker（服务端）
- MQ 的核心服务节点，负责管理队列、存储消息、处理生产者 / 消费者的连接请求。
二、核心特性与优势
| 特性 / 优势 | 具体说明 |
|---|---|
| 系统解耦 | 生产者和消费者无需感知对方的实现细节，仅面向队列交互；一方升级或故障不影响另一方 |
| 异步通信 | 替代同步接口调用，生产者发完即返回，非核心流程异步执行（如注册后发短信、积分更新） |
| 削峰填谷 | 应对突发流量（如电商秒杀），队列缓存过量请求，消费者按自身能力匀速消费，避免压垮后端 |
| 故障隔离 | 消费者宕机时，消息暂存队列；服务恢复后继续消费，不会丢失数据 |
| 消息可靠投递 | 通过持久化 （存磁盘）、ACK 确认机制（消费者处理完才删除消息）保障消息不丢失 |
三、关键概念
- 消息持久化
- 把消息从内存写入磁盘，即使 MQ 服务重启，消息也不会丢失，是保障可靠性的核心手段。
- ACK（消息确认）
- 消费者处理完消息后，向 Broker 发送确认信号，Broker 才会删除该消息；若未收到 ACK，会重试投递。
- 死信队列（DLQ）
- 处理失败的消息（如重试多次仍失败、消息超时）会被转移到死信队列，方便后续排查问题，避免阻塞正常队列。
- 消息重试与幂等性
- 重试：消息投递失败时，MQ 会自动重试；需设置重试次数上限，防止无限循环。
- 幂等性：消费者需保证重复消费同一条消息的结果与消费一次一致（如基于唯一 ID 去重）。
- 消息路由模式
- 直连模式：消息按指定队列投递。
- 主题模式（Topic）：按消息主题分类，消费者订阅感兴趣的主题，实现一对多分发。
- 扇形模式：一条消息广播给所有消费者。
四、主流 MQ 产品对比
| 产品 | 核心特点 | 适用场景 |
|---|---|---|
| RabbitMQ | 基于 AMQP 协议，轻量级，路由灵活，支持多种交换机类型；Erlang 语言开发，并发性能好 | 中小型系统、对路由灵活性要求高的场景（如微服务通信） |
| Kafka | 分布式架构，高吞吐量、高持久化；基于磁盘顺序读写，适合海量数据传输 | 大数据场景、日志收集、实时流处理、高并发削峰 |
| RocketMQ | 阿里开源，支持事务消息、延时消息，可靠性强；兼容 Kafka 协议 | 金融、电商等对可靠性要求高的核心业务 |
| ActiveMQ | 老牌 MQ，支持多协议（OpenWire、AMQP），功能全面但性能略逊 | 传统企业级应用、对性能要求不高的场景 |
五、典型应用场景
- 异步任务处理：用户注册→发送短信 / 邮件、订单支付→异步发货通知。
- 系统间数据同步：订单系统→库存系统、电商订单→财务对账系统的数据流转。
- 流量削峰：秒杀活动、促销活动中，用队列缓存大量下单请求，保护后端数据库。
- 日志与数据采集：业务系统日志发送到 Kafka，由 ELK 等分析系统消费处理。
- 分布式事务：通过事务消息保障跨系统数据一致性（如 RocketMQ 的事务消息功能）。
六、使用注意事项
- 避免过度使用 MQ：简单的同步调用无需引入 MQ，否则增加架构复杂度。
- 关注消息积压问题：需监控队列长度，及时扩容消费者或排查消费瓶颈。
- 必须保证消费者幂等性：防止重复消费导致数据错误。
- 合理设置持久化与重试策略：平衡性能与可靠性。