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.confLinux或安装目录的etc/rabbitmq/rabbitmq.confWindows里支持原生配置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; } }配置prefetchCount1之后消费者每次只从 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 模式能匹配的消息errorQueuelog.error.*log.error.systemAallQueuelog.#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七种模式里最容易忽略却是保证消息可靠性最关键的一个。发布者确认模式的思路是生产者发消息给 BrokerBroker 成功落盘并持久化后会给生产者回一个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 的定位差异对比维度RabbitMQKafkaRocketMQ开发语言ErlangScala/JavaJava典型优势灵活路由、生态成熟、管理台好用高吞吐、日志流、分区有序事务消息、延迟消息、金融场景适用场景业务解耦、工单任务、多路由分发日志采集、实时计算、大数据链路电商订单、资金流水、累计消息消息可靠性需要结合 confirm 手动确认需要自己处理消费位点事务消息内置支持顺序消息支持队列内顺序但要小心分区内顺序好集群秒级顺序我在实际项目里的经验是它们是互补的关系不是替代的关系。业务系统内部的服务解耦、定时任务分发、通知广播首选 RabbitMQ原因就是七种工作模式提供了非常丰富的路由能力而且管理台插件非常好用排查问题方便。数据平台侧的日志聚合、用户行为采集首选 Kafka因为它的写入吞吐和分区机制是为了海量数据流设计的。涉及资金交易、订单状态严格一致、需要分布式事务支持的场景RocketMQ 的事务消息机制会比自己在 RabbitMQ 上搓可靠很多。4.2 按场景选择具体工作模式的决策流程业务里经常需要做模式决策我整理成一个简化的决策思路按步骤来基本不踩坑消息只需要被一个消费者处理后结束选简单模式或 Work 队列。如果任务并发消耗大、消息积压明显升级为 Work 队列加手动确认。消息需要所有模块都收到一份选 Fanout 发布订阅。消息需要按类型精确分发选 Direct 路由模式。消息需要按通配符规则分发选 Topic 主题模式。需要同步等待结果选 RPC 模式或者干脆走 HTTP 同步调用。消息重要、不能丢不管哪种模式都必须开发布者确认 队列持久化 消费者手动 Ack。有一个常见误区是用 Topic 模式解决所有路由问题。我见过有人把所有 RoutingKey 设计成很长的点分串试图用#和*组合覆盖所有场景最后绑定关系复杂到没法维护。设计原则是能用两个 Direct 交换机解决的问题就不要用一个 Topic 去匹配一大堆模式。路由越简单代码越容易理解跨团队协作的沟通成本就越低。4.3 什么情况下建议别用 RabbitMQRabbitMQ 虽然好但不合适的时候也别硬扛。我和团队曾经在一个数据采集项目里单日消息量到了一个亿的级别在 RabbitMQ 上做存储和后端消费超过几天消息堆积后吞吐和磁盘压力都很感人后来换成 Kafka 才彻底解决。总结下来两种情况建议直接换 MQ吞吐量要求特别高百万级以上每秒优先考虑 Kafka它面向批量处理做了大量优化。需要强一致性的金融级事务消息优先考虑 RocketMQ它的事务消息半提交机制帮你省掉极多底层造轮子成本。生态和人员技能栈偏向大数据直接上 KafkaRabbitMQ 的大数据集成能力明显不如 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 在你眼里就变成一个能直接摆弄的路由实验台七种模式不再是七个概念而是七种能随手切换的分发规则。