消息队列高可用
校招考察频度：☆ 中频（分布式系统设计·中间件高可用） 生产导向主线：MQ 作为分布式架构的“蓄水池”，一旦 Broker 宕机，整个异步链路将瞬间瘫痪。面试核心：RabbitMQ 集群高可用演进（传统镜像队列脑裂痛点 vs 现代 Quorum 队列 Raft 多数派机制）、消费重试与死信队列（DLQ）隔离、以及生产到消费的全链路消息防丢闭环。
一、RabbitMQ Quorum 仲裁队列与高可用
RabbitMQ Quorum 队列: 基于 Raft 共识协议的高可用架构
- 传统镜像队列（Mirrored Queue）痛点：主从全量复制，网络开销大，跨机架网络抖动容易发生脑裂（Split-Brain）（官方在 4.0 彻底废弃）。
- 现代 Quorum 队列（推荐标配）：底层基于 Raft 分布式共识协议，配置 3 或 5 个奇数副本。
- 多数派写入原则（Quorum）：只有多数派（如 3 节点中的 2 节点，即 ）成功将日志写入磁盘并确认后，Broker 才向生产者返回 Confirm ACK。
- 天然防脑裂：网络分区时，少数派分区自动拒绝写入，只有多数派分区能合法选主提供服务，彻底杜绝数据双写错乱。
二、消费重试与死信队列（DLQ）
重试耗尽进死信: 隔离异常数据，保障主队列畅通
| 机制 | 生产作用 | 关键配置与注意点 |
|---|---|---|
| 重试队列 | 消费偶发失败时延迟重投，采用指数退避（如 1s, 5s, 30s）。 | 重试必须有最大上限（如 3~5 次），严禁无限重试把队列堵死！ |
| 死信队列（DLQ） | 重试达到上限依然失败的消息，自动转入 DLQ 隔离。 | 防止坏消息堵塞正常业务流程，保护正常消息顺畅处理。 |
| 死信监控 | 监控死信队列堆积情况，触发告警。 | DLQ 中出现积压往往意味着有系统性 Bug 或下游接口挂掉，需立即排查。 |
| 消费幂等 | 消息重投必然会产生重复消费。 | 消费端必须基于唯一业务键（如订单号）实现幂等性（见重试与幂等篇）。 |
三、消息不丢的全链路四大关卡
- 生产端：开启
Publisher Confirm确认监听，配合mandatory = true与 Return 机制，确保消息安全进入 Broker 并成功路由。 - 存储端：Exchange 持久化 + Queue 持久化（
durable=true） + 消息持久化（delivery_mode=2），集群部署使用 Quorum 队列（Raft 多数派落盘）。 - 消费端：关闭
autoAck，业务执行落库成功后手动调用basicAck。 - 异常兜底：不可恢复坏数据拒绝入死信队列，定期扫死信表人工或离线补偿。
面试高频追问
- RabbitMQ 如何防脑裂？ 使用基于 Raft 算法的 Quorum 队列。网络分区时只有占据多数派节点的子集群才能选出 Leader 提供写服务，少数派自动拒绝写入，彻底消除了脑裂可能。
- 死信队列用来解决什么问题？ 解决“毒药消息（Poison Message）”问题。当某条坏消息引发代码 NPE 或业务错误时，将其从主队列隔离转入死信队列，防止因为反复重试导致主队列完全堵死。
- 消息重复消费怎么破？ 消息中间件只能保证 At-Least-Once（至少一次投递）。消费端必须做幂等设计：数据库唯一主键、状态机版本号更新、或基于 Redis 的全局 MessageId 检查。