Java 中的 7 种重试机制,还有谁不会?!

这篇具有很好参考价值的文章主要介绍了Java 中的 7 种重试机制,还有谁不会?!。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

随着互联网的发展项目中的业务功能越来越复杂,有一些基础服务我们不可避免的会去调用一些第三方的接口或者公司内其他项目中提供的服务,但是远程服务的健壮性和网络稳定性都是不可控因素。

在测试阶段可能没有什么异常情况,但上线后可能会出现调用的接口因为内部错误或者网络波动而出错或返回系统异常,因此我们必须考虑加上重试机制

重试机制 可以提高系统的健壮性,并且减少因网络波动依赖服务临时不可用带来的影响,让系统能更稳定的运行。

1. 手动重试

手动重试:使用 while 语句进行重试:

@Service
public class OrderServiceImpl implements OrderService {
 public void addOrder() {
     int times = 1;
     while (times <= 5) {
         try {
             // 故意抛异常
             int i = 3 / 0;
             // addOrder
         } catch (Exception e) {
             System.out.println("重试" + times + "次");
             Thread.sleep(2000);
             times++;
             if (times > 5) {
                 throw new RuntimeException("不再重试!");
             }
         }
     }
 }
}

运行上述代码:

Java 中的 7 种重试机制,还有谁不会?!

上述代码看上去可以解决重试问题,但实际上存在一些弊端:

  • 由于没有重试间隔,很可能远程调用的服务还没有从网络异常中恢复,所以有可能接下来的几次调用都会失败
  • 代码侵入式太高,调用方代码不够优雅
  • 项目中远程调用的服务可能有很多,每个都去添加重试会出现大量的重复代码

推荐一个开源免费的 Spring Boot 实战项目:

https://github.com/javastacks/spring-boot-best-practice

2. 静态代理

上面的处理方式由于需要对业务代码进行大量修改,虽然实现了功能,但是对原有代码的侵入性太强,可维护性差。所以需要使用一种更优雅一点的方式,不直接修改业务代码,那要怎么做呢?

其实很简单,直接在业务代码的外面再包一层就行了,代理模式在这里就有用武之地了。

@Service
public class OrderServiceProxyImpl implements OrderService {
    
    @Autowired
    private OrderServiceImpl orderService;

    @Override
    public void addOrder() {
        int times = 1;
        while (times <= 5) {
            try {
                // 故意抛异常
                int i = 3 / 0;
                orderService.addOrder();
            } catch (Exception e) {
                System.out.println("重试" + times + "次");
                try {
                    Thread.sleep(2000);
                } catch (InterruptedException ex) {
                    ex.printStackTrace();
                }
                times++;
                if (times > 5) {
                    throw new RuntimeException("不再重试!");
                }
            }
        }
        
    }
}

这样,重试逻辑就都由代理类来完成,原业务类的逻辑就不需要修改了,以后想修改重试逻辑也只需要修改这个类就行了

代理模式虽然要更加优雅,但是如果依赖的服务很多的时候,要为每个服务都创建一个代理类,显然过于麻烦,而且其实重试的逻辑都大同小异,无非就是重试的次数和延时不一样而已。如果每个类都写这么一长串类似的代码,显然,不优雅!

3. JDK 动态代理

这时候,动态代理就闪亮登场了。只需要写一个代理处理类就 ok 了

public class RetryInvocationHandler implements InvocationHandler {

    private final Object subject;

    public RetryInvocationHandler(Object subject) {
        this.subject = subject;
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        int times = 1;
        while (times <= 5) {
            try {
                // 故意抛异常
                int i = 3 / 0;
                return method.invoke(subject, args);
            } catch (Exception e) {
                System.out.println("重试【" + times + "】次");
                try {
                    Thread.sleep(2000);
                } catch (InterruptedException ex) {
                    ex.printStackTrace();
                }
                times++;
                if (times > 5) {
                    throw new RuntimeException("不再重试!");
                }
            }
        }
        return null;
    }

    public static Object getProxy(Object realSubject) {
        InvocationHandler handler = new RetryInvocationHandler(realSubject);
        return Proxy.newProxyInstance(handler.getClass().getClassLoader(), realSubject.getClass().getInterfaces(), handler);
    }

}

测试:

@RestController
@RequestMapping("/order")
public class OrderController {

    @Qualifier("orderServiceImpl")
    @Autowired
    private OrderService orderService;

