Spring Apache MQ容器化后如何区分消息重投递原因？

你的核心问题是JMS的isRedelivered无法区分「业务异常触发的重投」和「容器宕机/重启导致的预取消息重投」，以下是无需降低预取值、不影响性能的可行方案：

核心思路 #

放弃依赖Broker层面的isRedelivered标记，改为在业务异常触发重投时手动添加自定义属性，通过该属性明确区分两种重投场景，既保留业务异常的重投逻辑，又让宕机重启的预取消息按正常流程处理。

具体实现步骤 #

1. 修改业务逻辑判断条件
   不再使用msg.isRedelivered()，转而检查消息是否存在自定义属性businessFailed：

   • 若属性存在，判定为业务异常导致的重投，执行原有重投分支逻辑；
   • 若属性不存在，判定为首次处理（包括宕机重启后重投的预取消息），执行正常业务逻辑。

2. 业务异常时添加标记并回滚
   当捕获到需要触发重投的业务异常时，给当前消息添加businessFailed=true属性，再回滚事务，让消息携带该标记重新投递。

3. Spring JMS代码示例

   @JmsListener(destination = "your.target.queue")
   public void processMessage(Message message, Session session) throws JMSException {
       if (message.propertyExists("businessFailed")) {
           // 业务异常导致的重投，执行原有重投逻辑
           handleRedeliveredMessage(message);
           session.commit();
       } else {
           try {
               // 正常业务处理
               handleNormalMessage(message);
               session.commit();
           } catch (BusinessException ex) {
               // 标记为业务失败触发的重投
               message.setBooleanProperty("businessFailed", true);
               session.rollback();
           } catch (Exception ex) {
               // 非业务异常（如系统崩溃、网络问题），直接回滚，不添加标记
               session.rollback();
           }
       }
   }
   

关键注意事项 #

• 必须基于事务性会话（你已开启Session事务，符合要求），确保消息属性的修改能随事务回滚同步到Broker，下次投递时携带该属性；
• 非业务异常（如容器宕机、JVM崩溃）导致的重投，不会添加businessFailed标记，因此会走正常逻辑，完全匹配你的需求；
• 该方案完全保留预取策略（jms.prefetchPolicy.all=10）带来的性能提升，无需调整预取值。

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