@Retryable和@Recover的使用踩坑记录

@Retryable和@Recover的使用踩坑记录

问题情境:

在项目中有调用第三方公司数据接口,因为调用该接口的时候存在不稳定因素,比如网络波动、接口数据返回超时等等,代码中做了重试策略,采用了@Retryable和@Recover组合的方式进行处理。

最开始的时候没有触发到托底操作,也就是@Recover方法的一直没有被执行,后面发现几次系统中的全局捕捉异常会抓到系统异常,由于日志加的不全,没有怀疑是托底操作的原因,后面发现是由于@Recover修饰的方法的返回值类型与@Retryable修饰方法的返回值类型不一致导致。

举例说明:

@Retryable(value = {RetryException.class},//指定发生的异常进行重试
            maxAttempts=3,                   //重试次数,默认即为3
            backoff = @Backoff(value = 2000))//每次重试延迟毫秒数
    public A retry () {
        log.info("retry start");
        throw new RetryException("retry fail");
        return A;
    }
    
    
    
@Recover
    public B recover (RetryException e) {
        log.info("recovery,{}",e.getMessage());
         // 这里返回的数据类型要与上面@Retryable 方法返回的数据类型一直,否则会报错
         
         return B;
    }    

上面@Retryable返回的数据类型为A,@Recover修饰的方法返回的数据类型为B,这样当然会有问题。

由于没加日志,这个问题找了很久,最后才考虑到重试3次失败的情景。
@Retryable和@Recover的使用踩坑记录_第1张图片

你可能感兴趣的:(java-后端语法相关,java,开发语言)