RabbitMQ 面试的重心不在「什么是 AMQP」，而在三件事：Exchange 四种类型怎么路由、消息从生产到消费哪一段会丢、高可用方案怎么选。本文按模型路由、可靠性、高级特性、高可用四条线逐题拆到机制层。

考察地图

  • 模型与路由：整体模型、四种交换机的路由规则与场景。这是 RabbitMQ 区别于其他 MQ 的核心。
  • 可靠性投递：生产者确认、持久化、消费 ack 三段防线。考察能否把「不丢消息」拆成可配置的工程动作。
  • 高级特性：死信队列、TTL、延迟队列。考察对消息生命周期的完整理解。
  • 高可用：普通集群、镜像队列、Quorum Queue 的演进与取舍。注意镜像队列已在 4.0 移除。
  • 建议自行查阅：五种工作模式代码示例、优先级队列参数、Streams 适用边界——偏 API 记忆，掌握主机制后看文档即可。

模型与路由

RabbitMQ 的整体模型是什么样的？

结论：生产者不直接发消息到队列，而是发给 Exchange（交换机），Exchange 按绑定（Binding）规则把消息路由到一个或多个 Queue，消费者从 Queue 取消息。Exchange 管路由，Queue 管存储，二者通过 BindingKey 与 RoutingKey 的匹配关系连接。

原理：这套模型来自 AMQP 0-9-1。消息由消息体和消息头组成，头里的 routing-key 是路由依据；Exchange 与 Queue 多对多，一个绑定就是一条路由规则。路由不到任何队列时，消息可能退回生产者（设了 mandatory）、转入备用交换器（Alternate Exchange）或直接丢弃，取决于发布参数与配置。另外，预声明的默认交换机（空字符串名的 direct 类型）兜住了省略交换机的发送。

延伸：与 Kafka 对比能看清设计取向：Kafka 把消息存在分区日志里，队列只是位点逻辑；RabbitMQ 把消息实体存在 Queue 中，确认后即删除（Streams 除外）——前者为吞吐与回放优化，后者为路由灵活性优化。传输层上 Channel 复用 TCP 连接降低握手开销，但 Channel 非线程安全，多线程要各用各的。

追问：RabbitMQ 为什么不支持队列内广播消费？提示：队列语义是「一条消息被一个消费者处理」，要广播就给每个消费者建独立队列绑定到同一 fanout/topic 交换机——路由的灵活性替代了队列的广播。

四种交换机类型有什么区别？各自适合什么场景？

结论：fanout 忽略路由键广播到所有绑定队列；direct 要求 RoutingKey 与 BindingKey 完全相等；topic 按 . 分段做通配符匹配；headers 按消息头属性匹配，性能差、很少用。

原理：fanout 最简单，收到消息就投给全部绑定队列，适合配置刷新、缓存失效这类全员通告。direct 做精确匹配，按业务类型或日志级别分流。topic 是重点：RoutingKey 形如 order.china.beijing，BindingKey 支持两个通配符——* 匹配恰好一个词，# 匹配零个或多个词，所以 order.china.* 匹配 order.china.beijing 但不匹配 order.china.beijing.created，order.# 则通吃。headers 忽略 RoutingKey 改按消息头键值对匹配，支持 x-match=all/any，因性能与可维护性问题，能用 topic 表达就不用它。

延伸：topic 的灵活带来一个运维要点：通配符规则设计要前瞻，绑了 order.# 的队列会收到未来新增的所有 order 子类型消息，新增路由键时容易意外「串消息」。路由不到的消息也要提前规划——重要业务配 Alternate Exchange 兜底，而不是默认丢弃。

追问：*.error.# 这样的 BindingKey 合法吗？提示：合法，* 和 # 可以出现在任意位置组合使用；但要现场推演几个 RoutingKey 的匹配结果，面试官常在这里埋细节。

可靠性投递

如何保证消息从生产者可靠投递到 Broker？

结论：用 Publisher Confirms 确认「Broker 收到了」，用 mandatory + Return Listener（或 Alternate Exchange）兜底「路由到队列了」。两个机制缺一不可，且 Confirm 与事务机制互斥。

