【RabbitMQ的x-death】始终为null的原因

在RabbitMQ中，x-death头部信息仅在消息成为死信（如被拒绝且不重新入队，或TTL过期）时才会被添加。当使用basicNack并设置requeue=true时，消息会重新回到队列头部，但不会触发死信机制，因此x-death始终为null。以下是对问题的具体分析和解决方案：

原因分析

1. x-death的生成条件
   x-death头仅在消息进入死信队列时由RabbitMQ自动添加。当消息通过basicNack或basicReject且requeue=false时，如果队列配置了死信交换器（DLX），消息会被转发到死信队列，此时才会记录x-death。

2. requeue=true的问题
   当前代码在失败时调用channel.basicNack(tag, false, true)（第三个参数requeue为true），导致消息重新入队但不触发死信机制，因此x-death不会被填充。只有最后一次调用basicReject(tag, false)（requeue=false）时，消息才会成为死信，但此时消息已不再由原消费者处理。

解决方案

方案1：通过死信队列追踪重试次数

1. 配置队列绑定死信交换器
   为原始队列设置DLX和TTL，使消息在多次重试后自动过期成为死信：

   @Bean
   public Queue originQueue() {
       return QueueBuilder.durable("origin.queue")
           .withArgument("x-dead-letter-exchange", "dlx.exchange")
           .withArgument("x-message-ttl", 5000) // 消息5秒后过期成为死信
           .build();
   }
   

2. 监听死信队列
   在死信队列的消费者中通过x-death获取重试次数，若超过阈值则持久化失败记录。

方案2：手动维护重试次数

在消息头中自定义重试计数器（如retry-count），每次消费失败时递增：

@RabbitHandler
public void itineraryAudit(Message message, Channel channel, @Header(AmqpHeaders.DELIVERY_TAG) long tag) throws IOException {
    MessageProperties properties = message.getMessageProperties();
    Map<String, Object> headers = properties.getHeaders();
    int retryCount = headers.containsKey("retry-count") ? (int) headers.get("retry-count") : 0;
    
    try {
        // 业务逻辑
    } catch (Exception e) {
        if (retryCount >= 2) {
            channel.basicReject(tag, false);
        } else {
            headers.put("retry-count", retryCount + 1);
            // 重新发布消息到原队列（注意避免循环）
            channel.basicPublish("", properties.getConsumerQueue(), 
                new AMQP.BasicProperties.Builder()
                    .headers(headers)
                    .build(),
                message.getBody());
            channel.basicAck(tag, false); // 确认原消息
        }
    }
}

总结

• x-death为null的根本原因：消息因requeue=true重新入队，未触发死信机制。
• 正确做法：通过DLX机制或手动维护重试次数，避免依赖x-death在非死信场景下的值。推荐使用方案1，由RabbitMQ自动管理重试和死信。