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 学习记录
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的学习,备忘!

参考文献

;