Spring Boot @SqsListener抛出异常时SQS消息的处理与重试问题

问题解答 #

1. 抛出异常时原SQS消息是否会保留在队列中？ #

会保留，但会进入隐藏（不可见）状态。因为你配置了acknowledgementMode = SqsListenerAcknowledgementMode.ON_SUCCESS，这个模式下只有监听器方法完全执行成功（无异常抛出），Spring才会向SQS发送DeleteMessage请求删除消息。如果方法抛出异常，不会发送删除请求，原消息留在队列中，但其可见性会被暂时屏蔽，屏蔽时长由队列的VisibilityTimeout参数决定（默认30秒），超时后消息会重新回到队列的可见状态，等待再次被消费。

2. 若保留，是否无需在catch块中重新发送原消息？ #

是的，完全不需要手动重新发送。原消息会在可见性超时后自动重回队列，重复消费逻辑由SQS原生机制处理。当前代码中手动发送消息的操作会导致重复消息堆积：原消息超时后回到队列，加上手动发送的副本，会出现两条完全相同的消息，后续可能引发重复处理问题，破坏数据一致性。

3. 若保留，能否配置延迟避免立即重发？ #

可以，有两种实现方式：

• 队列全局配置：修改SQS队列的VisibilityTimeout参数，直接延长消息的隐藏时长，比如设置为900秒（15分钟），这样消息第一次消费失败后，需等待900秒才会重回队列。
• 代码动态调整：如果需要针对特定异常设置不同延迟，可以在catch块中调用sqsTemplate.changeMessageVisibility()方法，修改当前失败消息的可见性超时时间。注意需要在监听器方法中接收消息的ReceiptHandle参数：

  // 监听器方法新增ReceiptHandle参数
  public void incomingNotification(@Payload String rawMessage, @Headers("ReceiptHandle") String receiptHandle) {
      try {
          SomeService.processNotification(rawMessage);
      } catch (RetryableException e) {
          // 动态设置当前消息的可见性超时为900秒
          sqsTemplate.changeMessageVisibility("${queue.name}", receiptHandle, 900);
      }
  }
  

4. 若不保留（比如使用其他确认模式），更优的重试方案有： #

• Spring Retry框架：在业务方法上添加@Retryable注解，配置重试次数、延迟、退避策略，搭配@Recover处理最终重试失败的场景，适合轻量级、无状态的重试需求：

  @Retryable(value = RetryableException.class, maxAttempts = 3, backoff = @Backoff(delay = 900000))
  @Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
  public void processNotification(String rawMessage) {
      // 业务逻辑：写入DB、发布SNS等
  }
  
  @Recover
  public void recover(RetryableException e, String rawMessage) {
      // 最终重试失败后的处理：如发送到死信队列
  }
  

• 死信队列（DLQ）机制：为主队列配置死信队列，当消息被消费的次数达到队列的MaxReceiveCount阈值时，自动转移到DLQ。DLQ中的消息可单独排查处理，避免阻塞主队列的正常消费。
• 自定义重试表：将需要重试的消息存入数据库表，记录重试次数、失败原因、下次重试时间等信息，通过定时任务扫描表中到期的消息进行重试。这种方式适合需要精细控制重试逻辑、或需要持久化重试状态的场景。

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