Spring Retry 学习记录

前言

在很多场景中，我们需要“重试”，重试意味着反复执行一段代码直至成功，或者重试多次无果后标记失败。“重试”的出发点有可能是为了保持状态的一致，也有可能是为了容忍被调用方短暂的不可用。“重试”逻辑有可能是同步执行，也有可能是异步执行。异步有可能是将信息存入数据库定时任务重试，也有可能是通过异步消息，利用消息的重试机制，等等，不一而论。

把“重试”逻辑进行抽象的目前知道的有两个，一个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的学习，备忘！

参考文献

• https://github.com/spring-projects/spring-retry
• http://www.mscharhag.com/spring/spring-retry
• http://www.cnblogs.com/rollenholt/p/4711441.html
• http://iyiguo.net/blog/2016/01/17/spring-retry-simple-introduce/