Spring-Retry应用

前言

spring retry是从spring batch独立出来的一个能功能，主要实现了重试和熔断。对于重试是有场景限制的，不是什么场景都适合重试，比如参数校验不合法、写操作等（要考虑写是否幂等）都不适合重试。远程调用超时、网络突然中断可以重试。在微服务治理框架中，通常都有自己的重试与超时配置，比如dubbo可以设置retries=1，timeout=500调用失败只重试1次，超过500ms调用仍未返回则调用失败。在spring retry中可以指定需要重试的异常类型，并设置每次重试的间隔以及如果重试失败是继续重试还是熔断（停止重试）。目前在spring cloud中已经渗透到诸多组件，如ribbon等，故本章对原生spring-retry的应用做个简单的梳理和案例分析。

本章概要

1、设计实现原理

2、案例实践：

• 重试策略：SimpleRetryPolicy固定重试次数
• 重试策略：SimpleRetryPolicy固定重试次数
• 重试策略：AlwaysRetryPolicy无限重试

• 重试策略：TimeoutRetryPolicy超时重试
• 重试策略：根据返回结果值实现重试
• 重试策略：启用熔断器重试策略
• 通过RetryListener实现拦截器模式
• 采用注解方式实现

设计实现原理

重试的定义： RetryOperations定义重试的API，RetryTemplate是API的模板模式实现，实现了重试和熔断。提供的API如下：

RetryCallback定义了需要执行重试的操作，定义好操作后，就是如何重试的问题了。 RetryTemplate通过制定不同的重试策略来执行如何重试的逻辑。默认的重试策略是SimpleRetryPlicy，也就是会重试3次。重试第1次如果成功后面就不会继续重试了。那么如果3尺都重试失败了呢？流程结束或者返回兜底结果。要返回兜底结果需要配置 RecoveyCallBack，从名字可以看出这是一个兜底回调接口，也就是重试失败后执行的逻辑。

重试策略，除了SimpleRetryPolicy还有其他重试策略，先来看下RetryPolicy接口：

方法说明：

• canRetry：在每次重试的时候调用，是否可以继续重试的判断条件 
• open：重试开始前调用，会创建一个重试上下文到RetryContext，保存重试的堆栈等信息 
• registerThrowable：每次重试异常时调用（有异常会继续重试）

以 SimpleRetryPolicy为例，当重试次数达到3（默认3次）停止重试，重试次数保存在重试上下文中。

所有重试策略实现如下：

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

重试回退(等待)策略，指的是每次重试是立即重试还是等待一段时间后重试。默认情况下是立即重试，如果需要配置等待一段时间后重试则需要指定回退策略 BackOffPolicy。 BackOffPolicy有如下实现：

• NoBackOffPolicy：无退避算法策略，每次重试时立即重试
• FixedBackOffPolicy：固定时间的退避策略，需设置参数sleeper和backOffPeriod，sleeper指定等待策略，默认是Thread.sleep，即线程休眠，backOffPeriod指定休眠时间，默认1秒
• UniformRandomBackOffPolicy：随机时间退避策略，需设置sleeper、minBackOffPeriod和maxBackOffPeriod，该策略在[minBackOffPeriod,maxBackOffPeriod之间取一个随机休眠时间，minBackOffPeriod默认500毫秒，maxBackOffPeriod默认1500毫秒
• ExponentialBackOffPolicy：指数退避策略，需设置参数sleeper、initialInterval、maxInterval和multiplier，initialInterval指定初始休眠时间，默认100毫秒，maxInterval指定最大休眠时间，默认30秒，multiplier指定乘数，即下一次休眠时间为当前休眠时间*multiplier
• ExponentialRandomBackOffPolicy：随机指数退避策略，引入随机乘数可以实现随机乘数回退

有状态重试 OR 无状态重试

所谓无状态重试是指重试在一个线程上下文中完成的重试，反之不在一个线程上下文完成重试的就是有状态重试。之前的SimpleRetryPolicy就属于无状态重试，因为重试是在一个循环中完成的。那么什么会后会出现或者说需要有状态重试呢？通常有两种情况：事务回滚和熔断。

如数据库操作异常DataAccessException，则不能执行重试，而如果抛出其他异常可以重试。

熔断的意思不在当前循环中处理重试，而是全局重试模式（不是线程上下文）。熔断会跳出循环，那么必然会丢失线程上下文的堆栈信息。那么肯定需要一种“全局模式”保存这种信息，目前的实现放在一个cache（map实现的）中，下次从缓存中获取就能继续重试了。

案例实践

场景描述：i作为计数器，如果i小于5则抛出异常，i会进行自增一操作，直到等于5方正常返回，否则根据重试策略进行重试操作，如果直到最后一直未重试成功，则返回Integer最大值。在重试上下文中添加一个value变量，后续通过其值实现根据返回值判断重试应用。最后打印最终的返回值。

示例代码：

private void run(RetryTemplate retryTemplate) throws Exception {

Integer result = retryTemplate.execute( new RetryCallback<Integer, Exception>() {

int i = 0 ;

// 重试操作

@Override

public Integer doWithRetry(RetryContext retryContext) throws Exception {

retryContext.setAttribute( "value" , i );

LOGGER .info( "retry {} times." , retryContext.getRetryCount());

return len( i ++);

}

}, new RecoveryCallback<Integer>() { //兜底回调

@Override