原理：Publisher Confirms 是异步确认：开启 confirmSelect() 后，Broker 处理完回 ack，持久化消息等落盘、Quorum Queue 等多数副本接受后才确认；失败回 nack，生产者据此重试。关键陷阱：消息到了 Exchange 但没匹配到任何队列时，Broker 照样回 ack——从它的视角「处理完了」。路由失败要靠第二道防线：mandatory=true 让无法路由的消息经 Return Listener 退回，或声明 Alternate Exchange 兜底。事务机制（tx）也能保投递，但同步阻塞、吞吐差一个量级，且与 Confirm 互斥，基本不用。

延伸：逐条同步等 Confirm 会把吞吐拖垮，正确姿势是异步回调或批量确认——注意 multiple ack 语义是「该序号及以下全部确认」，失败重发时小心误重发已成功部分。应用宕机时未确认的消息需本地留痕（如本地消息表），靠定时对账补偿。

追问：只开 Publisher Confirms，消息还可能在哪丢？提示：路由失败静默丢弃（缺 mandatory/AE）；Broker 收到但还没持久化就宕机（缺 durable + delivery_mode=2）——引出下一段防线。

只设置消息持久化，为什么消息还是会丢？

结论：持久化三件套（durable 队列 + durable Exchange + delivery_mode=2）只覆盖「Broker 存储期间」这一段；生产者没等 Confirm、消费者用自动 ack，前后两段照样丢。可靠性是三段防线，缺任何一段都不完整。

原理：把链路拆开看。第一段生产者到 Broker：靠 Confirm + Return，见上题。第二段 Broker 存储：durable 保证队列与交换机元数据重启后存活，delivery_mode=2 让消息写盘；但写盘是异步的，落盘完成前宕机仍可能丢——所以 Confirm 的 ack 时机要等持久化完成，两段防线在此咬合。第三段 Broker 到消费者：自动 ack 下消息一出队列即视为成功，消费者宕机就丢了；必须改手动 ack，处理成功后再 basicAck，失败用 basicNack/basicReject 按异常类型决定是否 requeue。

延伸：第三段还有两个细节：prefetch_count 限制消费者本地未确认消息数，防止消息全堆在一个消费者的 Unacked 状态里（其他消费者干等，宕机还要全部重投）；重试要设上限，超限进死信队列而不是无限 requeue。最后，消费端幂等是底线——手动 ack 防丢不防重。

追问：basicNack(requeue=true) 无限重试有什么风险？提示：坏消息反复入队形成死循环，刷爆消费端 CPU 与 Broker IO；正确做法是限定重试次数后拒绝并入死信队列。

高级特性

死信队列是什么？消息在什么情况下会变成死信？

结论：死信队列是绑定到「死信交换机（DLX）」的普通队列，收容无法正常消费的消息。消息变死信有四种情形：被 reject/nack 且 requeue=false、TTL 过期、队列超长被挤出、Quorum Queue 中投递次数超过 delivery-limit。

原理：机制本身是一次「转投」：队列声明时通过 x-dead-letter-exchange 指定 DLX，消息死亡时 Broker 用原路由键（或 x-dead-letter-routing-key 指定的键）重新发布到 DLX，再进入绑定的死信队列。之后由专门消费者或人工处理——排查原因、修复后重投或告警归档。本质是给消费失败兜底，避免坏消息无限阻塞正常流量。

延伸：三个易错点：死信队列只是普通队列，不消费照样积压，必须配监控；消息进入死信时原始属性（TTL、header）可能已变化，重投前要评估是否恢复上下文；TTL 过期导致的死信有队头阻塞特性——队头消息没过期，后面已过期消息的转投会被延迟，这直接引出 TTL 的设计问题。

追问：业务上用死信队列做「延迟重试」（失败后死信转一圈再回来）靠谱吗？提示：可行但要控制圈数和间隔，无界循环重试等于死循环；更规范的做法是重试次数计数 + 超限告警。

RabbitMQ 的 TTL 有哪两种设置方式？有什么区别？

结论：TTL 可设在队列上（x-message-ttl，全队统一过期时间）或单条消息上（发布时的 expiration 属性）。两者同时存在取较小值；行为差异的关键是：队列级过期即移除，消息级要等轮到队头才被判定过期。

原理：队列级 TTL 由 Broker 统一判定，过期消息可被及时剔除或转入死信。消息级 TTL 则不同——Broker 为避免逐条扫描，只在消息到达队头即将投递时才检查它自己的 expiration；一条 TTL 很长的消息堵在队头，后面早已过期的消息也不会被处理。这就是「队头阻塞」，也是 TTL + DLX 延迟方案延迟不准的根因。

