Java消息队列消费失败重试的核心是让异常自然传播而非手动捕获，需满足不吞异常、配置生效、确认模式匹配；RabbitMQ依赖Spring AMQP自动重试链，RocketMQ则通过返回值或异常显式声明重试意图，通用关键点包括避免try-catch吞异常、事务回滚配置一致、子线程异常不可传回等，重试耗尽后应转发DLQ、丢弃告警或落库告警。
Java 中消息队列消费失败时的重试，核心不是靠“捕获异常再手动抛出”，而是让异常自然传播、被框架捕获，从而触发内置重试流程。不同 MQ 实现机制差异大，但逻辑主线一致：**不吞异常 + 配置生效 + 确认模式匹配**。
RabbitMQ：依赖 Spring AMQP 自动重试链
必须满足三个前提才能触发重试：
- 开启重试配置：
spring.rabbitmq.listener.simple.retry.enabled=true - 确认模式为
auto（不能是manual或none） - @RabbitListener 方法内不 try-catch 吞掉异常——哪怕只 log 一句也不 throw，都会中断重试
Spring 默认对所有 RuntimeException 和未捕获的检查异常（如 IOException）都尝试重试。若需排除某些异常（如 IllegalArgumentException），可自定义 RetryPolicy。
RocketMQ：靠返回值或异常显式声明重试意图
消费者端不依赖“抛异常自动重试”，而是由业务代码主动反馈状态：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 集群消费下，返回
ConsumeConcurrentlyStatus.RECONSUME_LATER或直接抛出任意异常 → 触发重试 - 返回
ConsumeConcurrentlyStatus.CONSUME_SUCCESS或 catch 异常后 return SUCCESS → 消息被确认，不再重试 - 可通过
msg.getReconsumeTimes()获取当前已重试次数，用于业务判断（例如第 3 次失败就转人工）
默认最多重试 16 次，间隔按固定序列递增（1s→5s→10s→…→2h），超限后进死信队列（DLQ）。
通用关键点：避免重试失效的典型错误
以下写法会让重试完全失效，务必规避：
- @RabbitListener 方法里写
try { ... } catch (Exception e) { log.error(...); }却不 re-throw - 加了
@Transactional，但rollbackFor没覆盖实际抛出的异常类型，导致事务不回滚、重试不联动 - 在监听器中调用
@Async方法，异常发生在子线程，无法传回监听器主线程 - 没配
MessageRecoverer，重试耗尽后默认basicNack(requeue=true)，造成无限循环
重试失败后怎么兜底
重试不是万能的，耗尽后必须有明确归宿：
-
转发死信队列（推荐）：配
RepublishMessageRecoverer，消息带原始异常头信息进入 DLX/DLQ，便于排查和人工干预 -
丢弃并告警：用
RejectAndDontRequeueRecoverer，适合幂等强、可容忍丢失的场景（如日志类消息） -
落库+告警：自定义
MessageRecoverer，把消息体、堆栈、时间戳存入数据库表，触发企业微信/钉钉告警