    @GetMapping("/addOrder")
    public String addOrder() {
        OrderService orderServiceProxy = (OrderService)RetryInvocationHandler.getProxy(orderService);
        orderServiceProxy.addOrder();
        return "addOrder";
    }
    
}

动态代理可以将重试逻辑都放到一块,显然比直接使用代理类要方便很多,也更加优雅。

这里使用的是JDK动态代理,因此就存在一个天然的缺陷,如果想要被代理的类,没有实现任何接口,那么就无法为其创建代理对象,这种方式就行不通了

4. CGLib 动态代理

既然已经说到了 JDK 动态代理,那就不得不提 CGLib 动态代理了。使用 JDK 动态代理对被代理的类有要求,不是所有的类都能被代理,而 CGLib 动态代理则刚好解决了这个问题

@Component
public class CGLibRetryProxyHandler implements MethodInterceptor {

    private Object target;

    @Override
    public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
        int times = 1;
        while (times <= 5) {
            try {
                // 故意抛异常
                int i = 3 / 0;
                return method.invoke(target, objects);
            } catch (Exception e) {
                System.out.println("重试【" + times + "】次");
                try {
                    Thread.sleep(2000);
                } catch (InterruptedException ex) {
                    ex.printStackTrace();
                }
                times++;
                if (times > 5) {
                    throw new RuntimeException("不再重试!");
                }
            }
        }
        return null;
    }

    public Object getCglibProxy(Object objectTarget){
        this.target = objectTarget;
        Enhancer enhancer = new Enhancer();
        enhancer.setSuperclass(objectTarget.getClass());
        enhancer.setCallback(this);
        Object result = enhancer.create();
        return result;
    }

}

测试:

@GetMapping("/addOrder")
public String addOrder() {
    OrderService orderServiceProxy = (OrderService) cgLibRetryProxyHandler.getCglibProxy(orderService);
    orderServiceProxy.addOrder();
    return "addOrder";
}

这样就很棒了,完美的解决了 JDK 动态代理带来的缺陷。优雅指数上涨了不少。

但这个方案仍旧存在一个问题,那就是需要对原来的逻辑进行侵入式修改,在每个被代理实例被调用的地方都需要进行调整,这样仍然会对原有代码带来较多修改

5. 手动 Aop

考虑到以后可能会有很多的方法也需要重试功能,咱们可以将重试这个共性功能通过 AOP 来实现,使用 AOP 来为目标调用设置切面,即可在目标方法调用前后添加一些重试的逻辑

<dependency>
    <groupId>org.aspectj</groupId>
    <artifactId>aspectjweaver</artifactId>
</dependency>

自定义注解:

@Documented
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface MyRetryable {
    
    // 最大重试次数
    int retryTimes() default 3;
    // 重试间隔
    int retryInterval() default 1;

}
@Slf4j
@Aspect
@Component
public class RetryAspect {

    @Pointcut("@annotation(com.hcr.sbes.retry.annotation.MyRetryable)")
    private void retryMethodCall(){}

    @Around("retryMethodCall()")
    public Object retry(ProceedingJoinPoint joinPoint) throws InterruptedException {
        // 获取重试次数和重试间隔
        MyRetryable retry = ((MethodSignature)joinPoint.getSignature()).getMethod().getAnnotation(MyRetryable.class);
        int maxRetryTimes = retry.retryTimes();
        int retryInterval = retry.retryInterval();

        Throwable error = new RuntimeException();
        for (int retryTimes = 1; retryTimes <= maxRetryTimes; retryTimes++){
            try {
                Object result = joinPoint.proceed();
                return result;
            } catch (Throwable throwable) {
                error = throwable;
                log.warn("调用发生异常,开始重试,retryTimes:{}", retryTimes);
            }
            Thread.sleep(retryInterval * 1000L);
        }
        throw new RuntimeException("重试次数耗尽", error);
    }

}

给需要重试的方法添加注解 @MyRetryable

@Service
public class OrderServiceImpl implements OrderService {

    @Override
    @MyRetryable(retryTimes = 5, retryInterval = 2)
    public void addOrder() {
        int i = 3 / 0;
        // addOrder
    }
    
}

这样即不用编写重复代码,实现上也比较优雅了:一个注解就实现重试。

6. spring-retry

Spring Boot 基础就不介绍了,推荐看这个实战项目:

https://github.com/javastacks/spring-boot-best-practice

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

开启重试功能:在启动类或者配置类上添加 @EnableRetry 注解

在需要重试的方法上添加 @Retryable 注解

@Slf4j
@Service
public class OrderServiceImpl implements OrderService {

