spring-rabbit结合spring-retry下x-message-ttl生效逻辑及异常行为咨询

1. 相关组件特性澄清 #

首先明确你配置涉及的几个核心机制的原生特性：

• Spring RetryInterceptor本地重试：你配置的maxAttempts=2指单条消息单次投递时最多触发2次消费尝试（含首次调用），两次尝试之间固定阻塞等待60s，这个重试是在消费者进程内完成的，重试过程中当前消费者线程被阻塞，不会处理其他消息，且消息不会归还给RabbitMQ Broker，保持unacked状态。Spring Retry的计数是单次投递的上下文级别的，消息被重新投递到消费者时会重置重试计数。
• RabbitMQ队列级TTL特性：x-message-ttl从消息入队时刻开始倒计时，requeue操作不会重置TTL计时；队列中存储的消息采用惰性过期检查：只有当消息成为队列头部时才会检查是否过期，过期则直接移入DLQ，不会投递给消费者。
• Unacked消息TTL规则：已经投递到消费者、处于unacked状态的消息（包括预取到消费者本地缓存、正在被处理/重试的消息），达到TTL阈值后，RabbitMQ Broker会主动将其回收并移入DLQ，不需要等消息回到队列头部。
• 重试耗尽默认行为：Spring RetryInterceptor重试次数耗尽后，默认会触发requeue操作，将消息扔回队列尾部，不会直接死信。
• 单消费者串行执行：你仅开启1个并发消费者，所有消费、重试操作都是串行执行，同一时间只能处理1条消息，默认的消费者预取数远大于8，8条消息入队后会被全部预取到消费者本地缓存。

2. 执行序列时间线拆解 #

我们以8条消息入队时刻为T0，TTL过期阈值为T0+125s，每轮重试间隔60s：

1. T0 ~ T0+120s
   • T0开始处理消息1：首次消费失败后阻塞60s，T0+60s完成第2次尝试，重试耗尽，消息1被requeue到队列尾部，此时消费者本地缓存剩余消息[2,3,4,5,6,7,8]
   • T0+60s开始处理消息2：首次消费失败后阻塞60s，T0+120s完成第2次尝试，重试耗尽，消息2被requeue到队列尾部，此时消费者本地缓存剩余消息[3,4,5,6,7,8]
2. T0+120s 及之后
   • T0+120s开始处理消息3：首次消费失败后进入60s等待，等待到T0+125s时，所有消息均达到TTL阈值，RabbitMQ开始主动回收消费者本地缓存中处于unacked状态的过期消息，回收顺序从缓存尾部开始，所以先回收7、8，对应你观测到的消息7过期、消息8过期
   • T0+180s：消息3完成第2次尝试，重试耗尽后requeue回队列，此时消息3早已超过TTL，回到队列后直接被检测到过期入DLQ，对应观测到的消息3过期
   • 后续消息4、5、6的处理逻辑和消息3完全一致：重试过程中就超过了TTL，重试耗尽requeue后直接入DLQ，对应观测到的消息4过期、消息5过期、消息6过期
   • 之前被requeue到队列尾部的消息1、2，TTL早已到期，被消费者再次拉取到的时候会重新触发重试逻辑（重试计数重置），所以会出现第3、4次消费尝试，消费过程中或者消费完成后被检测到过期入DLQ，对应你观测到的消息1、2的多次消费和最终过期。

3. 异常现象的根因 #

• 部分消息未消费就进DLQ：这些消息还在消费者预取缓存里没轮到处理，就达到TTL被Broker主动回收死信，不会触发消费逻辑
• 消费/过期顺序不符合预期：消息重试耗尽后会被requeue到队列尾部，打乱了原始入队顺序，且unacked消息的回收顺序是从缓存尾部开始，和原始入队顺序相反
• 消息出现超过配置maxAttempts的消费次数：消息被requeue后属于新的投递，会重置Spring Retry的计数，所以会触发多轮重试

内容的提问来源于stack exchange，提问作者abullor