Spring Boot中RabbitMQ消费者重试默认不启用指数退避，因Spring AMQP默认使用SimpleRetryPolicy（仅控次数、无延迟），initial-interval等参数需配合ExponentialBackOffPolicy才生效，否则重试将立即连续执行引发雪崩。
Spring Boot 中 RabbitMQ 消费者重试必须用 ExponentialBackOffPolicy，否则重试间隔会线性堆叠甚至卡死；单纯靠 max-interval 限幅不能替代退避策略本身。
为什么 spring.rabbitmq.listener.simple.retry 默认不启用指数退避
Spring AMQP 的重试默认使用 SimpleRetryPolicy，它只控制重试次数，不控制间隔——所有重试都在异常抛出后立即执行（即“零延迟重试”）。这在生产环境极易引发雪崩：比如数据库连接池已满，消费者反复秒级重试，只会加剧资源争抢。
真正触发指数退避，必须显式启用并配置 ExponentialBackOffPolicy，而不仅仅是设置 initial-interval 和 multiplier。否则这些参数会被忽略。
-
spring.rabbitmq.listener.simple.retry.enabled=true只是打开重试开关，不等于启用退避 -
initial-interval、multiplier、max-interval这三个参数只有在底层重试模板绑定了ExponentialBackOffPolicy实例时才生效 - Spring Boot 2.3+ 自动装配的
RetryTemplate默认仍用SimpleBackOffPolicy，需手动覆盖
如何在 @Configuration 中正确注入 ExponentialBackOffPolicy
不能只靠 application.yml 配置，必须通过 Java Config 显式注册带退避策略的 RetryTemplate，否则 multiplier 等参数形同虚设。
以下是最小可靠配置：
@Configuration
public class RabbitRetryConfig {
@Bean
public RetryTemplate retryTemplate() {
RetryTemplate template = new RetryTemplate();
// 重试策略：最多 5 次（含首次）
SimpleRetryPolicy retryPolicy = new SimpleRetryPolicy();
retryPolicy.setMaxAttempts(5);
template.setRetryPolicy(retryPolicy);
// 退避策略：指数增长，初始 1s，乘子 2，上限 30s
ExponentialBackOffPolicy backOffPolicy = new ExponentialBackOffPolicy();
backOffPolicy.setInitialInterval(1000);
backOffPolicy.setMultiplier(2.0);
backOffPolicy.setMaxInterval(30000);
template.setBackOffPolicy(backOffPolicy);
return template;
}
}
- 必须把该
RetryTemplate注入到监听器容器工厂中，否则不会生效 - 若使用
@RabbitListener+@EnableRabbit，还需确保SimpleRabbitListenerContainerFactory引用了这个retryTemplate - 不要试图在
@RabbitListener方法里 catch 异常并手动重试——这会绕过 Spring 的重试拦截器，ACK 行为失控
default-requeue-rejected=false 是死信队列的前提，不是可选项
重试耗尽后，消息必须被拒绝且不重新入队（requeue=false），才能进入死信流程。而 spring.rabbitmq.listener.simple.default-requeue-rejected=false 就是控制这个行为的关键开关。
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
如果漏配或配成 true，会出现两种危险情况：
- 消息不断打回原队列，被同一个消费者反复拉取，形成无限循环
- RabbitMQ 内存中堆积大量
Unacked消息，监控显示队列长度为 0，但实际内存占用飙升
配合死信队列，完整 yml 片段应类似：
spring:
rabbitmq:
listener:
simple:
retry:
enabled: true
max-attempts: 5
initial-interval: 1000
multiplier: 2.0
max-interval: 30000
default-requeue-rejected: false
注意：default-requeue-rejected 是 listener 级别开关，不是 retry 子项，位置错会导致整个配置失效。
重试失败后进死信队列，需要队列声明时绑定 DLX
即使 Spring 端拒绝了消息，RabbitMQ 也不会自动创建死信队列——它只负责路由。你必须提前声明业务队列时指定 x-dead-letter-exchange 和 x-dead-letter-routing-key。
常见错误是只配了 Spring 的 default-requeue-rejected=false，却没在队列定义里加 DLX 参数，结果重试失败的消息直接被丢弃（AMQP 协议默认行为）。
- DLX 必须是已存在的 exchange，类型通常为
direct或topic - 业务队列声明代码中需传入
Map<String, Object>参数，包含"x-dead-letter-exchange" - 死信队列本身不需要特殊声明，只要被 DLX 正确绑定即可
- 验证方式：重试失败后，在 RabbitMQ 管理界面查看对应队列的
Dead letter exchange字段是否非空
最易被忽略的一点：重试策略只对监听器方法内抛出的未捕获异常生效；如果方法里吞掉了异常（比如 try-catch 后 return），Spring 根本收不到失败信号，重试机制完全静默失效。