    @Override
    @Retryable(maxAttempts = 3, backoff = @Backoff(delay = 2000, multiplier = 2))
    public void addOrder() {
        System.out.println("重试...");
        int i = 3 / 0;
        // addOrder
    }

    @Recover
    public void recover(RuntimeException e) {
        log.error("达到最大重试次数", e);
    }
    
}

该方法调用后会进行重试,最大重试次数为 3,第一次重试间隔为 2s,之后以 2 倍大小进行递增,第二次重试间隔为 4 s,第三次为 8s

Spring 的重试机制还支持很多很有用的特性,由三个注解完成:

  • @Retryable
  • @Backoff
  • @Recover

查看 @Retryable 注解源码:指定异常重试、次数

public @interface Retryable {

 // 设置重试拦截器的 bean 名称
    String interceptor() default "";
 
 // 只对特定类型的异常进行重试。默认:所有异常
    Class<? extends Throwable>[] value() default {};
 
 // 包含或者排除哪些异常进行重试
    Class<? extends Throwable>[] include() default {};
    Class<? extends Throwable>[] exclude() default {};
 
 // l设置该重试的唯一标志,用于统计输出
    String label() default "";

    boolean stateful() default false;
 
 // 最大重试次数,默认为 3 次
    int maxAttempts() default 3;
 
 
    String maxAttemptsExpression() default "";
 
 // 设置重试补偿机制,可以设置重试间隔,并且支持设置重试延迟倍数
    Backoff backoff() default @Backoff;
 
 // 异常表达式,在抛出异常后执行,以判断后续是否进行重试
    String exceptionExpression() default "";

    String[] listeners() default {};
}

@Backoff 注解: 指定重试回退策略(如果因为网络波动导致调用失败,立即重试可能还是会失败,最优选择是等待一小会儿再重试。决定等待多久之后再重试的方法。通俗的说,就是每次重试是立即重试还是等待一段时间后重试)

@Recover 注解: 进行善后工作:当重试达到指定次数之后,会调用指定的方法来进行日志记录等操作

注意:
  • @Recover 注解标记的方法必须和被 @Retryable 标记的方法在同一个类中
  • 重试方法抛出的异常类型需要与 recover() 方法参数类型保持一致
  • recover() 方法返回值需要与重试方法返回值保证一致
  • recover() 方法中不能再抛出 Exception,否则会报无法识别该异常的错误

这里还需要再提醒的一点是,由于 Spring Retry 用到了 Aspect 增强,所以就会有使用 Aspect 不可避免的坑——方法内部调用,如果被 @Retryable 注解的方法的调用方和被调用方处于同一个类中,那么重试将会失效

通过以上几个简单的配置,可以看到 Spring Retry 重试机制考虑的比较完善,比自己写AOP实现要强大很多

弊端:

但也还是存在一定的不足,Spring的重试机制只支持对 异常 进行捕获,而无法对返回值进行校验

@Retryable
public String hello() {
    long current = count.incrementAndGet();
    System.out.println("第" + current +"次被调用");
    if (current % 3 != 0) {
        log.warn("调用失败");
        return "error";
    }
    return "success";
}

因此就算在方法上添加 @Retryable,也无法实现失败重试

除了使用注解外,Spring Retry 也支持直接在调用时使用代码进行重试:

@Test
public void normalSpringRetry() {
    // 表示哪些异常需要重试,key表示异常的字节码,value为true表示需要重试
    Map<Class<? extends Throwable>, Boolean> exceptionMap = new HashMap<>();
    exceptionMap.put(HelloRetryException.class, true);
 
    // 构建重试模板实例
    RetryTemplate retryTemplate = new RetryTemplate();
 
    // 设置重试回退操作策略,主要设置重试间隔时间
    FixedBackOffPolicy backOffPolicy = new FixedBackOffPolicy();
    long fixedPeriodTime = 1000L;
    backOffPolicy.setBackOffPeriod(fixedPeriodTime);
 
    // 设置重试策略,主要设置重试次数
    int maxRetryTimes = 3;
    SimpleRetryPolicy retryPolicy = new SimpleRetryPolicy(maxRetryTimes, exceptionMap);
 
    retryTemplate.setRetryPolicy(retryPolicy);
    retryTemplate.setBackOffPolicy(backOffPolicy);
 
    Boolean execute = retryTemplate.execute(
        //RetryCallback
        retryContext -> {
            String hello = helloService.hello();
            log.info("调用的结果:{}", hello);
            return true;
        },
        // RecoverCallBack
        retryContext -> {
            //RecoveryCallback
            log.info("已达到最大重试次数");
            return false;
        }
    );
}

