启用备用交换机可自动捕获无法路由的消息：声明fanout类型持久化备用交换机my-ae，绑定持久化队列unroutable-messages，为主交换机配置alternate-exchange参数指向my-ae，消息将被广播至该队列。

直接在声明主交换机时指定一个 fanout 类型的备用交换机，就能自动捕获所有无法路由的消息，不用改生产者代码，也不用设 mandatory 或监听 ReturnListener。

声明 fanout 类型的备用交换机和接收队列

备用交换机必须是 fanout 类型（最简单可靠），它不关心 routingKey，确保所有转发来的消息都能被广播出去。

• 创建持久化备用交换机，比如名为 my-ae，类型为 fanout，durable=true
• 声明一个专用队列，如 unroutable-messages，同样设为 durable=true
• 把该队列绑定到备用交换机，binding 的 routingKey 可填空字符串（fanout 忽略它）

为主交换机配置 alternate-exchange 参数

这是关键一步：在声明主交换机（direct/topic/fanout）时，通过 arguments 显式传入 "alternate-exchange" 参数。

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 参数键名必须是 alternate-exchange（注意连字符，大小写敏感）
• 参数值必须是已存在的、类型兼容的交换机名称（比如上面声明的 my-ae）
• RabbitMQ 运行时会校验该交换机是否存在；若不存在，声明会失败

验证机制是否生效

发一条 routingKey 在主交换机上没有任何队列绑定的消息，它不会丢失，而是自动流入备用交换机绑定的队列。

• 例如主交换机绑定了 order.created，却发送了 user.deleted
• 登录 RabbitMQ 管理界面 → Queues 页面，查看 unroutable-messages 是否有积压消息
• 启动消费者监听该队列，可做日志归档、告警或人工干预

注意事项和常见误区

Alternate Exchange 只处理“无法路由”的消息，不是万能兜底方案。

• 它不捕获队列满、消费者 nack/reject、TTL 过期、消息被拒绝等场景——这些属于死信范畴，应配合 DLX 使用
• 备用交换机自身不能再设 alternate-exchange，否则 RabbitMQ 拒绝声明（防止循环转发）
• 消息进入 fanout 备用交换机后，原始 exchange 名和 routingKey 信息会丢失
• 如果同时用 Policy 设置 AE，代码中声明的 arguments 优先级更高，会覆盖 Policy 配置