十分钟让你搞懂会用Spring Retry

本文介绍如何在Spring应用中使用Spring Retry来增强应用的鲁棒性。主要探讨了使用@Retryable注解和RetryTemplate两种方式来实现重试逻辑,以及如何自定义重试策略和监听器。

一、项目的配置

为了启用 Spring Retry 的支持,首先要在pom.xml 文件中添加以下依赖项

   <properties>
        <version.spring.retry>1.3.1</version.spring.retry>
    </properties>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework.retry</groupId>
                <artifactId>spring-retry</artifactId>
                <version>${version.spring.retry}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <dependencies>
        <dependency>
            <groupId>org.springframework.retry</groupId>
            <artifactId>spring-retry</artifactId>
        </dependency>
    </dependencies>

在这里我们使用的是maven中央仓库中最新的制品1.3.1。除了其本身的依赖,正常使用Spring Retry还需要 依赖AOP。对于Spring Boot 项目,在 pom.xml中添加 Spring-Boot-starter-aop starter

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-aop</artifactId>
        </dependency>

二、启用Spring Retry支持

为了启用Spring Retry的功能,需要向配置类添加@EnableRetry注释。

@SpringBootApplication
@EnableRetry
public class Launcher {
    public static void main(String[] args) {
        SpringApplication.run(Launcher.class, args);
    }
}

使用Retry的功能,有两种常见的方式,包括@Retryable注解到方法,以及RetryTemplate配置策略后手动去执行。

三、@Retryable 注解形式

3.1 @Retryable

注解方式就是在启用重试特性的方法上使用@Retryable注释。

我们提供一个接口,提供一个需要重试的方法,并为这个方式赋于改注解。

public interface RetryService {
    /**
     * 指定异常CustomRetryException重试,重试最大次数为4(默认是3),重试补偿机制间隔200毫秒
     * 还可以配置exclude,指定异常不充实,默认为空
     * @return result
     * @throws CustomRetryException 指定异常
     */
    @Retryable(value = {CustomRetryException.class},maxAttempts = 4,backoff = @Backoff(200))
    String retry() throws CustomRetryException;
}

注解参数的赋值内容解释见方法的注释。

  • value属性告诉 Spring retry 在方法在CustomRetryException异常出现时触发重试。

  • maxAttempts设置重试的最大次数,如果没有指定默认值为3。

  • backoff指定下次重试的延迟时间,默认值为1秒。

CustomRetryException异常是自定义的异常,代码如下

public class CustomRetryException extends Exception{
    public CustomRetryException(String error){
        super(error);
    }
}

3.2 @Recover

当被@Retryable注解的方法由于指定的异常而失败时,用于定义单独恢复方法的@Recover注释。

@Service
@Slf4j
public class RetryServiceImpl implements RetryService {

    private static int count = 1;

    @Override
    public String retry() throws CustomRetryException {
        log.info("retry{},throw CustomRetryException in method retry",count);
        count ++;
        throw new CustomRetryException("throw custom exception");
    }

    @Recover
    public String recover(Throwable throwable) {
        log.info("Default Retry service test");
        return "Error Class :: " + throwable.getClass().getName();
    }

}

3.3 测试

通过Junit进行单元测试。

    @Test
    void retry() {
        try {
            final String message = retryService.retry();
            log.info("message = "+message);
        } catch (CustomRetryException e) {
            log.error("Error while executing test {}",e.getMessage());
        }
    }

测试输出结果如下,符合预期,四次执行retry方法,最后一次执行结束后进入recover方法。

a77e9e674a3fb25288b99a45a377d43.png

四、RetryTemplate

RetryTemplate是使用注解形式重试的一种替代。

4.1 RetryOperations

使用 RetryOperations 接口的 Spring retry providesRetryOperations 策略。

public interface RetryOperations {

 <T> T execute(RetryCallback < T > retryCallback) throws Exception;
 // other execute methods

 <T> T execute(RetryCallback < T > retryCallback, RecoveryCallback < T > recoveryCallback,
  RetryState retryState) throws Exception;
}

RetryCallback允许插入在失败时需要重试的业务逻辑。

public interface RetryCallback <T> {
T doWithRetry(RetryContext context) throws Throwable;
}

4.2 RetryTemplate

