spring boot 全局异常处理无法直接捕获死信队列（dlq）中的消息，因为死信队列是 rabbitmq 等中间件在消息消费失败后自动转移的独立存储区，此时应用进程并未处于“正在处理该消息”的状态。要处理死信队列中的异常，必须为死信队列配置独立的消费者监听器，并在其中实现业务逻辑或重试策略。
如何配置死信队列并建立独立监听
通过声明 RabbitTemplate 和绑定关系，将正常队列的死信路由到专用死信队列，并使用 @RabbitListener 注解创建专门处理死信消息的消费者方法。
import org.springframework.amqp.core.*;
import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;
@Component
public class DeadLetterConfig {
public static final String NORMAL_QUEUE = "normal.queue";
public static final String DLQ_QUEUE = "dlq.queue";
public static final String DLX_EXCHANGE = "dlx.exchange";
public static final String DLX_ROUTING_KEY = "dlq.routing.key";
@Bean
public Queue normalQueue() {
return QueueBuilder.durable(NORMAL_QUEUE)
.withArgument("x-dead-letter-exchange", DLX_EXCHANGE)
.withArgument("x-dead-letter-routing-key", DLX_ROUTING_KEY)
.build();
}
@Bean
public DirectExchange dlxExchange() {
return new DirectExchange(DLX_EXCHANGE);
}
@Bean
public Binding dlqBinding() {
return BindingBuilder.bind(normalQueue())
.to(dlxExchange())
.with(DLX_ROUTING_KEY);
}
}
@Component
public class DlqConsumer {
@RabbitListener(queues = "dlq.queue")
public void handleDeadLetter(String message) {
System.out.println("Processing dead letter: " + message);
}
}
上述代码定义了正常队列 normal.queue，并通过参数指定其死信交换机 dlx.exchange 和路由键 dlq.routing.key。当消息在正常队列中因拒绝（NACK）且 requeue=false 而丢弃时，会被转发至死信队列 dlq.queue。DlqConsumer 类中的 handleDeadLetter 方法专门监听该死信队列，从而实现对异常消息的捕获和处理。
如何在死信消费者中区分异常类型
在死信消费者的监听方法中，可以通过解析消息头或自定义包装对象来识别导致消息进入死信队列的具体原因，如超时、拒绝或达到最大重试次数。
import com.rabbitmq.client.AMQP;
import org.springframework.amqp.core.Message;
import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;
@Component
public class IntelligentDlqConsumer {
@RabbitListener(queues = "dlq.queue")
public void processWithReason(Message message) {
AMQP.BasicProperties props = message.getProperties();
String reason = props.getHeaders().get("x-death-reason");
if ("max-retry".equals(reason)) {
System.out.println("Message exceeded max retries, moving to archive.");
} else if ("rejected".equals(reason)) {
System.out.println("Message was explicitly rejected, logging error.");
}
System.out.println("Dead Letter Content: " + new String(message.getBody()));
}
}
此示例展示了如何在 processWithReason 方法中访问消息属性。RabbitMQ 会在消息进入死信队列时自动添加 x-death 头信息，其中包含 reason 字段，指示消息被移入死信的原因。开发者可以根据这些原因执行不同的后续操作，例如将超过重试次数的消息归档，或将因业务逻辑拒绝的消息记录到错误日志中。这种方法确保了即使消息进入死信队列，也能根据其异常状态进行精细化处理。
死信队列消费者如何处理重复投递问题
由于死信队列本身不保证消息的唯一性，若原生产者未做幂等处理，死信消费者需自行实现去重逻辑以避免重复处理。
在 IntelligentDlqConsumer 的基础上，可以引入 Redis 或数据库唯一索引来标记已处理的死信消息 ID。例如，在处理消息前检查 Redis 中是否存在该消息的哈希值，若存在则跳过处理；若不存在则执行业务逻辑并写入 Redis。这种机制确保了即使死信队列中因网络波动等原因出现重复消息，系统也能保持数据一致性。此外，建议在死信消费者中设置合理的超时时间，防止因长时间阻塞影响其他消息的处理效率。