此时唯一的好处是可以设置多种重试策略:

  • NeverRetryPolicy:只允许调用RetryCallback一次,不允许重试
  • AlwaysRetryPolicy:允许无限重试,直到成功,此方式逻辑不当会导致死循环
  • SimpleRetryPolicy:固定次数重试策略,默认重试最大次数为3次,RetryTemplate默认使用的策略
  • TimeoutRetryPolicy:超时时间重试策略,默认超时时间为1秒,在指定的超时时间内允许重试
  • ExceptionClassifierRetryPolicy:设置不同异常的重试策略,类似组合重试策略,区别在于这里只区分不同异常的重试
  • CircuitBreakerRetryPolicy:有熔断功能的重试策略,需设置3个参数openTimeout、resetTimeout和delegate
  • CompositeRetryPolicy:组合重试策略,有两种组合方式,乐观组合重试策略是指只要有一个策略允许即可以重试,悲观组合重试策略是指只要有一个策略不允许即可以重试,但不管哪种组合方式,组合中的每一个策略都会执行

7. guava-retry

和 Spring Retry 相比,Guava Retry 具有更强的灵活性,并且能够根据 返回值 来判断是否需要重试

<dependency>
    <groupId>com.github.rholder</groupId>
    <artifactId>guava-retrying</artifactId>
    <version>2.0.0</version>
</dependency>
@Override
public String guavaRetry(Integer num) {
    Retryer<String> retryer = RetryerBuilder.<String>newBuilder()
            //无论出现什么异常,都进行重试
            .retryIfException()
            //返回结果为 error时,进行重试
            .retryIfResult(result -> Objects.equals(result, "error"))
            //重试等待策略:等待 2s 后再进行重试
            .withWaitStrategy(WaitStrategies.fixedWait(2, TimeUnit.SECONDS))
            //重试停止策略:重试达到 3 次
            .withStopStrategy(StopStrategies.stopAfterAttempt(3))
            .withRetryListener(new RetryListener() {
                @Override
                public <V> void onRetry(Attempt<V> attempt) {
                    System.out.println("RetryListener: 第" + attempt.getAttemptNumber() + "次调用");
                }
            })
            .build();
    try {
        retryer.call(() -> testGuavaRetry(num));
    } catch (Exception e) {
        e.printStackTrace();
    }
    return "test";
}

先创建一个Retryer实例,然后使用这个实例对需要重试的方法进行调用,可以通过很多方法来设置重试机制:

  • retryIfException():对所有异常进行重试
  • retryIfRuntimeException():设置对指定异常进行重试
  • retryIfExceptionOfType():对所有 RuntimeException 进行重试
  • retryIfResult():对不符合预期的返回结果进行重试

还有五个以 withXxx 开头的方法,用来对重试策略/等待策略/阻塞策略/单次任务执行时间限制/自定义监听器进行设置,以实现更加强大的异常处理:

  • withRetryListener():设置重试监听器,用来执行额外的处理工作
  • withWaitStrategy():重试等待策略
  • withStopStrategy():停止重试策略
  • withAttemptTimeLimiter:设置任务单次执行的时间限制,如果超时则抛出异常
  • withBlockStrategy():设置任务阻塞策略,即可以设置当前重试完成,下次重试开始前的这段时间做什么事情

总结

从手动重试,到使用 Spring AOP 自己动手实现,再到站在巨人肩上使用特别优秀的开源实现 Spring Retry 和 Google guava-retrying,经过对各种重试实现方式的介绍,可以看到以上几种方式基本上已经满足大部分场景的需要:

  • 如果是基于 Spring 的项目,使用 Spring Retry 的注解方式已经可以解决大部分问题
  • 如果项目没有使用 Spring 相关框架,则适合使用 Google guava-retrying:自成体系,使用起来更加灵活强大

版权声明:本文为CSDN博主「sco5282」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。原文链接:https://blog.csdn.net/sco5282/article/details/131390099

近期热文推荐:

1.1,000+ 道 Java面试题及答案整理(2022最新版)

2.劲爆!Java 协程要来了。。。

3.Spring Boot 2.x 教程,太全了!

4.别再写满屏的爆爆爆炸类了,试试装饰器模式,这才是优雅的方式!!

5.《Java开发手册(嵩山版)》最新发布,速速下载!

觉得不错,别忘了随手点赞+转发哦!文章来源地址https://www.toymoban.com/news/detail-634560.html

