01 它是干嘛的
MQ 是企业级消息中间件，负责在两个系统之间可靠地搬运消息。它的价值不在「快」，而在「绝不丢」：消息写入磁盘、支持事务、确认后才删除，即使接收方宕机也能在恢复后继续投递。
02 为什么会有它
以前：两个系统直接调用，一方挂了另一方就懵了
早期系统对接多采用直接调用：A 系统调用 B 系统的接口，等待返回。问题在于 B 一宕机，A 的请求就失败；B 恢复了，那些失败的请求也没人再重试，除非 A 自己记录了它们。
更麻烦的是峰值。A 突然涌入十倍流量，B 处理不过来直接被压垮，故障沿调用链扩散，这就是常说的雪崩。
消息队列的思路是在中间放一个可靠的缓冲区：A 把消息交给队列就算完成，队列负责持久化并保证送达；B 按自己的节奏来取。两边解耦，峰值被削平，故障不再直接传导。
03 它怎么工作
消息先持久化落盘，消费者取走并明确确认后才会被删除；未确认的消息会重新投递。
一条消息的不丢之旅
- 1① 生产者发送
发送方把消息写入队列，队列落盘后返回确认，发送方才算成功。
- 2② 持久化
消息写入持久化存储并记日志，进程崩溃也不丢失。
- 3③ 消费者拉取
接收方按自身处理能力取消息，处理速度与发送速度解耦。
- 4④ 确认与删除
处理成功后显式确认，队列才删除；未确认则会重新投递。
- 5⑤ 重试与死信
反复失败的消息进入死信队列，避免堵塞正常消息，同时保留现场供排查。
04 谁在用它
银行与支付清算
一笔交易指令绝不能丢也不能重复执行。
跨系统异构集成
老系统与新系统通过消息解耦对接。
削峰填谷
大促时先把请求堆在队列里，后端按能力消费。
需要严格顺序的场景
同一账户的操作必须按序处理。
05 怎么用
关键是设计好「确认时机」与「重复消费如何处理」。
- 01明确消息是否必须严格有序，有序会显著限制并发。
- 02决定确认时机：处理前确认可能丢，处理后确认可能重复。
- 03让消费逻辑幂等，重复处理不会造成错误结果。
- 04配置死信队列并定期查看，那是故障的第一现场。
避坑提示
- !幂等是消息系统的生命线，靠它兜住「至少一次投递」带来的重复。
- !队列堆积是预警信号，说明消费能力已经跟不上。
06 关键概念
- 解耦
- 发送方与接收方不直接依赖，一方故障不立刻拖垮另一方。
- 削峰
- 用队列吸收突发流量，后端按自身节奏消费。
- 幂等
- 同一条消息处理多次结果一致，是重复投递的必要防线。
- 死信队列
- 存放反复处理失败的消息，避免拖住整个队列。
07 容易混淆的对比
Kafka吞吐极高、偏向日志流与回放，但单条消息的可靠确认语义不如 MQ 严格。
RabbitMQ轻量灵活、路由能力强，适合互联网业务；金融级持久化与事务支持弱于 MQ。