RetryTemplate提供了RetryOperations的一种具体实现。它被认为是从中创建bean的良好做法。

    @Bean
    @ConditionalOnMissingBean
    public RetryTemplate retryTemplate(){
        final SimpleRetryPolicy simpleRetryPolicy = new SimpleRetryPolicy();
        simpleRetryPolicy.setMaxAttempts(4);

        final FixedBackOffPolicy fixedBackOffPolicy = new FixedBackOffPolicy();
        fixedBackOffPolicy.setBackOffPeriod(1000L);

        return RetryTemplate.builder()
            .customPolicy(simpleRetryPolicy)
            .customBackoff(fixedBackOffPolicy)
            .retryOn(CustomRetryException.class)
            .build();
    }

进行单元测试。

    
    @Autowired
    pivate RetryTemplate retryTemplate;

    @Test
    void retryWithoutAnnotation(){
        try {
            String message = retryTemplate.execute(x ->                  retryService.retryWithoutAnnotation());
            log.info("message = "+message);
        } catch (CustomRetryException e) {
            log.error("Error while executing test {}",e.getMessage());
        }
    }

如下图的输出结果所示,也是重试了四次,但是没有recover的策略。

fc44465528aeaf661622a9712a2aa3e.png

4.2 RecoveryCallback

execute时,可以选择输入RecoveryCallback回调,确定重试结束后,仍然出现异常的recovery行为。方法签名如下。

    public final <T, E extends Throwable> T execute(RetryCallback<T, E> retryCallback, RecoveryCallback<T> recoveryCallback) throws E {
        return this.doExecute(retryCallback, recoveryCallback, (RetryState)null);
    }

所以,我们先自定义RecoveryCallback

@Slf4j
public class CustomRecoveryCallback implements RecoveryCallback<String> {

    @Override
    public String recover(RetryContext retryContext) throws Exception {
        log.info("Default Retry service test,total retry {}",retryContext.getRetryCount());
        return "Error Class :: " + retryContext.getLastThrowable().getClass().getName();
    }
}

然后进行单元测试。

    @Autowired
    private CustomRecoveryCallback customRecoveryCallback;

    @Test
    void retryWithoutAnnotation(){
        try {
            String message = retryTemplate.execute(x -> retryService.retryWithoutAnnotation(), customRecoveryCallback);
            log.info("message = "+message);
        } catch (CustomRetryException e) {
            log.error("Error while executing test {}",e.getMessage());
        }
    }

如下图的输出结果所示,重试完成后,执行了我们自定义的recover

d5bfb79bc99998c1ba6ac3679df6c92.png

五、RetryListenerSupport

如果我们想在重试整个生命周期中,按照不同的阶段设置一些事件监听处理机制,那怎么办呢?设置自定义的RetryListenerSupport能帮助到我们。我们继承RetryListenerSupport,并重新Override close 、onErroropen方法,这三个方法分别表示

  • 所有重试结束时

  • 每一次重试发生异常时

  • 重试正式开始前。

@Slf4j
public class DefaultListenerSupport extends RetryListenerSupport {

    @Override
    public <T, E extends Throwable> void close(RetryContext context, RetryCallback<T, E> callback, Throwable throwable) {
        log.info("DefaultListenerSupport close");
        super.close(context, callback, throwable);
    }

    @Override
    public <T, E extends Throwable> void onError(RetryContext context, RetryCallback<T, E> callback, Throwable throwable) {
        log.info("DefaultListenerSupport onError");
        super.onError(context, callback, throwable);
    }

    @Override
    public <T, E extends Throwable> boolean open(RetryContext context, RetryCallback<T, E> callback) {
        log.info("DefaultListenerSupport open");
        return super.open(context, callback);
    }
}

并且在构造RetryTemaplate时候,设置withListener字段。

@Bean
@ConditionalOnMissingBean
public RetryListenerSupport retryListenerSupport(){
    return new DefaultListenerSupport();
}

@Bean
@ConditionalOnMissingBean
public RetryTemplate retryTemplate(RetryListenerSupport retryListenerSupport){

    ...
    
    return RetryTemplate.builder()
        .customPolicy(simpleRetryPolicy)
        .customBackoff(fixedBackOffPolicy)
        .withListener(retryListenerSupport)
        .retryOn(CustomRetryException.class)
        .build();
}

运行单元测试,输出结果如下。

六、总结

在这篇文章中,我们看到了 Spring retry的不同特性,我们清楚使用它能使应用程序更加健壮。我们实践了Spring Retry最为常见的几种用法,主要包括@Retryable 注释和 RetryTemplate

那么哪些地方我们能用到Spring Retry呢?有这两点建议

  • 仅在临时错误上使用重试。不建议它在永久错误中使用它,因为这样可能导致系统性能问题。

  • 它不是熔断器的替代的一种方式,最好在允许的情况下,既使用熔断器,又使用重试器。

