消息队列知识体系概览
什么是消息队列？
消息队列（Message Queue, MQ） 是一种异步通信中间件——生产者将消息发送到队列中，消费者从队列中取出消息进行处理。生产者和消费者不需要同时在线，也不需要知道彼此的存在。
用一个现实世界的类比：消息队列就像快递柜——寄件人（生产者）把包裹放进快递柜（队列），收件人（消费者）有空时再去取。寄件人不需要等收件人回家，收件人也不需要在门口等快递员。
消息队列的三大作用
| 作用 | 前（不用 MQ） | 后（使用 MQ） |
|---|---|---|
| 异步 | 注册 → 写库 → 发短信 → 发邮件（串行 1500ms） | 注册 → 写库（50ms），短信/邮件异步处理 |
| 解耦 | 订单服务直接调用库存/物流/积分服务 | 订单服务只发消息，下游服务各自订阅 |
| 削峰 | 秒杀 10 万 QPS 直接打爆数据库 | MQ 缓冲，消费者按 1000 QPS 消费 |
主流消息队列对比
| 特性 | Kafka | RocketMQ | RabbitMQ |
|---|---|---|---|
| 开发语言 | Scala/Java | Java | Erlang |
| 单机吞吐量 | 百万级 | 十万级 | 万级 |
| 延迟 | 毫秒级 | 毫秒级 | 微秒级 |
| 消息可靠性 | 高 | 极高 | 高 |
| 事务消息 | ❌ | ✅ 支持 | ❌ |
| 延迟消息 | ❌（需额外实现） | ✅ 支持 | ✅ 支持（插件） |
| 适用场景 | 日志、大数据、流处理 | 电商、金融、核心业务 | 中小型系统、复杂路由 |
| 国内使用 | 广泛（大数据场景） | 广泛（阿里系） | 较少 |
Kafka——追求极致吞吐量
Kafka 是 LinkedIn 开源的分布式流处理平台，以超高吞吐量著称。它的核心设计：
- Partition（分区）：Topic 分为多个 Partition，实现并行读写
- ISR（In-Sync Replicas）：只有与 Leader 保持同步的副本才在 ISR 内
- 零拷贝：使用
sendfile系统调用，数据直接从文件传输到网络，减少内核态/用户态切换 - 顺序写磁盘：利用磁盘顺序写的高性能（接近内存的速度）
RocketMQ——国内企业级首选
RocketMQ 是阿里开源的消息中间件，专为高并发、高可靠的业务场景设计，具备 Kafka 不支持的关键特性：
- 事务消息：半消息 + 回查机制，解决分布式事务
- 延迟消息：支持定时/延迟投递
- 消息轨迹：追踪消息的生产和消费记录
- Tag 过滤：消费者可以按 Tag 只消费特定类型的消息
RabbitMQ——功能丰富的"老牌"MQ
RabbitMQ 基于 AMQP 协议，通过 Exchange（交换机） 实现灵活的消息路由：
- Direct：精确匹配 Routing Key
- Topic：通配符匹配（
order.*、order.#） - Fanout：广播给所有绑定队列
消息队列的核心问题
消息可靠性——如何保证"不丢消息"
消息可能在三个环节丢失：
| 环节 | 问题 | 解决方案 |
|---|---|---|
| 生产端 | 发送失败 | 同步发送 + 重试、事务消息 |
| MQ 存储 | MQ 宕机 | 同步刷盘 + 主从同步 |
| 消费端 | 消费完还没处理就 ACK | 处理完才手动 ACK |
消息顺序性——如何保证"有序消费"
全局有序（整个 Topic 有序）代价太大，通常只需要局部有序——同一个订单的消息（创建→支付→发货）发到同一个 Partition/Queue，由同一个消费者顺序消费。
消息幂等性——如何保证"不重复消费"
MQ 通常只保证"至少一次投递"（At Least Once），消费者可能收到重复消息。需要在消费端做幂等处理：唯一 ID + 去重表、数据库唯一约束、Redis SETNX。
学习建议
推荐学习路径
- MQ 核心概念 → 异步、解耦、削峰
- Kafka 原理 → Partition、ISR、零拷贝（大数据场景必学）
- RocketMQ 原理 → 事务消息、延迟消息（电商场景必学）
- 消息可靠性 → 生产端 + 存储端 + 消费端全链路保障
- 消息顺序性 + 幂等性 → 分布式系统核心问题
- MQ 选型 → 根据场景选择合适的 MQ