做 RabbitMQ 也快十年了，我见过不少因为交换机持久化配置不规范导致的事故。最典型的一次是凌晨发版后，RabbitMQ 节点因为内存紧张被自动重启，结果业务方发现所有消息都发不出去。查来查去，问题不是队列丢了，而是交换机没了。交换机在 RabbitMQ 里有点像快递分拣中心，消息先到交换机，再由它按规则塞进队列。如果分拣中心的定义没有持久化，节点一重启，这个中心就等于被拆了，后续消息自然无处可去。今天就把 RabbitMQ 四大类型交换机——direct、topic、fanout、headers——以及它们各自的持久化机制完整梳理一遍。
特别提醒一句：这里的“交换机”是消息中间件里的 exchange，不是网络设备那个交换机，也不是锐捷、华为命令行里配的那个交换机。网上搜“交换机持久化”很容易被误导到网络设备配置上去，所以先把这个概念锚定住。
1. 为什么先把“持久化”这件事搞明白
1.1 交换机在 RabbitMQ 里到底是什么角色
RabbitMQ 的核心模型是“生产者 -> 交换机 -> 队列 -> 消费者”。生产者不会直接把消息丢进队列，而是先把消息发给交换机，交换机再根据路由规则把消息复制或转发到一个或多个队列。所以交换机本身不存储消息内容，它只保存两样东西：自身的定义（名称、类型、持久化标志、自动删除标志）和它与队列之间的绑定关系。
这也是很多人对“交换机持久化”产生误解的根源：以为交换机持久化了，消息就不会丢。实际上，交换机持久化只保证“这个交换机还在”，不保证“队列里的消息还在”。如果交换机没持久化，节点重启后交换机定义丢失，生产者再往这个交换机发消息就会得到 404 channel exception；如果交换机持久化了但队列没持久化，队列没了，交换机绑定关系也没了，消息即使路由到空队列也等于白发。
换一个更直白的说法：交换机持久化解决的是“路由拓扑是否还在”的问题，消息能不能活下来是另一套机制。
1.2 交换机、队列、消息三层持久化缺一不可
RabbitMQ 的持久化可以拆成三个独立维度：
| 持久化对象 | 配置方式 | 重启后效果 | 是否包含消息内容 |
|---|---|---|---|
| 交换机 | 声明时durable=true | 交换机定义恢复，绑定关系只要队列也在就恢复 | 不包含 |
| 队列 | 声明时durable=true | 队列定义恢复，持久化消息恢复 | 包含消息数据 |
| 消息 | 发送时delivery_mode=2 | 消息写入磁盘，重启后可恢复 | 消息本身 |
注意这里的关键点：交换机持久化只是“三者之一”。如果一个交换机是 durable 的，队列是 durable 的，但生产者在发送消息时没有把delivery_mode设为 2，那么消息依然是瞬态消息。节点一旦宕机，这条消息大概率会丢。很多做 RabbitMQ 的入门教程会强调“durable exchange + durable queue + persistent message”才是保证消息不丢的完整配置，但实际业务里经常只做到前两步，结果就把锅甩给了 RabbitMQ。
我在生产项目里见过一个经典案例：业务方把所有交换机都声明成了 durable，队列也声明成了 durable，但生产者发送消息时用的是 Spring Boot 默认的MessageDeliveryMode.PERSISTENT，看起来没问题。后来有一个老项目没有走公共封装，发送消息时直接操作RabbitTemplate，结果消息默认投递模式是瞬态。节点重启后，交换机还在，队列还在，但积压在队列里的消息全部消失。排查了很久才发现是消息级别的持久化漏了。
2. RabbitMQ 四大交换机类型逐一拆解
RabbitMQ 官方定义的四大内置交换机类型是direct、topic、fanout、headers。它们的路由逻辑完全不同，但在持久化配置上用的是同一个durable标志。所以我先分别讲清楚每种类型是什么、适合什么场景，再统一讲持久化怎么配。
2.1 Direct：精确匹配，最常用的业务路由
direct交换机的路由规则最简单：消息的routing_key必须与队列绑定的binding_key完全一致，才能路由到该队列。比如生产者发送routing_key="order.create"，交换机有两个绑定：一个是队列 A 绑定了order.create，另一个队列 B 绑定了order.pay，那只有队列 A 能收到这条消息。
这个类型适合按业务事件精确分发消息。比如订单服务创建订单后发出order.created事件，只希望通知库存服务，不希望通知支付服务，那 direct 就是最合适的选择。
持久化配置也不复杂。在 Java 代码里声明一个 direct 交换机：
@Bean public DirectExchange orderExchange() { return new DirectExchange("order.exchange", true, false); }这里的true表示 durable，false表示 autoDelete。我的习惯是：只要交换机在业务里被长期复用，直接设durable=true, autoDelete=false。autoDelete=false保证交换机不会因为最后一个绑定队列解绑而被自动删除。如果只设 durable 不设 autoDelete，在管理界面创建时默认auto_delete=false，但在代码里手动调用new DirectExchange(name)这种只传 name 的构造函数时，durable 和 autoDelete 都是默认值，其中 durable 默认是 false，得特别注意。
2.2 Topic：按通配符匹配，灵活但容易配错
topic交换机是生产环境最常用的类型之一。它支持用通配符匹配routing_key：*匹配一个单词，#匹配零个或多个单词，单词之间用.分隔。比如topic.exchange绑定了一个队列，binding key 是order.*.created，那order.created.created可以匹配，order.pay.created也可以匹配，但如果 routing key 是order.created只有两个单词，就无法匹配。
这种机制非常适合日志分级、业务事件分类、微服务间按领域前缀订阅等场景。比如日志服务把系统日志分级成log.info、log.error，消费者可以用log.#订阅所有日志，也可以用log.error只订阅错误日志。
持久化配置方式和 direct 一样：
@Bean public TopicExchange logTopicExchange() { return new TopicExchange("log.topic.exchange", true, false); }使用 topic 容易踩的坑是通配符语义。*只能匹配一个“单词”，而不是任意字符。很多初学者以为order.*能匹配order.create和order.create.pay，实际上后者有三个单词，匹配不了。第二坑是发送消息时routing_key本身不能包含通配符，否则会被当成普通字符串去精确匹配 binding key，结果谁也匹配不上。曾有人在生产环境把routing_key写成order.#，导致所有消息都进不了队列，这个事我在答疑群里见过至少三次。
2.3 Fanout：广播复制，不考虑 key
fanout交换机是四大类型里最“粗暴”的。它完全不看 routing key，收到消息后会把消息复制到所有绑定的队列。哪怕你发送时带了 routing key，它也会忽略。所以 fanout 最适合广播场景，比如配置刷新、缓存失效、全局通知。
举个例子：用户修改密码之后，需要通知所有服务踢掉旧 token、刷新缓存、记录安全日志。如果每个服务都建独立队列并绑定到同一个 fanout 交换机，生产者只要往这个交换机发一条消息，所有队列都能收到。
持久化配置示例：
@Bean public FanoutExchange userChangeFanoutExchange() { return new FanoutExchange("user.change.fanout.exchange", true, false); }fanout 场景里最需要注意的是队列数量。如果 fanout 交换机绑定了太多临时队列，每次广播都会往每个队列塞一份消息，队列一多，内存和磁盘占用会涨得很快。生产环境如果 fanout 交换机是持久化的，务必把绑定的队列也设成 durable，并规划好队列数量。曾经有个项目把 fanout 交换机用于 WebSocket 推送，每个连接创建一个自动删除队列，结果高峰时队列数过万，交换机广播一条消息要复制上万份，直接把节点内存打满。
2.4 Headers：按 header 匹配，最灵活也最不常用
headers交换机的路由规则不看 routing key，而是看消息 headers 里的键值对。绑定队列时可以设置x-match参数，x-match=all表示 headers 必须全部匹配才路由，x-match=any表示只要有一个匹配就路由。
比如一个队列绑定了device_type=ios, version=1.2，并且x-match=all。那么只有当消息 headers 里同时包含device_type=ios和version=1.2时，消息才会进入这个队列。这个类型适合按多维元数据做路由，比如不同设备类型、用户端版本、实验分组等。
持久化配置示例：
@Bean public HeadersExchange headerExchange() { return new HeadersExchange("device.header.exchange", true, false); }headers 交换机的最大问题是性能不如前三种，因为每次路由都需要解析消息头并做匹配，管理界面上也不直观。而且 headers 规则写在队列绑定的 arguments 里，排错时需要额外看绑定参数，复杂度很高。我的建议是：除非前三种类型确实表达不了路由规则，否则别用 headers。它虽然灵活，但维护成本是四类里最高的。面试题里常考它的存在，但实际生产项目里用得很少。
3. 交换机持久化配置实操
3.1 在管理控制台声明一个持久化交换机
RabbitMQ 自带的 Web 管理插件（默认端口 15672）可以手动创建交换机。进入 Exchanges 页签，点击 “Add a new exchange”，需要填几个字段：
Name：交换机名称，全局唯一，建议按项目或业务域命名，比如order.exchange。Type：选 direct、topic、fanout、headers 之一。Durability：选Durable表示持久化，选Transient表示不持久化。Auto delete：选Yes表示当最后一个绑定队列解绑后自动删除，选No则不自动删除。生产长期使用的交换机建议设成 No。Internal：选Yes表示只允许交换机转发给交换机，生产者不能直接发布消息。普通业务用不到，默认 No 即可。Arguments：可以填一些扩展参数，比如 alternate-exchange，用于处理无法路由的消息。
这里有个容易忽略的细节：Durable和Auto delete是独立开关。一个交换机可以既 Durable 又是 Auto delete，这样它虽然做成持久化，但只要没有队列绑定了，运行时也会被删掉。很多人在代码里配置了 durable=true 但忘了把 autoDelete 设为 false，以为重启后交换机就一定会恢复，结果每次消费者断开、队列都解绑后交换机就被自动清理了。所以我的习惯是：长期使用的交换机一律durable=true, autoDelete=false；临时用的测试交换机才考虑autoDelete=true。
3.2 在 Spring Boot 中声明持久化交换机
Spring Boot 集成 RabbitMQ 后，一般通过配置类声明Exchange的@Bean。建议不要直接new DirectExchange("order.exchange")，因为这样创建的交换机 durable 默认是 false，autoDelete 默认也是 false，虽然不会自动删除，但不会持久化。正确写法是：
@Configuration public class RabbitMQConfig { @Bean public DirectExchange orderDirectExchange() { return new DirectExchange("order.exchange", true, false); } @Bean public Queue orderQueue() { return QueueBuilder.durable("order.queue").build(); } @Bean public Binding orderBinding() { return BindingBuilder.bind(orderQueue()) .to(orderDirectExchange()) .with("order.create"); } }注意这里QueueBuilder.durable("order.queue")创建的队列也是持久化的，而Binding会随着交换机、队列一起声明。如果交换机和队列都是 durable，重启后绑定关系也会自动恢复。
还需要注意一点：Bean 名称和交换机名称不是一回事。上面代码里方法名orderDirectExchange是 Spring 容器里的 Bean 名称，真正创建到 RabbitMQ 里的交换机名称是"order.exchange"。如果后续要用RabbitAdmin或管理界面查看，认准order.exchange这个字符串。
3.3 用 rabbitmqadmin 和 HTTP API 持久化交换机
在没装管理插件或者不想打开界面的时候，可以用rabbitmqadmin命令行工具来声明交换机。
rabbitmqadmin declare exchange name=order.exchange type=direct durable=true auto_delete=false这个命令需要 RabbitMQ 管理插件已经启用，并且安装目录下有rabbitmqadmin脚本。很多运维习惯把它放在 RabbitMQ 节点的 PATH 里，方便脚本化操作。
HTTP API 也可以直接调用：
curl -u guest:guest -H "Content-Type: application/json" \ -X PUT http://localhost:15672/api/exchanges/%2F/order.exchange \ -d '{"type":"direct","durable":true,"auto_delete":false}'这里%2F是默认 vhost/的 URL 编码。如果业务用了多个 vhost，需要替换成对应的编码值。HTTP API 非常适合在 CI/CD 流水线里做交换机初始化，比在代码里声明更适合团队统一管理，因为不会因为某次代码回滚导致交换机定义不一致。
3.4 Docker 与集群部署时的持久化落盘要点
现在很多项目用 Docker Compose 部署 RabbitMQ。如果只在代码里声明 durable 交换机，但容器没有挂载持久化目录，那容器一旦重建，数据卷里的元数据还是会丢。正确做法是挂载/var/lib/rabbitmq：
services: rabbitmq: image: rabbitmq:3.12-management container_name: rabbitmq environment: RABBITMQ_DEFAULT_USER: guest RABBITMQ_DEFAULT_PASS: guest ports: - "5672:5672" - "15672:15672" volumes: - rabbitmq_data:/var/lib/rabbitmq volumes: rabbitmq_data:这里的rabbitmq_data是一个命名卷，数据会持久化在 Docker 管理的目录里。如果不挂载，容器删除后 RabbitMQ 的元数据、配置、消息全部归零，即使交换机声明了 durable 也救不回来。
另外要强调，rabbitmq.conf和definitions.json的导入导出是另一套机制。很多运维误以为只要持久化交换机，重启后定义就会自动加载。实际上如果 RabbitMQ 是从备份文件恢复，交换机定义和绑定关系会一并恢复；如果只是单纯重启，则靠磁盘上的元数据恢复。所以在集群环境里，最好定期用rabbitmqadmin export导出 definitions 文件，做一个拓扑备份，比临时重建交换机靠谱得多。
4. 常见问题与排查技巧实录
4.1 重启后交换机真的没了吗？
遇过最多次的疑问是：“我的交换机配置里明明设了 durable，为什么重启后还是找不到？”排查时先确认以下几点：
- 代码声明是否真的执行了。Spring Boot 项目里如果配置类没有被扫描，
@Bean可能没生效，交换机根本没创建。 - 确认连接的是不是同一个 vhost。RabbitMQ 的交换机、队列、绑定关系都是在 vhost 隔离的，你在
/里创建的交换机，在dev_vhost里当然看不到。 - 用
rabbitmqctl list_exchanges name durable auto_delete或者 HTTP API 检查当前实际状态。
rabbitmqctl list_exchanges name durable auto_delete如果看到durable对应值是false，说明声明时 durable 参数确实没传进去。如果是true，但重启后交换机还是消失，那很可能是 RabbitMQ 的元数据目录没有被持久化，或者集群节点发生了脑裂导致元数据不一致。
4.2 durable=true 后消息为什么还丢？
这是“三大持久化”没配合好的典型症状。交换机持久化只保证了路由拓扑在，队列持久化保证了队列定义和排队消息在，消息delivery_mode=2保证了消息本身写入磁盘。三者缺一，重启或宕机时都会有丢消息风险。
我列一个自查清单：
| 检查项 | 命令/配置 | 通过条件 |
|---|---|---|
| 交换机持久化 | rabbitmqctl list_exchanges durable | 目标交换机 durable=true |
| 队列持久化 | rabbitmqctl list_queues name durable | 目标队列 durable=true |
| 消息持久化 | 生产端设置delivery_mode=2 | 消息 properties 标记 persistent |
| 发布确认 | 开启 Publisher Confirm | 确认发布成功后再返回业务成功 |
哪怕以上全部通过，RabbitMQ 也不能保证极端情况下 100% 不丢。比如消息进入队列后还没 fsync 到磁盘，节点突然断电，仍然可能丢失。生产环境一般建议配合镜像队列或仲裁队列实现高可用，这个话题展开讲会很长，但至少要认识到：持久化只是减少丢失概率的基石，不是保险箱。
4.3 auto-delete 交换机与持久化“打架”
有个容易踩的坑：durable=true并不是“永不删除”的充分条件。如果auto_delete=true，交换机在所有绑定队列解绑后会被自动删除。即使它是 durable 的，重启之后也不会像你期望的那样恢复，因为它在运行期就被删了。
比如这样声明的交换机：
new DirectExchange("order.exchange", true, true);第二个参数 durable=true，第三个参数 autoDelete=true。如果业务高峰期消费者全部断开，队列被解绑，交换机就会消失。等消费者重新连上，代码里执行声明又能把它建回来，所以问题往往是间歇性的，很难排查。我建议业务代码里所有核心交换机统一设置durable=true, autoDelete=false，把 autoDelete 留给那些临时测试交换机。
4.4 绑定关系是持久化的吗？
RabbitMQ 的绑定关系不单独设置持久化，它依附于交换机和队列。如果交换机和队列都是 durable，绑定关系会作为元数据的一部分持久化并在重启后恢复。如果其中一个不是 durable，比如队列是临时队列，那么队列重建后需要重新绑定，绑定关系自然就没了。
所以，有些场景里“交换机看起来还在，但消息路由不过去”，往往就是队列临时换过名字，或者绑定没重新声明。排查绑定关系可以用：
rabbitmqctl list_bindings source_name destination_name routing_key如果目标队列还在但绑定列表里查不到，说明消费者在声明临时队列时没有重新调用queueBind，或者绑定用的 key 与交换机类型不匹配。
4.5 面试里关于交换机持久化的高频坑
最后聊一下面试题。现在很多 RabbitMQ 面试题会问“交换机持久化是什么，队列持久化是什么”，但很多人会混淆。标准简答是：交换机的持久化通过durable=true实现，持久化的是交换机本身定义和绑定关系，不包含消息内容；消息不丢需要交换机、队列、消息三层持久化配合。
如果对方再问“持久化交换机对性能影响大不大”，可以这样回答：影响主要在消息写入磁盘的 I/O，而不是交换机本身。交换机持久化只是把元数据写入磁盘，消息持久化才是每次写入磁盘的关键。可以通过启用 lazy queues、调整vm_memory_high_watermark、使用 SSD 等方式缓解，但这是后续调优话题，这里不展开。
我在实际项目里的体会是：先把“交换机持久化”当成标配，不要考虑“这个例子要不要 durable”。所有业务交换机都直接durable=true, autoDelete=false，队列默认durable=true，消息默认PERSISTENT，再通过 Publisher Confirm 做发布确认。这套组合拳打下来，虽然不能保证 100% 不丢，但至少能覆盖绝大多数重启、故障场景。真正要丢消息的时候，基本都是配置之外的原因，比如数据卷没挂载、vhost 搞错、绑定丢失。而这些问题，靠一个“交换机是否持久化”的检查清单就能拦住一大半。
最后再分享一个小技巧：上线前或者大版本发布后，用rabbitmqadmin list exchanges name type durable auto_delete把拓扑导出成文本，顺手看一眼哪些交换机不是 durable。我几次救急都是靠这个命令发现的——有些老项目里直接通过管理界面手工创建的交换机，代码里从未声明过，一旦节点迁移，这些交换机就再也回不来了。
