实际工作中由于网络波动等原因导致代码执行失败需要重新执行,保证最终能够完成业务功能。通常来说,会用try/catch,while循环或者定时任务重处理。但是这样的做法缺乏统一性,要多写很多代码。spring-retry组件可以通过注解优雅的实现重处理功能。
重试在功能设计上需要根据应用场景进行设计，读数据的接口比较适合重试的场景，写数据的接口就需要注意接口的幂等性了，还有就是重试次数如果太多的话会导致请求量加倍，给后端造成更大的压力，设置合理的重试机制是关键；
Spring Retry重试框架
Spring boot使用spring retry重试机制
1.pom引用
<dependency>
<groupId>org.springframework.retry</groupId>
<artifactId>spring-retry</artifactId>
</dependency>2.应用启动类开启retry
@EnableRetry
public class Application {
.......
}3.在指定方法上标记@Retryable来开启重试
@Retryable(value={RuntimeException.class},maxAttempts=5,backoff = @Backoff(delay = 2000,multiplier = 1.5))
public void retryTest() throws Exception {
System.out.println(Thread.currentThread().getName()+" do something...");
throw new RuntimeException();
}value: 指定发生的异常进行重试
include: 和value一样，默认空，当exclude也为空时，所有异常都重试
exclude: 指定异常不重试，默认空，当include也为空时，所有异常都重试
maxAttemps: 重试次数，默认3
backoff: 重试补偿机制，默认没有
4.在指定方法上标记@Recover来开启重试失败后调用的方法(注意,需跟重处理方法在同一个类中)
@Recover
public void recover(RuntimeException e) {
// ... do something
}使用详解
spring-retry通过AOP实现对目的方法的封装，执行在当前线程下，所以重试过程中当前线程会堵塞。如果BackOff时间设置比较长，最好起异步线程重试（也可以加@Async注解）。
@Retryable注解
被注解的方法发生异常时会重试
value:指定发生的异常进行重试
include:和value一样，默认空，当exclude也为空时，所有异常都重试
exclude:指定异常不重试，默认空，当include也为空时，所有异常都重试
maxAttemps:重试次数，默认3
backoff:重试补偿机制，默认没有
@Backoff注解
delay:指定延迟后重试
multiplier:指定延迟的倍数，比如delay=5000l,multiplier=2时，第一次重试为5秒后，第二次为10秒，第三次为20秒
@Recover
当重试到达指定次数时，被注解的方法将被回调，可以在该方法中进行日志处理。需要注意的是发生的异常和入参类型一致时才会回调
spring-retry踩坑
一、@Retryable未生效可能原因
@Retryable方法必须为 public
下面情况下@Retryable不生效，即重试方法与调用它的非重试方法在同一个类中。
// 注意 此方法不生效！！！
@EnableRetry(proxyTargetClass = true)
class test{
public void methodA(){
methodB();
}
@Retryable
public void methodB(){
}
}解决方案：将重试方法单独写了一个Service。
3.每个类中对一种异常只有一个重试方法。两个重试方法捕捉Exception，重试失效。
二、@Recover未生效可能原因
①返回值必须和被重试的函数返回值一致；
②参数中除了第一个是触发的异常外，后面的参数需要和被重试函数的参数列表一致；
③当然这里的返回值部分也可以再做一次手动重试，但是已经尝试那么多次都失败了，所以在兜底函数中再做一次也意义不大。因此我的考虑是，这里就用来做日志记录就好。