延伸：实践建议因此很明确：做延迟或过期控制优先用队列级 TTL，同一过期时间的消息放同一队列；每种延迟建一组队列虽然笨但行为可预期。消息级 TTL 只适合单条特殊化的补充场景。另外 TTL 到期且未配 DLX 时消息直接被丢弃，要有补偿预案（如从数据库重导）。

追问：TTL=0 表示什么？提示：消息若不能立即投递给消费者就过期——不是「永不过期」，常被用来实现「尽力即时投递」语义。

RabbitMQ 怎么实现延迟队列？

结论：RabbitMQ 没有原生延迟队列，两种常规实现：TTL + DLX 组合（消息先在「延迟队列」里过期，再经死信转投真实队列），或官方插件 rabbitmq-delayed-message-exchange（x-delayed-message 交换机按消息头的延迟时长转发）。前者无需插件但受队头阻塞影响，后者灵活但有规模上限。

原理：TTL + DLX 把「延迟」翻译成「过期」：建一个不消费的队列设好 TTL（如 30 分钟），绑死信到真正的业务队列，过期即被转投，变相实现延迟消费。缺点前面提过——不同延迟要建多组队列，消息级 TTL 的队头阻塞会让实际延迟偏长。插件方案把延迟判断挪到交换机层：消息到达后先暂存（Mnesia/ETS），到点才路由，单条消息可带各自延迟，不必为每种延迟建队列。

延伸：插件方案的边界要答得出来：官方定位是秒到小时级、最多一两天的延迟；内部用 ETS 表存储，堆积十万、百万级延迟消息或要求跨周调度时，应改用数据库/时间轮等外部调度系统到点再发 MQ。典型场景（订单超时关闭、支付重查）常被要求现场设计，两种方案加边界各说一遍就是完整答案。

追问：延迟消息到期后没有准时投递，排查方向有哪些？提示：TTL 方案查队头阻塞与队列级/消息级混用；插件方案查节点重启后的延迟表恢复与堆积规模。

高可用

镜像队列是什么？为什么被 Quorum Queue 取代？

结论：镜像队列是 RabbitMQ 3.x 的高可用方案：队列数据完整复制到多个节点，主节点宕机时最老镜像升主。它因同步模型老旧、脑裂恢复容易丢数据而在 3.8 被 Quorum Queue（基于 Raft）取代，4.0 已彻底移除，新项目一律用 Quorum Queue。

原理：镜像队列通过策略把队列声明为镜像，写消息时主节点同步到所有镜像。问题出在一致性模型上：镜像同步以异步为主，主宕机时镜像可能落后，升主即丢消息；分区恢复后旧主重新加入要全量同步，耗时长且期间队列不可用，还有脑裂双主写入的坑。Quorum Queue 改用 Raft：写入需多数副本（N/2+1）确认才返回成功，选主有明确任期与日志对齐，语义清晰得多。声明方式是队列参数加 x-queue-type=quorum，类型只能在声明时确定，不能从 classic 后期转换。

延伸：Quorum Queue 也不是万能的——复制成本决定它不适合临时队列、高频建删、大规模 fanout 和超大积压场景，那些该用 Classic Queue 或 Streams。答高可用题别忘了分层：集群本身只同步元数据和连接，队列数据是否复制取决于队列类型，「搭了集群」不等于「消息高可用」。网络分区下建议配 pause_minority 让少数派停写，防止双主各自累积数据。

追问：Quorum Queue 在 3 节点集群里挂掉 2 台还能写吗？提示：不能——Raft 多数派原则，剩 1 台构不成 quorum，分区进入只读/不可用状态，这与镜像队列「任一节点存活即可服务」的行为差异是常见考点。

小结

  • 路由是 RabbitMQ 的灵魂：fanout 广播、direct 精确、topic 通配（* 一词、# 多词）、headers 慎用。
  • 可靠性是三段防线：Confirm + mandatory 保投递，durable + 持久化消息保存储，手动 ack + prefetch 保消费，幂等兜底。
  • 死信四来源（拒绝、TTL、队满、delivery-limit）；TTL 队列级与消息级行为不同，队头阻塞是延迟队列不精准的原因。
  • 镜像队列已成历史，高可用的现代答案是 Quorum Queue（Raft 多数派），但要按队列特征选择，集群 ≠ 消息已复制。