Spring AMQP事务模式下死信队列失效，如何配置监听器容器？

我之前也碰到过完全一样的场景——把RabbitMQ消息事务和外部数据库事务同步后，异常发生时消息总是重新入队，死活不肯进死信队列。后来才搞明白核心原因：当你给监听器容器配置外部PlatformTransactionManager时，消息的重新入队行为会绑定到事务回滚操作，默认的死信触发逻辑（reject/nack且requeue=false）会被事务回滚的优先级覆盖。

下面是我验证过的可行解决方案：

1. 用ChainedTransactionManager同步Rabbit和数据库事务 #

首先要把RabbitMQ的事务管理器和你的外部数据库事务管理器组合成链式事务管理器，确保两者的事务能同步提交/回滚：

@Bean
public ChainedTransactionManager combinedTransactionManager(
        RabbitTransactionManager rabbitTxManager,
        PlatformTransactionManager dbTxManager) {
    // 顺序很重要：先提交数据库事务，再提交Rabbit事务；回滚时顺序相反
    return new ChainedTransactionManager(dbTxManager, rabbitTxManager);
}

2. 配置监听器容器，绑定链式事务并自定义错误处理 #

接下来配置监听器容器，开启事务并绑定链式事务管理器，关键是要通过自定义错误处理器控制哪些异常需要触发死信：

@Bean
public SimpleMessageListenerContainer messageListenerContainer(
        ConnectionFactory connectionFactory,
        MessageListener yourBusinessMessageListener,
        ChainedTransactionManager combinedTransactionManager) {

    SimpleMessageListenerContainer container = new SimpleMessageListenerContainer(connectionFactory);
    container.setQueueNames("your-business-queue");
    container.setMessageListener(yourBusinessMessageListener);
    
    // 启用通道事务
    container.setChannelTransacted(true);
    // 绑定链式事务管理器，实现事务同步
    container.setTransactionManager(combinedTransactionManager);
    
    // 自定义错误处理器，标记致命异常
    container.setErrorHandler(new ConditionalRejectingErrorHandler(new FatalExceptionStrategy() {
        @Override
        public boolean isFatal(Throwable throwable) {
            // 这里定义哪些异常需要触发死信，比如业务异常、不可恢复的RuntimeException
            // 按需调整判断逻辑，非致命异常（如临时网络波动）不要标记为fatal，保留重试能力
            return throwable instanceof BusinessException || 
                   throwable instanceof NonTransientException;
        }
    }));
    
    // 关闭默认的异常重新入队，配合错误处理器生效
    container.setDefaultRequeueRejected(false);
    
    return container;
}

3. 确保业务队列已配置死信参数 #

这一步你应该已经配置过，但为了完整性再强调：业务队列必须绑定死信交换机和路由键，否则被拒绝的消息无法转入死信队列：

@Bean
public Queue businessQueue() {
    return QueueBuilder.durable("your-business-queue")
            .deadLetterExchange("dlx-exchange")
            .deadLetterRoutingKey("dlx-routing-key")
            .build();
}

@Bean
public DirectExchange dlxExchange() {
    return new DirectExchange("dlx-exchange");
}

@Bean
public Queue deadLetterQueue() {
    return QueueBuilder.durable("dead-letter-queue").build();
}

@Bean
public Binding dlxBinding() {
    return BindingBuilder.bind(deadLetterQueue())
            .to(dlxExchange())
            .with("dlx-routing-key");
}

为什么这套方案能解决问题？ #

• ChainedTransactionManager保证了数据库操作和消息消费的原子性：要么两者都提交，要么都回滚，满足你事务同步的需求。
• 自定义FatalExceptionStrategy标记致命异常后，容器会拒绝消息且不重新入队（defaultRequeueRejected=false），触发死信机制。
• 事务回滚会撤销数据库操作，同时消息被转入死信队列，不会出现重复消费的情况。

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