1. 消息队列概述
消息队列（Message Queue，MQ）是分布式系统中用于实现异步通信的基础中间件。它通过“生产者-队列-消费者”模型，将消息的发送与接收解耦，使系统各组件能够独立演进与扩展。
1.1 消息队列的定义
消息队列是一种先进先出（FIFO）的数据结构，用于在分布式节点之间传递数据。生产者将消息发送到队列，消费者从队列中拉取或由队列推送消息进行处理。消息本身可以是文本、JSON、二进制数据等任意格式。
1.2 核心作用
消息队列在架构设计中主要解决三大问题：解耦、异步、削峰。下表对比了引入 MQ 前后的差异：
| 维度 | 无 MQ 的同步调用 | 引入 MQ 后的异步模式 |
|---|---|---|
| 耦合度 | 服务间直接 HTTP/RPC 调用，接口变更需联动修改 | 生产者只关心消息格式，消费者独立部署，接口解耦 |
| 响应时间 | 需等待下游所有服务处理完毕，延迟累加 | 生产者写入队列即返回，消费者异步处理，响应更快 |
| 流量控制 | 突发流量直接压垮下游数据库或服务 | 队列缓冲流量，消费者按自身能力拉取，防止过载 |
| 可用性 | 下游服务宕机导致上游调用失败 | 消息持久化在队列中，下游恢复后可继续消费 |
解耦（Decoupling）
生产者和消费者不直接依赖对方的存在。例如订单服务只需将“订单创建”消息写入队列，库存、物流、通知等消费者各自订阅处理。新增一个消费者时，无需修改订单服务代码。
异步（Asynchronous）
耗时操作（如发送邮件、生成报表）通过 MQ 异步执行，主流程立即返回。用户注册后，系统先返回“注册成功”，后台再异步发送欢迎邮件，用户体验显著提升。
削峰（Peak Clipping）
秒杀、大促等场景下，瞬时请求量远超系统处理能力。MQ 将请求暂存在队列中，后端服务以恒定速率消费，避免数据库被击穿。例如每秒 10 万请求通过队列缓冲，数据库只需处理每秒 2000 条。
1.3 消息队列架构示意
下图展示了消息队列在分布式系统中的典型位置与数据流向：
1.4 常见应用场景
消息队列在微服务、大数据、物联网等领域均有广泛应用。以下列出三种典型场景：
任务调度
将耗时任务（如视频转码、批量数据导出、报表生成）封装为消息发送到队列，由专用 Worker 集群异步执行。调度系统只需管理队列状态，无需关心 Worker 实例的启停。
- 延迟队列：支持定时任务，如“下单后 30 分钟未支付则取消订单”。
- 重试机制：消费失败的消息自动进入重试队列，避免丢失。
- 优先级队列：紧急任务优先消费，保证 SLA。
日志收集
分布式系统中，各服务将日志消息发送到统一的消息队列，由日志采集器（如 Logstash、Fluentd）集中消费并写入 Elasticsearch 或对象存储。这种模式避免了日志直接写入磁盘导致的 I/O 竞争。
- 高吞吐：Kafka 等 MQ 可支撑每秒百万级日志写入。
- 分区有序：同一业务 ID 的日志按分区顺序存储，便于排查。
- 多消费者：同一份日志可同时被实时监控系统和离线分析系统消费。
事件驱动
微服务架构中，服务间通过事件（Event）进行通信。例如用户注册后，订单服务、积分服务、消息服务各自订阅“user.created”事件，执行对应逻辑。事件驱动架构天然支持服务解耦和弹性伸缩。
1.5 主流消息队列对比
下表从关键维度对比 RabbitMQ、Kafka、RocketMQ 三款主流产品：
| 特性 | RabbitMQ | Kafka | RocketMQ |
|---|---|---|---|
| 协议 | AMQP 0-9-1 | 自定义 TCP 协议 | 自定义 TCP 协议 |
| 吞吐量 | 万级/秒 | 百万级/秒 | 十万级/秒 |
| 消息顺序 | 单队列有序 | 分区内有序 | 分区内有序 |
| 延迟 | 微秒级 | 毫秒级 | 毫秒级 |
| 典型场景 | 任务调度、微服务通信 | 日志收集、流处理 | 交易消息、削峰填谷 |