到了这里,关于Java 中的 7 种重试机制,还有谁不会?!的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Nginx + Spring Boot 轻松实现负载均衡,还有谁不会??

    来源:虚无境的博客 地址:www.cnblogs.com/xuwujing/p/11953697.html 在介绍Nginx的负载均衡实现之前,先简单的说下负载均衡的分类,主要分为 硬件负载均衡和软件负载均衡 ,硬件负载均衡是使用专门的软件和硬件相结合的设备,设备商会提供完整成熟的解决方案,比如F5,在数据的

    2024年02月08日
    浏览(40)
  • ChatGPT拒绝做这5件事,还有20件它也不会做!

    导读 :自从ChatGPT和其他生成式AI应用程序出现以来,我们一直在探索我们可以用它们做什么。看起来ChatGPT可以做任何事情。但在本文中,我们将探讨ChatGPT不会或无法做的事情。 本文字数:1800,阅读时长大约:10分钟 自从ChatGPT和其他生成式AI应用程序出现以来,我们一直在

    2024年02月09日
    浏览(42)
  • 面试官:@Transactional(readOnly=true) 有什么用?还有谁不会?!

    原文翻译自:https://medium.com 今天,我想谈谈 Spring 提供的 @Transactional(readOnly = true) 。 之所以聊这个是因为我公司项目的代码里有很多 @Transactional(readOnly = true) ,用过的同学都说 @Transactional(readOnly = true) 提高了性能。先思考以下几点: @Transactional(readOnly = true) 是如何工作的,为

    2024年02月05日
    浏览(40)
  • Spring Boot 调用外部接口的 3 种方式,还有谁不会?!

    SpringBoot不仅继承了Spring框架原有的优秀特性,而且还通过简化配置来进一步简化了Spring应用的整个搭建和开发过程。 在Spring-Boot项目开发中,存在着本模块的代码需要访问外面模块接口,或外部url链接的需求, 比如在apaas开发过程中需要封装接口在接口中调用apaas提供的接口(

    2024年02月09日
    浏览(61)
  • Maven 打包跳过测试的 5 种方法,应有尽有,还有谁不会!?

    平时开发时的工作的话之主要负责写代码就行了,什么发布项目啊,好吧不是我们干的事。在我们的了解中打包发布项目应该不是一个困难的问题。 对,最简单的方法就行使用直接使用maven插件打包,甚至我们都不需要知道他是怎么实现的,插件能帮我们将项目打包为一个

    2023年04月18日
    浏览(50)
  • rabbitmq 重试机制

    RabbitMQ是一个开源的消息中间件,它提供了可靠的消息传递机制。当消息发送到RabbitMQ时,可能会出现一些问题,例如网络故障、消费者不可用等,导致消息无法成功发送或消费。为了解决这些问题,RabbitMQ提供了重试机制。 重试机制是指在消息发送或消费过程中,当出现错误

    2024年02月03日
    浏览(38)
  • RabbitMQ--重试机制

    原文网址:RabbitMQ--重试机制_IT利刃出鞘的博客-CSDN博客 说明         本文介绍RabbitMQ的重试机制。 问题描述         消费者默认是自动提交,如果消费时出现了RuntimException,会导致消息直接重新入队,再次投递(进入队首),进入死循环,继而导致后面的消息被阻塞。

    2024年02月02日
    浏览(54)
  • kafka消费失败重试机制

    1.kafka批量消费消息,使用containerFactory 监听消费失败消息  2.使用RetryingBatchErrorHandler 指定批量消费时失败消息的重试次数和时间,如果不是批量消费,则使用RetryingErrorHandler来指定重试次数和间隔时间

    2024年02月11日
    浏览(35)
  • RabbitMQ异步与重试机制

            先来回顾一下前文,我们先基于Java原生语言,利用多线程和锁实现了串行/并行任务(Java串行/并行任务实现);之后利用SpringBoot为我们封装好的功能,尝试用SpringBoot自带的API实现了异步调用,并在此基础上,统一管理了多线程的事务(SpringBoot异步任务及并行事务实

    2024年02月07日
    浏览(37)
  • Springboot 中接口服务重试机制

    在平时开发中可能在调用服务时会遇到调用失败的情况,在springboot 中retery 机制可以很好的满足我们的开发场景,下面举个简单的例子模拟第三方调用。 使用起来很简单,只需要在引入相关jar,并且在启动的时候进行开启,这是springboot 的老套路,在我们服务层进行 @Retryabl

    2024年01月22日
    浏览(35)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包