前言
在很多场景中，我们需要“重试”，重试意味着反复执行一段代码直至成功，或者重试多次无果后标记失败。“重试”的出发点有可能是为了保持状态的一致，也有可能是为了容忍被调用方短暂的不可用。“重试”逻辑有可能是同步执行，也有可能是异步执行。异步有可能是将信息存入数据库定时任务重试，也有可能是通过异步消息，利用消息的重试机制，等等，不一而论。
把“重试”逻辑进行抽象的目前知道的有两个，一个Spring Retry，另外一个是Guava Retrier。本文的目的一方面是为了简单记录下Spring Retry的原理；另一方面是为了学习Spring Retry是如何对“重试”方方面面进行抽象的。
简单使用
简单使用部分请参考：官方文档
Spring Retry提倡以注解的方式对方法进行重试，重试逻辑是同步执行的，重试的“失败”针对的是Throwable，如果你要以返回值的某个状态来判定是否需要重试，可能只能通过自己判断返回值然后显式抛出异常了。
Spring 对于Retry的抽象
“抽象”是每个程序员必备的素质。对于资质平平的我来说，没有比模仿与理解优秀源码更好地进步途径了吧。为此，我将其核心逻辑重写了一遍...下面就看看Spring Retry对于“重试”的抽象。
“重试”逻辑
while(someCondition()) {
try{
doSth();
break;
} catch(Throwable th) {
modifyCondition();
wait();
}
}
if(stillFail) {
doSthWhenStillFail();
}
同步重试代码基本可以表示为上述，但是Spring Retry对其进行了非常优雅地抽象，虽然主要逻辑不变，但是看起来却是舒服多了。主要的接口抽象如下图所示：
Spring retry相关接口.jpg
- RetryCallback: 封装你需要重试的业务逻辑（上文中的doSth）
- RecoverCallback：封装在多次重试都失败后你需要执行的业务逻辑(上文中的doSthWhenStillFail)
- RetryContext: 重试语境下的上下文，可用于在多次Retry或者Retry 和Recover之间传递参数或状态（在多次doSth或者doSth与doSthWhenStillFail之间传递参数）
- RetryOperations : 定义了“重试”的基本框架（模板），要求传入RetryCallback，可选传入RecoveryCallback；
- RetryListener：典型的“监听者”，在重试的不同阶段通知“监听者”（例如doSth，wait等阶段时通知）
- RetryPolicy : 重试的策略或条件，可以简单的进行多次重试，可以是指定超时时间进行重试（上文中的someCondition）
- BackOffPolicy: 重试的回退策略，在业务逻辑执行发生异常时。如果需要重试，我们可能需要等一段时间(可能服务器过于繁忙，如果一直不间隔重试可能拖垮服务器)，当然这段时间可以是0，也可以是固定的，可以是随机的（参见tcp的拥塞控制算法中的回退策略）。回退策略在上文中体现为wait()；
- RetryTemplate :RetryOperations的具体实现，组合了RetryListener[]，BackOffPolicy，RetryPolicy。
看到上文中的XXXOperations(包括其中的execute()方法)，XXXCallback,XXXTemplate是不是感觉很熟悉？没错，JDBCTemplate也是用的这一套抽象命名！
总结
简单记录了对于Spring Retry的学习，备忘！
