RabbitMQ 的七种工作模式，说白了就是消息从生产者到消费者之间不用的路由和分发策略。我最早被这玩意儿绕晕，是接手公司一个订单通知系统的时候，同事丢过来一张交换机绑定关系图，满屏的箭头和队列名，看了一下午没搞明白为什么同一条消息非要绑这么多队列。后来自己动手装环境、跑 Demo、抓包看消息流转，才把简单模式、Work 队列、发布订阅、路由、主题、RPC、发布确认这七种模式彻底理顺。
这篇文章就把我整理的思路写出来，每个模式包含核心原理、能用在哪、一个可以直接抄的 Spring Boot 案例，以及我在生产环境里踩过哪些坑。不管是面试前突击，还是准备做技术选型，建议从头到尾盘一遍，收获会比零散刷博文大得多。
1. 先搞清楚 RabbitMQ 到底解决什么问题
很多时候不是七种模式难，而是你不清楚它们各自在解决什么问题。RabbitMQ 本质是一个消息中间件，生产者不直接调用消费者，而是把消息丢给 Broker，由 Broker 按规则转发。这层加进来之后，系统就获得了三个核心能力：异步、削峰、解耦。
拿电商下单举例，没有消息队列的时候，创建订单、扣库存、发短信、送积分这些操作全在一个请求里串行执行，接口响应时间很容易到秒级。引入 MQ 之后，下单主链路只做订单创建，发短信、加积分这些操作丢到消息里异步处理，用户感知到的就是"下单秒回"。这就是异步和解耦的价值。再比如秒杀场景，瞬间几万请求打过来，数据库扛不住，用 MQ 做削峰，先把请求接收下来，消费者按照自己的速率慢慢处理，系统就不会被打崩。
七种工作模式就是 RabbitMQ 在这三个能力之上的不同组合姿势：
| 模式 | 核心交换机类型 | 一句话说明 |
|---|---|---|
| 简单模式 | 默认交换机 | 点对点，最基础的队列收发 |
| Work 队列 | 默认交换机 | 一个队列多个消费者，任务分发 |
| 发布订阅 | Fanout | 广播，所有绑定的队列都能收到 |
| 路由模式 | Direct | 按 RoutingKey 精确匹配 |
| 主题模式 | Topic | 按通配符规则模糊匹配 |
| RPC 模式 | Direct | 同步请求-响应，等待处理结果 |
| 发布确认 | Confirm | 生产者确认消息到达 Broker |
学七种模式之前，有一个常见误区必须纠正：大部分人以为它们是七个并列的协议，实际上后四种模式使用的都是同一个机制——Exchange + RoutingKey + Binding，只是绑定规则和交换机类型不同。看懂了这一层，后面一切都顺了。
2. 前置工作：安装、启动和核心概念一个都不能少
我见过太多人模式看懂了，自己动手一搭环境就废掉，所以先花一章讲安装和核心概念。这里结合我自己在不同操作系统上装 RabbitMQ 的实测经验，把最容易出问题的地方拉出来说。
2.1 Windows 下安装：版本匹配是关键
Windows 装 RabbitMQ 最大的坑不是安装包下载，而是Erlang 版本不匹配。RabbitMQ 底层运行在 Erlang 虚拟机上，两者版本必须对应，否则服务根本起不来。比如 RabbitMQ 3.12.x 往往要求 Erlang 26.x，你装个 Erlang 23 启动直接报错。
推荐做法是去 RabbitMQ 官网的which-erlang页面查看版本匹配表，然后再到 Erlang 官网下载对应版本的 Windows 安装包，记得勾选"Add Erlang to PATH"。装完 RabbitMQ 后，先启动 RabbitMQ Service，再执行：
rabbitmq-plugins enable rabbitmq_management然后访问http://localhost:15672，默认账号密码是guest/guest。
我在 Windows 11 上遇到过启动失败，排查下来是RabbitMQ 服务没注册成功，或者安装目录没有写权限。解决方法是以管理员身份运行命令提示符，进入 RabbitMQ 的 sbin 目录，执行：
rabbitmq-service.bat install rabbitmq-service.bat start如果还不行，多半是 5672 端口被占用，用netstat -ano | findstr 5672看是谁占的端口，处理掉之后服务就能起来。
2.2 Linux 下安装：建议用官方脚本或包管理器
Linux 上我试过源码编译安装，也试过直接下载官方 RPM 包，体验差别很大。建议优先用官方提供的 RabbitMQ generic Unix 包，或者直接用系统自带的包管理器，因为源码编译要自己处理 Erlang 依赖，非常容易把自己绕进去。
我常用的部署步骤是基于.tar.xz通用包：
wget https://github.com/rabbitmq/rabbitmq-server/releases/download/v4.1.0/rabbitmq-server-generic-unix-4.1.0.tar.xz tar -xf rabbitmq-server-generic-unix-4.1.0.tar.xz mv rabbitmq_server-4.1.0 /opt/rabbitmq export PATH=$PATH:/opt/rabbitmq/sbin rabbitmq-server -detached启动之后重点检查三件事：主机名能不能解析、防火墙有没有放行 5672 和 15672 端口、数据目录是否有权限。RabbitMQ 对主机名做节点名绑定，Linux 上经常因为/etc/hostname没配置好导致启动失败，这时候执行hostname -f看返回值，再用rabbitmqctl status查看诊断信息。
2.3 修改默认端口：5672 和 15672 分别怎么动
默认情况下 RabbitMQ 的 AMQP 端口是 5672，管理台端口是 15672。如果这两个端口被冲突，修改方式不同。
RabbitMQ 在/etc/rabbitmq/rabbitmq.conf（Linux）或安装目录的etc/rabbitmq/rabbitmq.conf（Windows）里支持原生配置：
listeners.tcp.default = 5673 management.tcp.port = 15673改完执行rabbitmqctl stop再rabbitmq-server -detached重启。我建议除非端口严重冲突，否则不要改默认端口，因为很多客户端连接配置、监控系统、运维脚本都假设默认值，改完之后可能会有一串连锁问题。
2.4 五个必须刻在脑子里的核心概念
RabbitMQ 中五件事不知道，七种模式等于白看：
- Producer（生产者）：发消息的人。
- Consumer（消费者）：收消息并处理的人。
- Queue（队列）：消息存放的地方，本质是一个缓冲区。
- Exchange（交换机）：消息的"路由器"，接收生产者消息，按规则投递到一个或多个队列。
- Binding（绑定）：交换机和队列之间的关联关系，绑定的时候要指定 RoutingKey（路由键）。
消息的完整流向是：生产者 -> 交换机 -> 根据 RoutingKey 匹配绑定规则 -> 存入一个或多个队列 -> 消费者拉取消费。
之前有朋友问我，为什么不能直接生产者的消息发到队列，非要经过交换机？原因在于，没有交换机就意味着每条消息只能进一个确定的队列，想要广播、想要按类型分发、想要模糊匹配，全都实现不了。交换机这层抽象才是 RabbitMQ 灵活性的根本。
可以用快递驿站来类比：生产者是寄件人，消费者是收件人，队列是快递柜，交换机是快递分发中心。寄件人把包裹给驿站，驿站看了包裹上的标签（RoutingKey），按不同规则投到不同快递柜。绑定关系就是驿站墙上贴的"规则表"。
3. 七种工作模式逐个拆解
这部分是全文的核心，每个模式我会用「干哈用的 -> 怎么玩 -> Spring Boot 代码 -> 坑在哪」的顺序来讲。
3.1 简单模式（Hello World）
最简单的点对点模式。生产者往指定队列丢消息，消费者监听这个队列，一条消息只会被一个消费者收到。通常配合默认交换机使用。
// 生产者 @RestController public class SimpleProducer { @Autowired private RabbitTemplate rabbitTemplate; @GetMapping("/send") public String send() { rabbitTemplate.convertAndSend("simple.queue", "hello rabbitmq"); return "ok"; } } // 消费者 @Component public class SimpleConsumer { @RabbitListener(queues = "simple.queue") public void receive(String msg) { System.out.println("收到消息：" + msg); } }这套代码是 RabbitMQ 的 "Hello World"，但实际生产项目里极少单独这么用。原因很简单：它没有重试机制、没有多消费者负载均衡、没有持久化的完整保障。很多新手项目练手可能直接这么写，上线之后发现消息一多就出问题。建议把它当成理解最小粒度的工具，而不是直接投入生产的模板。
3.2 Work 队列模式（竞争消费者模式）
Work 队列和简单模式唯一的区别是：一个队列对应多个消费者，消息轮流分发到不同消费者，保证同一消息不会被重复消费。它解决的问题是：单个消费者处理太慢，消息在队列里越积越多，需要横向拉消费者来分摊任务。
讲原理要先看默认行为。默认情况下 RabbitMQ 采用轮询分发，按顺序一个消费者一条消息，完全不考虑消费者处理速度。这就会出现一个很尴尬的场景：消费者 A 处理一条消息需要 10 秒，消费者 B 处理一条只要 1 秒，轮询分发依然是一条一条平均分。结果是慢的积压、快的空闲。
生产环境的正确姿势是设置不公平分发和预取数量：
@Configuration public class WorkQueueConfig { @Bean public Queue workQueue() { return QueueBuilder.durable("work.queue").build(); } @Bean public RabbitListenerContainerFactory workFactory(ConnectionFactory connectionFactory) { SimpleRabbitListenerContainerFactory factory = new SimpleRabbitListenerContainerFactory(); factory.setConnectionFactory(connectionFactory); factory.setPrefetchCount(1); // 每次只取一条，处理完再取下一条 factory.setAcknowledgeMode(AcknowledgeMode.MANUAL); // 手动确认 return factory; } }配置prefetchCount=1之后，消费者每次只从 RabbitMQ 预取一条消息，处理完成并确认后才取新消息，处理快的消费者自然就多干活，处理慢的也不会被压太多。这是 Work 队列模式最重要的生产经验。
Work 模式的应用场景非常典型，比如批量邮件发送、批量状态同步、导出报表任务拆分。只要任务量大且任务之间互相独立，都可以上 Work 队列。
3.3 发布订阅模式（Publish/Subscribe）
到这一模式开始引入交换机。发布订阅使用的交换机类型是Fanout，它的行为是：凡是绑定到这个交换机上的队列，每条消息都会收到一份，和 RoutingKey 无关，直接广播。
你可以把它理解成微信群发：群主发一条消息，所有群成员都能收到，谁也没法阻止消息进群。
代码上要定义三个角色的东西：一个 Fanout 交换机、两个队列、两条绑定关系。
@Configuration public class PubSubConfig { @Bean public FanoutExchange pubExchange() { return new FanoutExchange("pub.exchange"); } @Bean public Queue emailQueue() { return new Queue("email.queue"); } @Bean public Queue smsQueue() { return new Queue("sms.queue"); } @Bean public Binding emailBinding() { return BindingBuilder.bind(emailQueue()).to(pubExchange()); } @Bean public Binding smsBinding() { return BindingBuilder.bind(smsQueue()).to(pubExchange()); } } // 生产者 rabbitTemplate.convertAndSend("pub.exchange", "", "这是一条广播消息");发布订阅模式最常见的误解是，以为 Fanout 广播和 MQTT 的"主题订阅"一回事。其实不同，Fanout 广播是全局的，不区分选择性接收，你绑了队列必然收到，不绑必然收不到，没有通配符那套。如果你需要"部分订阅"，请直接跳到后面 Topic 主题模式。
实际运用中，我用它做过全服务刷新配置缓存、更新多端数据副本、发送全量通知。比如一个商品变更事件，库存中心、搜索索引、缓存服务都要感知，用 Fanout 一次性广播，谁关心谁绑队列即可。
3.4 路由模式（Routing）
路由模式使用的交换机类型是Direct。它与 Fanout 的区别在于，消息并不是直接广播到所有队列，而是交换机根据 RoutingKey 精确匹配绑定了相同 RoutingKey 的队列，然后把消息投递过去。
接前面快递驿站的类比：Fanout 是驿站跟所有快递柜都通了个电话，Direct 是按快递柜上贴的标签，快递到了之后按标签精准分发。
@Configuration public class RoutingConfig { @Bean public DirectExchange routingExchange() { return new DirectExchange("routing.exchange"); } @Bean public Queue errorQueue() { return new Queue("error.queue"); } @Bean public Queue infoQueue() { return new Queue("info.queue"); } @Bean public Binding errorBinding() { return BindingBuilder.bind(errorQueue()) .to(routingExchange()).with("error"); } @Bean public Binding infoBinding() { return BindingBuilder.bind(infoQueue()) .to(routingExchange()).with("info"); } } // 生产者路由到 error 队列 rabbitTemplate.convertAndSend("routing.exchange", "error", "系统出错了");路由模式最典型的案例是日志处理：error日志进错误队列触发告警，info日志进信息队列做归档。这里有一个很细节的操作：一个队列可以绑定多个 RoutingKey，比如errorController队列同时绑定error和warning，这样系统错误和警告都发到同一个队列统一处理。
路由模式的坑在于，容易忽略"默认交换机"。其实简单模式用到的"默认交换机"就是AMQP default，它的 RoutingKey 直接对应队列名。很多人没意识到这点，以为默认交换机很特殊，其实它本质上就是一个 Direct 交换机，只是路由键规则固定为队列名。
3.5 主题模式（Topics）
主题模式使用的交换机类型是Topic，它是 Direct 的升级版，支持模糊匹配。RoutingKey 必须使用点号.分隔成多个单词，绑定 Queue 时可以用*和#做通配符：
*：必须匹配一个单词。#：匹配零个或多个单词。
比如我常见的一个绑定规则表：
| 绑定队列 | 绑定 RoutingKey 模式 | 能匹配的消息 |
|---|---|---|
| errorQueue | log.error.* | log.error.systemA |
| allQueue | log.# | log.info、log.error.systemA、log.warning.systemB |
主题模式适合的场景是多条件组合分发，比如订单系统中按"区域 + 状态"路由消息：
order.shenzhen.paid：深圳地区已支付订单，推送给深圳的履约服务。order.#.refund：所有已退款订单，推送给财务系统。
代码示例：
@Bean public TopicExchange topicExchange() { return new TopicExchange("topic.exchange"); } @Bean public Queue allOrderQueue() { return new Queue("all.order"); } @Bean public Binding allOrderBinding() { return BindingBuilder.bind(allOrderQueue()) .to(topicExchange()).with("order.#"); } // 生产者 rabbitTemplate.convertAndSend("topic.exchange", "order.shenzhen.paid", "订单已支付");主题模式的坑我重点提一下：如果 RoutingKey 用的是order.shenzhen.paid这种三段式，绑定时写成order.*并不能匹配，因为*只能匹配一个单词，而paidadmin是第三个单词。很多新手在主题匹配上反复踩坑，其实只需要记住*匹配一个.分隔的单词段，#匹配剩余的任意段，就不会错。还要注意#放在开头和结尾的效果不一样，放在开头表示匹配任意前缀，放在结尾表示匹配任意后缀，两个#同时出现在一个绑定键里会导致匹配规则不可预期，尽量避免。
3.6 RPC 模式
RPC 模式是七种模式中最容易"看不懂"的，因为它不完全属于异步消息，而是一种同步请求-响应模型：客户端把消息发到一个请求队列，服务端消费并处理，然后把结果发到响应回调队列，客户端在回调队列上等待结果。
它的核心机制用到了两个队列和一个关键字段：
- 客户端创建
callback.queue作为回调队列。 - 客户端发送消息时设置
replyTo属性，告诉服务端把结果发到哪个队列。 - 客户端发送消息时设置
correlationId属性，用于关联请求和响应数据。
过程示意（不画复杂图，用文字描述）：客户端把请求放上队列，带着自己的回复地址和唯一标识；服务端消费到请求，执行完业务，往回复地址发结果，并且原样带上 correlationId；客户端根据 correlationId 匹配到对应的那次请求，把结果返回给调用方。
RPC 模式在微服务架构里今天很少直接用了，因为 HTTP、gRPC 已经非常成熟，很多人选择更直接的方式。那它还有没有价值？有，我见过几个场景依然用它比较合适：
- 跨语言服务调用，且两个系统之间已经依赖 RabbitMQ 作为基础消息设施，不想额外引入另一个 RPC 框架。
- 处理耗时长的任务，不想让 HTTP 连接长时间挂着，采用 MQ 做异步 RPC，发送请求后立即返回，后台再来处理。
- 已经有现成队列集群和监控体系，用 MQ 做 RPC 意味着运维链条不需要再引入额外组件。
如果你要用 Java 原生代码实现，涉及 ContentType、replyTo、correlationId 等属性的手动设置，比 Spring 的RabbitTemplate.convertSendAndReceive要麻烦不少。Spring 封装了convertSendAndReceive，它内部帮我们实现了 replyTo 和 correlationId 的编排，日常开发用这个足够。
3.7 发布者确认模式（Publisher Confirms）
七种模式里最容易忽略，却是保证消息可靠性最关键的一个。发布者确认模式的思路是：生产者发消息给 Broker，Broker 成功落盘并持久化后，会给生产者回一个ack，如果处理失败，则回nack，生产者收到 nack 决定重发还是告警。
这个模式不是用来"路由"消息的，而是保证生产端到 Broker 这一段消息不丢。与之对应，要保证消息全链路可靠，还需要配合队列持久化、消费者手动 Ack、死信队列实现。
特别要提醒的是，RabbitMQ 的事务模式（txSelect）也可以保证消息可靠，但性能极差，每发一条消息都是 commit 级别的开销。发布者确认是官方推荐替代事务的方案，性能损失小很多。Spring 中开启确认模式的配置：
spring: rabbitmq: publisher-confirm-type: correlated # 异步确认，开启 confirm publisher-returns: true # 开启 return 退回机制@Configuration public class ConfirmConfig { @Bean public RabbitTemplate rabbitTemplate(ConnectionFactory connectionFactory) { RabbitTemplate rabbitTemplate = new RabbitTemplate(connectionFactory); rabbitTemplate.setMandatory(true); // 关键：消息找不到队列时退回 rabbitTemplate.setConfirmCallback((correlationData, ack, cause) -> { if (ack) { System.out.println("消息到达交换机"); } else { System.out.println("消息到达交换机失败：" + cause); } }); rabbitTemplate.setReturnsCallback(returned -> { System.out.println("消息从交换机退回：" + returned.getReplyText()); }); return rabbitTemplate; } }需要注意，Confirm 回调只负责交换机收到消息这一段的确认，不代表消息已经进队列了。消息如果被退回到交换机，需要配合 ReturnsCallback 处理。如果交换机接收失败也不重试，就要自己写重试策略或者投递到死信队列。
我做过一个支付回调对账服务，对消息可靠性的要求是"宁可重复，不可丢失"，发布者确认恰当，Consumer 手动 Ack + 幂等处理，才把数据不丢这件事做到了 99.99%。所以不要以为七种模式只是路由方式，发布者确认是生产系统能不能上线的根基。
4. 模式选型：RabbitMQ、Kafka、RocketMQ 怎么选
学完七种模式之后，一定会有一个问题浮出来：是选 RabbitMQ 还是 Kafka 还是 RocketMQ？网上围绕这个问题的争论很多，我结合自己的开发和运维经验，给出一个尽量客观的视角。
4.1 三大 MQ 的定位差异对比
| 维度 | RabbitMQ | Kafka | RocketMQ |
|---|---|---|---|
| 开发语言 | Erlang | Scala/Java | Java |
| 典型优势 | 灵活路由、生态成熟、管理台好用 | 高吞吐、日志流、分区有序 | 事务消息、延迟消息、金融场景 |
| 适用场景 | 业务解耦、工单任务、多路由分发 | 日志采集、实时计算、大数据链路 | 电商订单、资金流水、累计消息 |
| 消息可靠性 | 需要结合 confirm + 手动确认 | 需要自己处理消费位点 | 事务消息内置支持 |
| 顺序消息 | 支持队列内顺序，但要小心 | 分区内顺序好 | 集群秒级顺序 |
我在实际项目里的经验是，它们是互补的关系，不是替代的关系。业务系统内部的服务解耦、定时任务分发、通知广播，首选 RabbitMQ，原因就是七种工作模式提供了非常丰富的路由能力，而且管理台插件非常好用，排查问题方便。数据平台侧的日志聚合、用户行为采集，首选 Kafka，因为它的写入吞吐和分区机制是为了海量数据流设计的。涉及资金交易、订单状态严格一致、需要分布式事务支持的场景，RocketMQ 的事务消息机制会比自己在 RabbitMQ 上搓可靠很多。
4.2 按场景选择具体工作模式的决策流程
业务里经常需要做模式决策，我整理成一个简化的决策思路，按步骤来基本不踩坑：
- 消息只需要被一个消费者处理后结束：选简单模式或 Work 队列。如果任务并发消耗大、消息积压明显，升级为 Work 队列加手动确认。
- 消息需要所有模块都收到一份：选 Fanout 发布订阅。
- 消息需要按类型精确分发：选 Direct 路由模式。
- 消息需要按通配符规则分发：选 Topic 主题模式。
- 需要同步等待结果：选 RPC 模式，或者干脆走 HTTP 同步调用。
- 消息重要、不能丢：不管哪种模式，都必须开发布者确认 + 队列持久化 + 消费者手动 Ack。
有一个常见误区是，用 Topic 模式解决所有路由问题。我见过有人把所有 RoutingKey 设计成很长的点分串，试图用#和*组合覆盖所有场景，最后绑定关系复杂到没法维护。设计原则是：能用两个 Direct 交换机解决的问题，就不要用一个 Topic 去匹配一大堆模式。路由越简单，代码越容易理解，跨团队协作的沟通成本就越低。
4.3 什么情况下建议别用 RabbitMQ
RabbitMQ 虽然好，但不合适的时候也别硬扛。我和团队曾经在一个数据采集项目里，单日消息量到了一个亿的级别，在 RabbitMQ 上做存储和后端消费，超过几天消息堆积后，吞吐和磁盘压力都很感人，后来换成 Kafka 才彻底解决。总结下来，两种情况建议直接换 MQ：
- 吞吐量要求特别高（百万级以上每秒），优先考虑 Kafka，它面向批量处理做了大量优化。
- 需要强一致性的金融级事务消息，优先考虑 RocketMQ，它的事务消息半提交机制帮你省掉极多底层造轮子成本。
- 生态和人员技能栈偏向大数据，直接上 Kafka，RabbitMQ 的大数据集成能力明显不如 Kafka。
用我自己的话说，RabbitMQ 负责"把每一条消息送到该去的地方"，Kafka 负责"把海量消息快速存放并给你处理"，RocketMQ 负责"在强一致和事务的泥潭里给你搭桥"。
5. 高频踩坑与面试必问：从启动失败到消息丢失
最后这部分是实战中最容易被问到、也最常出问题的点。我按三个维度来整理：环境类、可靠性类、面试类。
5.1 启动失败排查清单
结合我自己在 Windows 和 Linux 上遇到的启动失败案例，整理成一个快速排查顺序：
| 现象 | 排查点 | 解决办法 |
|---|---|---|
| 服务启动报 Erlang 版本错误 | Erlang 与 RabbitMQ 版本不匹配 | 查官网版本匹配表，统一版本 |
| 启动后立刻退出，日志无特殊信息 | 主机名无法解析 | 修改/etc/hostname，执行hostname -F重新加载 |
| 管理台 15672 打不开 | 管理插件未启用或端口被防火墙拦截 | 执行rabbitmq-plugins enable rabbitmq_management，防火墙放行端口 |
| Windows 服务起不来 | 安装目录无写权限 | 以管理员身份重装，重新安装服务 |
| 内存警告导致拒绝生产消息 | 磁盘空间或可用内存不足 | 扩大磁盘、清理堆积队列、调高水位限制 |
| 修改端口后客户端连不上 | 只改了管理台端口没改 AMQP 端口 | 同时修改listeners.tcp.default和management.tcp.port |
有一个我后来才发现的问题：RabbitMQ 的默认 guest 用户只允许 localhost 访问，远程连接必须创建新用户并分配权限。很多人本地能连通，部署到服务器上其他机器怎么都连不上，就是这个原因。
5.2 消息可靠性三连坑
面试和实战最常考的就是"消息不丢失"。完整链路有三个环节：生产者到交换机、交换机到队列、消费者处理消息。任何一环没做好，消息都可能丢。
第一段：生产者到交换机。必须有发布者确认（confirm），确认消息真的被 Broker 收下了。
第二段：交换机到队列。必须设置交换机的持久化、队列的持久化，否则 Broker 重启后队列和消息都没了。持久化之后如果mandatory为 false，消息没有匹配到队列会静默丢弃，所以生产上务必 setMandatory(true) 并配合 ReturnsCallback。
第三段：消费者处理。消费者默认是自动 Ack，也就是说消息从队列取出就删掉了，即使后续处理异常，消息也已经丢失。必须手动确认，业务处理成功再basicAck，失败了basicNack并决定是否重新放回队列。
还有一个重复消费问题，很多人会忽略。手动确认 + 网络抖动可能会造成消息重复投递，比如消费者处理成功了但 Ack 没发回去，RabbitMQ 重新投递消息，消费者又处理一遍。所以消费逻辑一定要提供幂等方案（数据库唯一索引、Redis SetNx、业务状态机校验等）。
5.3 面试高频题速答
结合这些年在面试中反复被问到的题目，我整理出五道最高频的：
RabbitMQ 七种工作模式分别是什么？ 答：简单模式、Work 队列、发布订阅、路由模式、主题模式、RPC、发布者确认，后四个核心是交换机路由规则不同。
Direct、Topic、Fanout 有什么区别？ 答：Fanout 全量广播不校验路由键；Direct 按 RoutingKey 精确匹配；Topic 按通配符匹配，
*匹配一个词，#匹配零个或多个词。如何保证消息不丢失？ 答：生产者开启 Confirm 模式，队列和交换机持久化，消费者手动 Ack，必要时引入死信队列兜底。
消息积压了怎么办？ 答：先临时扩容消费者并合理设置 prefetch，注意不要盲目设置过大的 prefetch 导致内存暴涨；如果消费逻辑有瓶颈或外部依赖阻塞，需要先隔离消费逻辑，把消息重新导到新队列再处理。
RabbitMQ 集群高可用怎么做？ 答：普通模式下用镜像队列，Quorum 队列是更推荐的现代方案；镜像队列在故障切换时会有延迟和安全风险，Quorum 队列在保证数据一致性上更可靠。深夜讲细容易偏题，但这一点建议提前准备。
5.4 死信队列和延迟队列：七种模式之外的延伸
七种模式不包含死信队列，但实际工程里你用任何一种模式都可能需要它。死信队列可以理解为"消息的垃圾回收站"：消息被消费者拒绝、TTL 超时、队列长度超过限制时，会被投递到死信交换机，再进入死信队列。延迟队列一般是"TTL + 死信转发"组合出来的，通过设置消息的过期时间，过期之后由死信机制转投到目标队列。
这个设计在支付超时、订单自动取消、延迟任务场景下非常实用。我在做下单超时关闭功能的时候，订单消息设置 15 分钟 TTL，超时后自动进入死信队列，由专门的消费者扫描并执行关单动作，这个方案延迟一般不影响业务。
建议读完这篇文章后，把死信队列和延迟队列也一并研究一下，它们在面试上几乎可以当作"第七种半模式"来加分。
最后分享一个我自己调试这七种模式的习惯：RabitMQ Management 管理台里有一个 Exchange 页面，选中任意交换机点进去，会看到所有绑定关系和 RoutingKey；再点 Queue 页面，选中队列可以 Publish 消息和 Get Messages。我每次写模式 Demo 前，都会先建一个临时队列，手动在管理台上发消息、换绑定规则、观察消息分布。这种方式比一遍遍改代码重启服务高效得多。等你把管理台玩熟了，RabbitMQ 在你眼里就变成一个能直接摆弄的路由实验台，七种模式不再是七个概念，而是七种能随手切换的分发规则。
