消息队列：系统间通信的「异步桥梁」
你有没有遇到过这种情况：用户下单后，系统要调用库存服务、物流服务、积分服务、短信服务……每一个调用都要等上一个完成。
一条简单的下单操作，变成了一个「服务大串联」。
这就是同步调用的困境——你的系统，被别人的响应速度绑架了。
消息队列，就是来解决这个问题的。
什么是消息队列？
消息队列（Message Queue，简称 MQ）是一种进程间通信方式。它允许系统之间通过「发消息」的方式进行解耦：
- 发消息的系统叫 Producer（生产者），只管发，不管谁接收
- 收消息的系统叫 Consumer（消费者），想收就收，不用关心谁发的
两者完全不直接打交道，而是通过一个「中间人」——消息队列本身。
同步调用（串行）：
系统A → 系统B（等待）→ 系统C（等待）→ 系统D（等待）→ 返回结果
消息队列（异步）：
系统A → 消息队列 ──→ 系统B
├──→ 系统C
└──→ 系统D这个「中间人」的核心价值是：让快的先走，慢的排队。
核心概念
无论你用的是 Kafka、RabbitMQ 还是 RocketMQ，这些概念都是通用的：
| 概念 | 说明 |
|---|---|
| Producer | 消息的生产者，负责发送消息 |
| Consumer | 消息的消费者，负责接收和处理消息 |
| Broker | 消息队列的服务节点，负责存储和转发消息 |
| Topic | 消息的主题，逻辑上对消息进行分类 |
| Message | 消息本体，包含数据和元数据 |
消息队列能解决什么问题？
1. 异步解耦
将非核心流程从主流程中剥离，减少响应时间。比如下单后，通知系统、物流系统可以异步处理，不用等它们完成才返回。
2. 削峰填谷
在流量高峰期，消息会被缓存起来，等系统有能力处理时再消费。比如秒杀场景，MQ 可以承接百万请求，后端服务平稳处理。
3. 系统解耦
上下游系统不直接依赖，通过消息通信。即使下游服务暂时不可用，消息也不会丢失。
常见问题
消息队列虽然强大，但也有它的问题：
| 问题 | 说明 |
|---|---|
| 消息丢失 | 网络抖动、Broker 宕机可能导致消息丢失 |
| 消息重复 | Consumer 处理失败重试，可能导致重复消费 |
| 消息顺序 | 多分区或多 Consumer 时，可能无法保证顺序 |
| 系统复杂度 | 引入 MQ 后，系统间的关系变得更复杂 |
这些问题的解决方案，在后续的专题文档中会详细讲解。
内容导航
核心基础
核心问题
面试与实践
下一步
如果你想深入了解某个具体的消息队列：
- 高吞吐、日志收集、大数据：推荐从 Kafka 架构 开始
- 灵活路由、复杂业务场景：推荐从 RabbitMQ 核心概念 开始
- 电商交易、事务消息：推荐从 RocketMQ 架构 开始