消息队列
校招考察频度：★ 高频（核心必背·企业级消息底座） 复习主线：消息队列是分布式系统的“蓄水池”与系统解耦器。校招技术面核心聚焦点：RabbitMQ 遵循的 AMQP 0-9-1 协议模型（Exchange、Queue、Binding、Channel 信道复用）、生产端确认（Publisher Confirm 与 Return 回退）、消费端 QoS 限流与手动 ACK、全链路消息防丢三大防线、死信队列（DLX）与延迟队列落地、现代基于 Raft 协议的 Quorum 队列、以及生产百万消息堆积的应急治理。
消息队列（Message Queue）是分布式微服务系统异步削峰、流量削峰与服务解耦的中枢神经。本模块以企业级最广泛应用的 RabbitMQ 为主线展开。
分类考频地图
| 专题 | 核心页面 | 校招考频星级 | 重点考查要点 |
|---|---|---|---|
| RabbitMQ 架构 | RabbitMQ 架构与核心模型 | ★ 高频（核心必考） | AMQP 0-9-1 模型、VirtualHost 隔离、TCP 连接与 Channel 信道复用、四大 Exchange（Direct/Fanout/Topic/Headers）匹配规则 |
| 全链路防丢防重 | 消息可靠性保证 | ★ 高频（生死线） | 全链路防丢三大防线（生产 Confirm + Broker 交换机/队列/消息三级持久化 + 消费端手动 ACK）、全局唯一 MessageId 与消费端幂等性 |
| 生产端可靠机制 | 生产端机制与可靠发送 | ★ 高频（核心必考） | 生产端发送确认（Publisher Confirm 单条/批量/异步回调）、不可达路由回退（Return 机制）、备用交换机（Alternate Exchange） |
| 消费端与 QoS | 消费模型与并发机制 | ★ 高频（稳定性防线） | Push（basic.consume）vs Pull（basic.get）、QoS 流量控制与 prefetch_count（能者多劳防爆内存）、自动 vs 手动 ACK/NACK/Reject |
| 死信与延时队列 | 死信队列与延迟队列 | ☆ 中频（场景实战） | 死信交换机（DLX）三大触发场景、TTL+DLX 队头阻塞缺陷剖析、官方延迟插件 rabbitmq-delayed-message-exchange 实战 |
| 存储与高可用集群 | 存储机制与高可用集群 | ☆ 中频（Quorum 高可用） | Erlang Mnesia 元数据、普通集群 vs 镜像队列痛点 vs 现代 Quorum 队列（Raft 共识消除脑裂）、万级吞吐本质分析 |
| 顺序消费与事务 | 顺序消费与分布式事务 | ☆ 中频（事务进阶） | 单队列单消费者保证严格局部有序、一致性哈希交换机分流、RabbitMQ + 本地消息表实现分布式事务最终一致性 |
| 横向选型与排障 | MQ 选型与线上消息堆积排查 | ☆ 中频（实战排障） | RabbitMQ vs Kafka vs RocketMQ 深度权衡对比、线上百万级消息积压应急处置三板斧、Erlang 内存报警排查 |
消息队列的三大核心价值
| 核心价值 | 业务解释 | 生产典型场景 |
|---|---|---|
| 削峰填谷 | 保护下游脆弱服务。将瞬时突发的几万 QPS 峰值流量缓冲在队列中，下游数据库以稳定的 2000 QPS 匀速消费。 | 电商秒杀大促抢购、整点抢红包活动 |
| 解耦服务 | 生产方只需要关心把事件抛出，无需关心下游由谁消费，新增业务线零代码侵入。 | 用户下单成功后，支付系统发消息，库存系统、积分系统、物流系统按需订阅 |
| 异步提速 | 将主链路耗时、非核心的阻塞计算转为后台异步处理，大幅压缩前端用户接口的响应时间（从 500ms 降至 20ms）。 | 注册成功发送激活邮件与欢迎短信、导出大型 Excel 报表 |
AMQP 核心消息模型
RabbitMQ AMQP 0-9-1 核心数据流转模型
- Exchange 决定路线，Queue 真正存货：Exchange 是一个内存分拣器，不存储任何数据；只有被路由到 Queue 的消息才会被真正暂存和持久化。
什么时候不应该引入消息队列？
面试高分反思题：“MQ 是万能的银弹吗？什么时候不建议使用 MQ？”
- 强一致性事务场景：MQ 只能保证“最终一致性”。若业务要求“扣减账户余额与生成凭证必须在同一毫秒内同时成功或同时失败”（强一致 ACID），必须使用本地数据库事务或分布式强一致框架。
- 简单的同步调用请求：前端需要立即获得返回值渲染页面（如查询商品详情、获取当前汇率），强行引入 MQ 会导致同步阻塞，徒增系统复杂度与延迟。
- 系统本身吞吐极小：每日访问量几十万次的中小型系统，直接使用内存队列或数据库操作即可，过早引入分布式 MQ 徒增运维与数据丢失风险。
面试高频追问
- MQ 解决的核心问题是什么？有哪些副作用？
- 解决：削峰、解耦、异步。
- 副作用：系统可用性降低（MQ 宕机全链路瘫痪）、复杂度飙升（需解决消息重复、消息丢失、顺序错乱、消息积压）、分布式一致性问题（生产成功但消费失败）。
- RabbitMQ 和 Kafka 的消息模型有什么本质区别？
- RabbitMQ 是典型的推模型（Push）队列模型，基于 AMQP，消息在消费者确认后从队列删除，适合业务订单事件驱动。
- Kafka 是发布-订阅流模型（Pull 模式），基于日志追加（Commit Log），消息消费后不删除，保留数天供回溯，适合大数据与日志流。