<think>嗯,用户遇到了RabbitMQ的“Retry Policy Exhausted”错误,需要解决。我先回忆一下之前的引用内容。根据引用[1],Springretry机制是在消费端内部处理的,RabbitMQ本身并不知道这些重试。如果消费端重试次数用尽,消息就会被丢弃或进入死信队列。而引用[2]提到,使用channel.basicNack()可以让消息重新入队,但这样可能导致消息堆积,因为没有限制重试次数。 用户的问题是这个错误的原因和解决方法。首先,错误的原因是消费端配置的重试策略已达到最大次数,但消息仍未处理成功。可能的情况包括代码异常、依赖服务故障或资源不足。此外,如果重试用尽后没有正确处理消息,比如没有记录日志或转移到死信队列,消息就会丢失。 解决方法方面,首先要检查消费逻辑是否有BUG,添加日志记录和异常捕获。然后,调整重试参数,比如次数和间隔,避免过度重试。同时,配置死信队列,确保消息在重试失败后能转移到DLX,而不是丢失。另外,可以结合手动确认模式,使用basicNack让消息重新入队,但要注意设置最大重试次数,避免无限循环。最后,监控和告警机制也很重要,及时发现和处理问题。 需要确保用户正确配置了Spring Retry和死信队列,例如在application.yml中设置重试次数、开启重试,并定义交换机和队列的绑定。同时,手动确认模式下正确处理消息,避免漏确认导致重复消费。可能还需要考虑消息的TTL和死信路由,确保消息能正确转移。 用户可能需要具体的配置示例,比如代码片段或YAML配置,所以回答时要提供这些内容。另外,要提醒用户检查依赖服务是否正常,避免因外部服务故障导致持续失败。总结起来,解决方案包括调整配置、完善消费逻辑、设置死信队列和监控措施。</think>### RabbitMQ "Retry Policy Exhausted" 错误解析与解决方案 #### 错误原因 1. **消费端重试机制耗尽** - 当使用Spring Boot的`spring.rabbitmq.listener.retry`配置时,重试操作由消费端应用内部实现,RabbitMQ服务器并不感知此过程[^1] - 示例配置: ```yaml spring: rabbitmq: listener: retry: enabled: true max-attempts: 3 # 默认重试次数为3次 ``` - 当重试次数达到`max-attempts`阈值后仍未成功消费消息,会抛出该错误 2. **消息处理持续失败** - 消费代码中存在未处理的异常(如数据库连接失败、空指针异常) - 依赖的外部服务不可用 - 消息体格式与处理逻辑不匹配 3. **缺乏兜底处理机制** 重试耗尽后若未配置死信队列(DLX),消息会被直接丢弃[^2] --- #### 解决方案(分步实施) **1. 优化消费端逻辑** ```java @RabbitListener(queues = "your_queue") public void handleMessage(Message message, Channel channel) { try { // 业务处理逻辑 channel.basicAck(deliveryTag, false); // 手动确认 } catch (Exception e) { log.error("消息处理失败:{}", message.getBody(), e); channel.basicNack(deliveryTag, false, true); // 重新入队 } } ``` **2. 调整重试策略** ```yaml spring: rabbitmq: listener: retry: enabled: true max-attempts: 5 # 最大重试次数 initial-interval: 1000 # 初始间隔1秒 multiplier: 2.0 # 间隔倍数增长 max-interval: 10000 # 最大间隔10秒 ``` **3. 配置死信队列** ```java // 声明主队列绑定死信交换机 @Bean Queue mainQueue() { return QueueBuilder.durable("MAIN_QUEUE") .withArgument("x-dead-letter-exchange", "DLX_EXCHANGE") .withArgument("x-dead-letter-routing-key", "dlx.routingkey") .build(); } // 声明死信队列 @Bean Queue dlq() { return new Queue("DEAD_LETTER_QUEUE"); } ``` **4. 监控与告警** - 对死信队列实施监控 - 使用ELK或Prometheus收集错误日志 - 设置阈值告警(如每分钟死信消息超过10条) --- #### 进阶优化建议 1. **熔断机制**:集成Resilience4j实现熔断,当连续失败达到阈值时暂停消费 2. **消息TTL**:设置消息过期时间防止无限循环 ```java // 设置消息10分钟后过期 MessageProperties props = MessagePropertiesBuilder.newInstance() .setExpiration("600000").build(); ``` 3. **幂等处理**:添加消息去重机制,防止重复消费导致异常 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值