RabbitMQ延时插件消费异常时如何让消息按原延时时长自动重新入队

RabbitMQ 延时消息插件的x-delay参数仅在消息首次投递到延时交换机时触发时间计算逻辑。消费失败后直接调用basicNack/basicReject并设置requeue=true时，消息会直接回到原业务队列的头部，不会重新经过延时交换机做延时计算，因此会被立即消费。

方案1：消费失败手动重投到延时交换机（适配不同消息自定义延时时长场景） #

• 首次发送消息时，在消息自定义 Header 中新增两个字段：存储原始延时时长的x-original-delay（值和x-delay一致）、存储重试次数的x-retry-count（初始值为0）
• 消费逻辑执行异常时，不要执行requeue操作，先调用basicAck确认当前消费失败的消息
• 复制原消息的所有业务内容和 Header 信息，将x-retry-count值+1，x-delay值赋值为x-original-delay的取值，重新投递到原延时交换机，使用原路由键即可实现按原延时重试
• 增加重试次数上限控制，当x-retry-count超过预设阈值时，将消息投递到死信队列存储，避免无限重试占用资源

方案2：配合死信交换机实现重试延时（适配所有消息重试延时固定的场景） #

• 给业务队列配置死信交换机和死信路由键，指向一个新的延时队列，将该延时队列的消息过期时间设置为你需要的重试验时时长，同时配置该延时队列的死信交换机指向业务队列
• 消费逻辑执行异常时，直接调用basicNack(false, false)，让消息成为死信进入配置好的延时死信队列
• 消息在延时死信队列中过期后，会自动转发回业务队列，即可实现按固定时长延时重试
• 该方案同样需要配置重试次数上限，超过阈值的消息转死信队列人工处理

• 不要依赖RabbitMQ原生的requeue逻辑实现延时重试，该逻辑不会触发延时插件的计算规则
• 所有重试方案都必须配置重试次数上限，避免异常消息无限循环消耗MQ和业务服务资源

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