做后端这些年凡是和 RabbitMQ 打过交道的项目几乎都逃不过“消息重试”这个坎。消息投进去很容易消费者一处理就报错才是最折磨人的数据库连接超时、下游接口抖了一下、序列化格式对不上没有一套可靠的重试机制整个异步链路就跟纸糊的一样。今天专门聊聊 RabbitMQ 重试机制从 ack 语义、Spring Boot 配置、死信队列延迟重试到幂等处理和问题排查全部捋一遍。这份内容适合正在用 RabbitMQ 做消息队列的开发者也适合准备面试时想系统梳理重试这块的同学。1. 为什么需要重试机制先搞清楚失败长什么样1.1 瞬时失败与永久失败是两种物种消息消费失败并不是所有失败都值得重试也不是所有失败重试了就能成功。我习惯把所有失败先分成两类这两类的处理哲学完全不同。第一类是瞬时失败比如数据库连接池瞬间打满、网络抖了一下、下游服务刚好在重启、Redis 超时。这类失败的特点是稍等片刻再去执行大概率就成功了。就好比你打电话给朋友对方正在占线等一下再拨就能接通。对于这类失败重试是有意义的而且必须有合理的间隔和次数不能死等也不能无限重试。第二类是永久失败比如消息里的 JSON 格式本身就不对、业务上这个订单编号根本不存在、状态机已经推进到了不允许再次流转的状态。这类失败哪怕重试一百遍也是同样的结果就像你把一封信寄给一个根本不存在的地址寄多少次都是退信。对永久失败重试不仅浪费资源还会让死信堆积、消费者线程被占住、正常消息排不上队最终拖垮整个消费链路。所以设计的第一个要点就是你需要在代码里区分异常类型。比如数据格式错误直接丢弃或者进死信而网络超时、数据库连接异常才走重试逻辑。很多团队不加区分所有异常一律丢给重试模板结果一条坏数据反复重试把好消息全部堵在后面这是最常见的坑。1.2 不重试和乱重试都有隐患有些同学图省事消费者方法里直接 try-catch 然后打印日志就算完事不抛异常、不 ack、也不 requeue。后果是消息被自动确认丢弃业务逻辑实际没执行成功账不平、数据缺失出了问题只能靠事后对账捞数据。这在订单、支付、库存这类核心链路里是完全不可接受的。另一种极端是乱重试。比如在 catch 块里写了个 while 循环只要失败就一直循环调用处理逻辑也不 sleep也不设置上限。一旦出现瞬时异常消费者线程就死循环在单条消息上CPU 飙升其他消息全部积压。更隐蔽的是结合 RabbitMQ 默认的 auto ack 行为消费者一旦抛出异常Broker 会把消息重新入队然后再次投递给消费者形成无限循环投递。表面上队列没堆积但实际一直在空转日志刷得飞快消息却永远处理不完。所以重试机制的本质不是“失败后重新跑一次”而是“用可控的代价在合适的时间把还有机会成功的消息再尝试几次”。这句话建议先记住后面所有设计都围绕它展开。2. 重试机制的底层原理从 ack 到 requeue2.1 ack、nack、reject 到底在干什么要理解 RabbitMQ 重试第一关就是消息确认机制。RabbitMQ 保证消息不丢失的前提是消费者必须明确告诉 Broker这条消息我处理好了你可以删了。这个动作就是 ackacknowledgement。在 Spring Boot 里消息确认有三种模式对应配置项spring.rabbitmq.listener.simple.acknowledge-mode模式行为适用场景none消费者收到消息后Broker 立即确认不管处理是否成功允许丢消息、对可靠性要求极低的场景不建议用于业务数据autoSpring 根据监听器方法是否抛异常自动确认或拒绝默认模式最常见但要注意异常后的 requeue 行为manual消费者代码里手动调用 channel.basicAck/basicNack/basicReject 确认需要对消息处理结果做精细控制的场景自动确认模式下如果监听器方法正常返回Spring 会帮你执行basicAck如果方法抛出异常Spring 会执行basicReject并且默认将requeue参数设为 true。这就导致了一个经典问题消息被拒绝后马上重新入队然后又被同一个消费者投递再次抛异常再次入队无限循环。手动确认模式下你有了完全的掌控权。处理成功就调用channel.basicAck(deliveryTag, false);处理失败可以调用basicNack或者basicReject关键在于第二个参数或第三个参数// 拒绝并重回队列 channel.basicNack(deliveryTag, false, true); // 拒绝并进入死信或丢弃 channel.basicNack(deliveryTag, false, false); channel.basicReject(deliveryTag, false);basicNack和basicReject的区别不复杂basicReject一次只能拒绝一条消息basicNack支持设置multiple参数批量拒绝。日常业务里用哪个都行我更习惯用basicNack因为语义更统一。2.2 requeue 是把双刃剑requeue这个参数是 RabbitMQ 重试机制里最容易被低估的设计。当它为 true 时消息会被重新放回原队列并且可能被立即再次投递给消费者。听起来好像方便了重试但实际上风险极大。消息被 requeue 后往往会放在队列比较靠前的位置如果消费者还是处理失败就会再次 requeue。这种模式没有任何退避间隔没有次数限制本质上就是一柄双刃剑用得好可以实现快速重试用得不好就是无限循环。在无法区分永久失败和瞬时失败、又不想做复杂设计的项目里我一般不推荐直接依赖requeuetrue做重试。更好的做法是设置requeuefalse让消息进入死信队列再由死信队列配合 TTL 来实现延迟重试。这样重试的节奏就由你自己控制而不是让 Broker 傻傻地立刻重新投递。3. 重试方案的三种设计思路3.1 方案一Spring Retry 同步重试Spring Boot 的spring-boot-starter-amqp内置了 Spring Retry 的支持你可以直接在配置文件中开关。它的工作方式是在消息进入监听器方法之前由RetryTemplate对方法的执行进行拦截。如果监听器抛出异常RetryTemplate会按照配置的间隔和次数原地重试都失败后再把最终异常交给MessageRecoverer。优点是实现成本极低不需要额外声明任何队列改几行配置文件就能生效。缺点是同步重试会阻塞消费者线程。比如设置重试 3 次每次间隔 5 秒那么最坏情况下一条消息要占住消费者线程 10 秒以上如果消费者线程数只有几个其他消息就被堵住了。所以这个方案适合重试次数少、间隔短、消息量不大、对实时性要求不高的场景。配置示例我放到第 4 节里细说这里先把位置记住spring.rabbitmq.listener.simple.retry.*。3.2 方案二基于死信队列的异步延迟重试这是我在生产环境用得最多、也最推荐的方案。核心思路是消费者处理失败后不 requeue而是把消息拒收让它进入死信交换机DLX再由死信交换机路由到死信队列。死信队列或者后续的消费逻辑负责在一段时间后把消息重新投递到业务队列完成延迟重试。为什么叫“异步延迟重试”因为它不占消费者线程失败的消息立刻被转走消费者可以继续处理后面的好消息。等到延迟时间到了再回过来处理这条失败消息。这和同步重试在思维方式上完全不同同步重试是“我原地等一下再试”异步重试是“我先放到等待室时间到了再回来”。要实现这个方案至少需要两类队列业务队列消费者监听这个队列处理消息并配置x-dead-letter-exchange和x-dead-letter-routing-key指向死信交换机。等待重试队列死信队列可以设置 TTL消息到期后投递给消费者消费者再把消息发回业务队列或者直接在这里执行业务逻辑。如果你使用的是 RabbitMQ 3.9 以上版本还可以考虑官方延迟消息插件rabbitmq_delayed_message_exchange它可以给单条消息设置不同的延迟时间比固定 TTL 的死信队列更灵活。不过延迟插件本质上是把消息存放在交换机内部生产环境使用前要先做压测确认性能和版本兼容性。3.3 方案三消费方手动重试与定时补偿有些场景不适合依赖 MQ 基建做重试。比如你的消费者是一个定时任务需要扫描数据库里某个状态为“待处理”的记录然后调用外部接口。此时你没必要把失败的东西发回队列直接在业务表里记下失败次数和下次执行时间由定时任务统一捞取重试会更直观、更好监控。另外还有一种常见做法本地维护一张“消息重试表”消费者处理失败后把消息原样或者转换后的业务数据写入重试表状态标记为 FAILED。后台再起一个定时任务每隔一段时间扫描这张表把到期的记录重新投递到 MQ 或者直接调用处理逻辑。这种方案的优点是重试状态完全可以自定义方便人工介入而且可以灵活设置重试上限、截止时间、告警通知。缺点是引入了额外的表和定时任务代码量多一些。方案三没有统一标准我通常用它做兜底实时重试全部失败后进入人工处理通道或者对账任务避免一条脏数据卡住整条链路。3.4 方案选型对照表方案延迟能力对消费线程影响复杂度典型场景Spring Retry 同步重试固定/退避间隔但阻塞线程高低少量消息、短间隔重试死信队列 TTL 异步重试可控制延迟不阻塞消费者低中生产环境主流方案适合消息量大手动重试与定时补偿灵活控制低中高强依赖外部服务、需要人工兜底方案没有银弹但你可以在一个系统里组合使用。比如实时重试用 Spring Retry 扛 3 次全部失败后发送到死信队列再由一个低优先级的消费者做定时补偿。这样既有快速响应的能力又不会因为单条坏消息拖垮整体消费速度。4. 实操Spring Boot 接入 RabbitMQ 重试4.1 基础依赖与队列声明先用 Spring Boot 跑通一个最简单的 RabbitMQ 消费者。在pom.xml里引入依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-amqp/artifactId /dependency连接信息配置在application.ymlspring: rabbitmq: host: 127.0.0.1 port: 5672 username: guest password: guest virtual-host: /这里的 virtual-host 需要注意一个细节默认的 guest 账号只能在/这个虚拟主机下访问。如果你换了 virtual-host需要用rabbitmqctl set_permissions或者管理界面给用户授权否则经常会出现“消息发不出去”“管理界面能打开但创建不了队列”之类的问题。这个和重试机制本身没关系但排查消息堆积时特别容易踩。声明业务队列和死信队列我建议用 Java Bean 的方式声明而不是只靠 RabbitMQ 管理界面手动创建。手动创建在本地测试没问题一上环境就崩代码里写清楚才可管理。Configuration public class RabbitConfig { Bean public Queue bizQueue() { return QueueBuilder.durable(biz.queue) .withArgument(x-dead-letter-exchange, dlx.exchange) .withArgument(x-dead-letter-routing-key, dlx.routing) .build(); } Bean public Queue dlxQueue() { return QueueBuilder.durable(dlx.queue) .withArgument(x-message-ttl, 5000) .build(); } Bean public DirectExchange bizExchange() { return new DirectExchange(biz.exchange); } Bean public DirectExchange dlxExchange() { return new DirectExchange(dlx.exchange); } Bean public Binding bizBinding() { return BindingBuilder.bind(bizQueue()).to(bizExchange()).with(biz.routing); } Bean public Binding dlxBinding() { return BindingBuilder.bind(dlxQueue()).to(dlxExchange()).with(dlx.routing); } }注意x-message-ttl是队列级别的 TTL所有发到这个死信队列的消息统一延迟 5 秒。如果你想让不同消息有不同延迟可以用消息属性里的expiration但不同的expiration消息堆积在一个队列里时RabbitMQ 只检查队列头部的过期消息可能出现延迟不准确的问题。所以生产环境追求精确延迟建议上延迟插件。4.2 配置消费端重试参数Spring Boot 里的同步重试配置很容易翻车因为不同版本对应配置前缀略有差异。以使用SimpleMessageListenerContainer为例在application.yml中可以这样配置spring: rabbitmq: listener: simple: acknowledge-mode: auto retry: enabled: true max-attempts: 3 initial-interval: 1000ms multiplier: 2 max-interval: 10000ms default-requeue-rejected: false几个参数解释一下enabled开启重试默认是 false。max-attempts最大尝试次数。注意它包含第一次执行所以设为 3 表示“第一次 重试两次”。initial-interval第一次重试前的等待时间。multiplier每次重试间隔的倍数。1 表示固定间隔2 表示指数退避即 1s、2s、4s。max-interval间隔上限防止倍数过大导致等待时间无限拉长。default-requeue-rejected这个非常关键设为 false 后Spring 在重试耗尽后不会把消息重新入队而会交给MessageRecoverer从而避免无限循环。如果你用的是DirectMessageListenerContainer把前缀改成spring.rabbitmq.listener.direct.retry.*即可配置语义是一样的。Spring Boot 2.x 和 3.x 在这个命名上保持了兼容但底层实现有优化建议使用较新的 Spring Boot 版本。4.3 配置 MessageRecoverer 决定最终失败去向重试次数耗尽后异常会被交给MessageRecoverer由它决定消息的最终命运。Spring AMQP 提供了几个现成的实现实现类行为RejectAndDontRequeueRecoverer直接拒绝消息不重新入队消息进入死信或丢弃ImmediateRequeueMessageRecoverer立即把消息放回原队列不推荐RepublishMessageRecoverer把失败消息重新发布到指定交换机适合做失败归档我强烈推荐RepublishMessageRecoverer。它把最终失败的消息重新发布到一个“失败交换机”后续可以由专门的任务去分析失败原因或者人工介入处理。这样原始消息不会被丢弃也不会无限循环。配置方式如下Bean public MessageRecoverer messageRecoverer(RabbitTemplate rabbitTemplate) { return new RepublishMessageRecoverer( rabbitTemplate, biz.exchange, biz.failed.routing ); }但需要注意RepublishMessageRecoverer重新发布消息时会把原始消息的x-death头带上同时附加一些重试信息。消费者在反序列化时不要因为这些额外的消息头报错最好用Map接收 headers 或者忽略未知头。4.4 监听器代码与手动 ack 写法一个标准的RabbitListener方法开启 Spring Retry 后我一般这样写Component public class BizConsumer { RabbitListener(queues biz.queue) public void onMessage(String message) { try { // 处理业务逻辑 processBusiness(message); } catch (DataFormatException e) { // 永久失败直接抛出特定异常或打日志后返回 log.error(消息格式错误无需重试, e); throw new PermanentFailException(e); } catch (Exception e) { // 瞬时失败交给 Spring Retry 处理 log.warn(消费失败准备重试, e); throw e; } } }这里的PermanentFailException需要结合自定义RetryPolicy才能区分。如果不做区分所有异常都会被重试。你可以实现RetryPolicy或者简单地在 catch 里对永久失败执行throw new AmqpRejectAndDontRequeueException(e)。这个异常是 Spring AMQP 专门提供的抛出后消息会直接拒绝且不重新入队。如果你使用手动 ack核心代码如下Component public class ManualAckConsumer { RabbitListener(queues biz.queue) public void onMessage(Message message, Channel channel) throws Exception { long deliveryTag message.getMessageProperties().getDeliveryTag(); try { processBusiness(message); channel.basicAck(deliveryTag, false); } catch (Exception e) { log.error(处理失败, e); // 这里可以根据重试次数决定 requeue 字段 channel.basicNack(deliveryTag, false, false); } } }手动 ack 配合requeuefalse时失败消息会进入死信队列。你可以在统一的死信消费方里判断x-death头里的count是否超过阈值如果没超过就重新发回业务队列如果超过了就记录日志转人工。实际上死信消费方可以做很多文章。比如从死信队列取出消息后检查x-death头RabbitListener(queues dlx.queue) public void onDlxMessage(Message message, Channel channel) throws Exception { MessageProperties props message.getMessageProperties(); ListMapString, ? xDeath props.getXDeathHeader(); long count ...; // 解析 x-death 中 count 字段 if (count 3) { // 重新发送到业务交换机 rabbitTemplate.convertAndSend(biz.exchange, biz.routing, new String(message.getBody())); } else { // 超过次数转人工或告警 alertService.sendAlert(...); } channel.basicAck(message.getMessageProperties().getDeliveryTag(), false); }这样一条消息最多被处理 3 次每次之间通过死信队列的 TTL 隔开既不阻塞消费者又能控制重试节奏。4.5 重试次数与退避间隔的计算关于重试参数很多人是拍脑袋定的。我的经验是不要对“最大重试次数”和“最大间隔”拍脑袋而是根据实际业务耗时来算。比如你的下游接口 P95 耗时 500ms最长抖动 5 秒内恢复那么你希望给这条消息最多的容忍时间是 15 秒左右。如果设置initial-interval1s, multiplier2, max-attempts5那么等待时间是 1 2 4 8 15 秒加上每次执行业务的时间总体约 17.5 秒。这个时间就是消费者线程被占用的时间。如果这个等待时间太长消费者线程池又只有 10 个那么吞吐量会明显下降。这时就应该放弃同步重试改用死信队列异步重试。核心判断依据永远是等待时间 * 并发消费者数 你能接受的消息积压延迟。超出这个范围就要换方案。5. 幂等性不解决幂等重试就是在给系统埋雷5.1 为什么重试必然带来重复消费消息重复消费不是重试机制的 bug而是分布式系统的常态。消费者处理成功、但在发送 ack 之前网络断了Broker 会认为消息没被处理重新投递或者同步重试时第一次执行其实成功了但返回响应之前抛了个超时异常第二次重试又会执行一遍。这些情况都会导致同一业务逻辑被多次执行。最典型的就是支付回调消费端处理订单付款成功消息如果重复执行可能给用户重复加积分、重复发短信、重复更新库存。所以任何面向业务的消费逻辑都必须默认“我可能被重复执行”。5.2 常用幂等方案与代码思路幂等方案没有银弹但可以组合使用。第一种是数据库唯一约束。比如处理“订单已完成”消息时往order_event_record表插入一条记录唯一的业务键是orderId eventType。重复插入时数据库会报唯一键冲突直接忽略即可。这是最可靠、最容易实现的方式。第二种是 Redis setNX。使用业务唯一键作为 key执行setIfAbsent只有第一次返回 true 才继续执行。但要注意设置过期时间避免 key 永久占用内存同时也要考虑 Redis 宕机后的兜底。第三种是业务状态机校验。比如订单状态只有“待支付 - 已支付 - 已发货”的顺序流转合法。每次处理消息前先从数据库查出当前状态如果已经是目标状态直接 return。这种方式不需要额外表但要求业务表有明确的状态字段。幂等还有一个容易忽略的点不仅要在消费端做幂等还要考虑重试发布。如果生产者把同一条消息发送了多次消费者也要能识别。常见做法是给每条消息生成一个全局唯一的messageId放在消息属性里消费者用messageId做去重。这样可以避免同一业务事件在消息层面重复进入消费流程。5.3 重试上下文传递在重试机制里幂等还需要和重试次数配合。当消息从业务队列进入死信队列再重新投递时你可能会带一些上下文信息。比如原始的业务操作时间、重试次数、上一次失败原因。这些建议放在消息头的自定义字段里而不是拼进消息体避免影响业务反序列化。示例发送重试消息时从死信头里解析次数并写入自定义 header。MessageBuilder.withBody(payload) .setContentType(MessageProperties.CONTENT_TYPE_JSON) .setHeader(x-retry-count, retryCount 1) .build();重试次数写入 header 后无论是监控、报警还是在消费端做条件判断都很方便。我见过不少团队把重试次数往 body 里塞结果所有消费方都要感知这个字段说不改动是假的特别容易埋雷。6. 常见问题与排查实录6.1 消息无限循环重投消费者空转现象日志里同一个异常反复出现队列的requeued指标持续飙升但消息就是处理不掉CPU 也很高。原因一般是自动确认模式下监听器抛异常后 Spring 默认把消息重新入队并且没有开启重试限制。解决办法是配置default-requeue-rejected: false或者开启spring.rabbitmq.listener.simple.retry.enabledtrue并使用MessageRecoverer。如果你手动 ack记得 failure 分支用basicNack(tag, false, false)不要用true无限 requeue。6.2 死信队列不生效失败消息直接消失队列声明了 DLX但消息失败后没有进入死信队列反而被直接丢弃。排查思路按顺序来先确认死信交换机是否真的存在并且类型、名称、routing key 都匹配。再确认原队列的x-dead-letter-exchange和x-dead-letter-routing-key是否设置正确。如果只有x-dead-letter-exchange没有x-dead-letter-routing-keyRabbitMQ 会使用原消息的 routing key 去路由当这个 routing key 在死信交换机上没有任何绑定时消息就会被丢弃。检查消费者是否使用的是手动 ack并且失败时确实传了requeuefalse。一直传true的话消息永远走不到死信。我遇到过最隐蔽的一次死信交换机名字拼错一个字母但本地环境一直正常因为本地有同名交换机生产环境则是另一个名字导致消息全部丢失。所以队列相关 Bean 的名称一定要用常量统一管理。6.3 重试间隔和次数设置了没效果常见场景是配置了spring.rabbitmq.listener.simple.retry.enabledtrue但监听器抛异常后立刻无限重试跟没配置一样。这时候先确认你的项目是不是用了多个RabbitListenerContainerFactory。如果你自定义了containerFactory并且没有把它指向配置文件里的属性Spring Boot 的自动配置不会生效。你需要手动给自定义工厂装配RetryTemplate。另外Spring Boot 2.0 之前和之后的配置属性名有变化如果你用的版本较老retry.enabled可能不在simple.listener下面而是spring.rabbitmq.listener.retry.enabled。遇到配置不生效先看启动日志里SimpleRabbitListenerContainerFactory的isRetryEnabled到底是什么值别靠猜。6.4 同步重试把消费者拖垮如果你的消费者线程数只有 5每条消息同步重试最长占用 15 秒那么理论吞吐量就已经低到没法看了。这时不要继续调大重试次数而应该改成异步延迟重试。保留一个极短暂的重试用于过滤偶发抖动比如重试 2 次间隔 1 秒然后直接 reject 进死信由死信队列做 30 秒或 1 分钟级别的重试。这样消费者线程能快速释放消息也不会因为瞬时故障立刻被丢弃。6.5 管理界面看到 unacked 持续堆积队列的unacked表示已经投递给消费者但还未确认的消息。如果你看到unacked一直很高而ready也不低通常不是重试参数的问题而是消费者处理速度太慢。结合日志看消费者线程是否长时间阻塞比如调用了外部接口没设超时、数据库连接池拿不到连接。重试机制只有在消息失败后才有意义如果消费者卡在处理过程中重试无法解决根因。我见过最夸张的一次是消费端调第三方接口没有设置连接超时TCP 连接全部挂起消息大量积压在unacked重试配置再完美也没用。另外插一句排查时的权限坑如果你用管理界面能看到队列但用定义的账号去消费时报 not allowed多半是该用户没有对应 virtual-host 的权限不要和重试机制搞混。先rabbitmqctl set_permissions授权再回头调重试逻辑。根据我个人的经验做重试机制最忌讳的是“一把梭”。不管什么异常都无限重试不如先花半天时间把失败类型梳理清楚。瞬时失败和永久失败分开了再决定用同步重试还是死信延迟重试。最后再分享一个小技巧生产环境务必监控队列的requeued、unacked、dead letter三个指标任何一个异常飙升都说明重试链路出问题了。消息重试不是为了制造更多消息而是为了让该成功的消息尽快成功该失败的消息尽快暴露给人类处理。把这句话想明白RabbitMQ 这块你基本就算玩明白了。