spring retry是從spring batch獨立出來的一個能功能，主要實現(xiàn)了重試和熔斷。對于重試是有場景限制的，不是什么場景都適合重試，比如參數(shù)校驗不合法、寫操作等（要考慮寫是否冪等）都不適合重試。遠(yuǎn)程調(diào)用超時、網(wǎng)絡(luò)突然中斷可以重試。在微服務(wù)治理框架中，通常都有自己的重試與超時配置，比如dubbo可以設(shè)置retries=1，timeout=500調(diào)用失敗只重試1次，超過500ms調(diào)用仍未返回則調(diào)用失敗。在spring retry中可以指定需要重試的異常類型，并設(shè)置每次重試的間隔以及如果重試失敗是繼續(xù)重試還是熔斷（停止重試）。

設(shè)計與實現(xiàn)

RetryOperations定義重試的API，RetryTemplate是API的模板模式實現(xiàn)，實現(xiàn)了重試和熔斷。提供的API如下：

public interface RetryOperations {
  <T, E extends Throwable>T execute(RetryCallback<T, E>retryCallback) throws E;
  }
  // 其他API已省略

RetryCallback定義了需要執(zhí)行重試的操作，定義好操作后，就是如何重試的問題了。RetryTemplate通過制定不同的重試策略來執(zhí)行如何重試的邏輯。默認(rèn)的重試策略是SimpleRetryPlicy，也就是會重試3次。重試第1次如果成功后面就不會繼續(xù)重試了。那么如果3尺都重試失敗了呢？流程結(jié)束或者返回兜底結(jié)果。要返回兜底結(jié)果需要配置RecoveyCallBack，從名字可以看出這是一個兜底回調(diào)接口，也就是重試失敗后執(zhí)行的邏輯。除了SimpleRetryPolicy還有其他重試策略，先來看下RetryPolicy接口：

public interface RetryPolicy extends Serializable {
  boolean canRetry(RetryContext context);
  RetryContext open(RetryContext parent);
  void close(RetryContext context);
  void registerThrowable(RetryContext context, Throwable throwable);
}

canRetry在每次重試的時候調(diào)用，是否可以繼續(xù)重試的判斷條件
open重試開始前調(diào)用，會創(chuàng)建一個重試上下文到RetryContext，保存重試的堆棧等信息
registerThrowable每次重試異常時調(diào)用（有異常會繼續(xù)重試）

以SimpleRetryPolicy為例，當(dāng)重試次數(shù)達到3（默認(rèn)3次）停止重試，重試次數(shù)保存在重試上下文中。

提供如下重試策略實現(xiàn)：

1. NeverRetryPolicy：只允許調(diào)用RetryCallback一次，不允許重試
2. AlwaysRetryPolicy：允許無限重試，直到成功，此方式邏輯不當(dāng)會導(dǎo)致死循環(huán)
3. SimpleRetryPolicy：固定次數(shù)重試策略，默認(rèn)重試最大次數(shù)為3次，RetryTemplate默認(rèn)使用的策略
4. TimeoutRetryPolicy：超時時間重試策略，默認(rèn)超時時間為1秒，在指定的超時時間內(nèi)允許重試
5. ExceptionClassifierRetryPolicy：設(shè)置不同異常的重試策略，類似組合重試策略，區(qū)別在于這里只區(qū)分不同異常的重試
6. CircuitBreakerRetryPolicy：有熔斷功能的重試策略，需設(shè)置3個參數(shù)openTimeout、resetTimeout和delegate
7. CompositeRetryPolicy：組合重試策略，有兩種組合方式，樂觀組合重試策略是指只要有一個策略允許重試即可以，悲觀組合重試策略是指只要有一個策略不允許重試即可以，但不管哪種組合方式，組合中的每一個策略都會執(zhí)行

重試回退策略，指的是每次重試是立即重試還是等待一段時間后重試。默認(rèn)情況下是立即重試，如果需要配置等待一段時間后重試則需要指定回退策略BackoffRetryPolicy。BackoffRetryPolicy有如下實現(xiàn)：

1. NoBackOffPolicy：無退避算法策略，每次重試時立即重試
2. FixedBackOffPolicy：固定時間的退避策略，需設(shè)置參數(shù)sleeper和backOffPeriod，sleeper指定等待策略，默認(rèn)是Thread.sleep，即線程休眠，backOffPeriod指定休眠時間，默認(rèn)1秒
3. UniformRandomBackOffPolicy：隨機時間退避策略，需設(shè)置sleeper、minBackOffPeriod和maxBackOffPeriod，該策略在[minBackOffPeriod,maxBackOffPeriod之間取一個隨機休眠時間，minBackOffPeriod默認(rèn)500毫秒，maxBackOffPeriod默認(rèn)1500毫秒
4. ExponentialBackOffPolicy：指數(shù)退避策略，需設(shè)置參數(shù)sleeper、initialInterval、maxInterval和multiplier，initialInterval指定初始休眠時間，默認(rèn)100毫秒，maxInterval指定最大休眠時間，默認(rèn)30秒，multiplier指定乘數(shù)，即下一次休眠時間為當(dāng)前休眠時間*multiplier
5. ExponentialRandomBackOffPolicy：隨機指數(shù)退避策略，引入隨機乘數(shù)可以實現(xiàn)隨機乘數(shù)回退

有狀態(tài)重試 OR 無狀態(tài)重試

所謂無狀態(tài)重試是指重試在一個線程上下文中完成的重試，反之不在一個線程上下文完成重試的就是有狀態(tài)重試。之前的SimpleRetryPolicy就屬于無狀態(tài)重試，因為重試是在一個循環(huán)中完成的。那么什么會后會出現(xiàn)或者說需要有狀態(tài)重試呢？通常有兩種情況：事務(wù)回滾和熔斷。

數(shù)據(jù)庫操作異常DataAccessException，不能執(zhí)行重試，而如果拋出其他異?？梢灾卦?。

熔斷的意思不在當(dāng)前循環(huán)中處理重試，而是全局重試模式（不是線程上下文）。熔斷會跳出循環(huán)，那么必然會丟失線程上下文的堆棧信息。那么肯定需要一種“全局模式”保存這種信息，目前的實現(xiàn)放在一個cache（map實現(xiàn)的）中，下次從緩存中獲取就能繼續(xù)重試了。

Quick Start

在需要執(zhí)行重試的類上使用@EnableRetry，如果設(shè)置了proxyTargetClass=true這使用CGLIB動態(tài)代理：

@Configuration
@EnableRetry(proxyTargetClass = true)
@Component
public class RetryExamples {

}

基于最大重試次數(shù)策略的重試，如果重試了3次仍然拋出異常則停止重試，執(zhí)行兜底回調(diào)，所以最后的輸出結(jié)果是Integer.MAX_VALUE：

private void retryExample3() throws Exception {
    RetryTemplate retryTemplate = new RetryTemplate();

    SimpleRetryPolicy simpleRetryPolicy = new SimpleRetryPolicy();
    simpleRetryPolicy.setMaxAttempts(3);

    retryTemplate.setRetryPolicy(simpleRetryPolicy);

    Integer result = retryTemplate.execute(new RetryCallback<Integer, Exception>() {
      int i = 0;

       // 重試操作
      @Override
      public Integer doWithRetry(RetryContext retryContext) throws Exception {
        log.info("retry count: {}", retryContext.getRetryCount());
        return len(i++);
      }
    }, new RecoveryCallback<Integer>() { //兜底回調(diào)
      @Override
      public Integer recover(RetryContext retryContext) throws Exception {
        log.info("after retry: {}, recovery method called!", retryContext.getRetryCount());
        return Integer.MAX_VALUE;
      }
    });
    log.info("final result: {}", result);
  }

  private int len(int i) throws Exception {
    if (i < 10) throw new Exception(i + " le 10");
    return i;
  }

下面介紹如何使用熔斷重試策略模式（CircuitBreakerRetryPolicy），需要設(shè)置如下三個參數(shù)：

1. delegate：傳入RetryPolicy（每個RetryPolicy實現(xiàn)都有自己的重試策略實現(xiàn)），是真正判斷是否重試的策略，當(dāng)重試失敗時，則執(zhí)行熔斷策略
2. openTimeout：openWindow，配置熔斷器電路打開的超時時間，當(dāng)超過openTimeout之后熔斷器電路變成半打開狀態(tài)（只要有一次重試成功，則閉合電路）
3. resetTimeout：timeout，配置重置熔斷器重新閉合的超時時間

斷路器開閉實現(xiàn)判斷：

1. 當(dāng)重試失敗，且在熔斷器打開時間窗口[0,openWindow) 內(nèi)，立即熔斷
2. 當(dāng)重試失敗，且超過timeout，熔斷器電路重新閉合
3. 在熔斷器半打開狀態(tài)[openWindow, timeout] 時，只要重試成功則重置上下文，斷路器閉合

測試代碼如下：

RetryTemplate template = new RetryTemplate();
    CircuitBreakerRetryPolicy retryPolicy =
        new CircuitBreakerRetryPolicy(new SimpleRetryPolicy(3));
    retryPolicy.setOpenTimeout(5000);
    retryPolicy.setResetTimeout(20000);
    template.setRetryPolicy(retryPolicy);

    for (int i = 0; i < 10; i++) {
      //Thread.sleep(100);
      try {
        Object key = "circuit";
        boolean isForceRefresh = false;
        RetryState state = new DefaultRetryState(key, isForceRefresh);
        String result = template.execute(new RetryCallback<String, RuntimeException>() {
          @Override
          public String doWithRetry(RetryContext context) throws RuntimeException {
            log.info("retry count: {}", context.getRetryCount());
            throw new RuntimeException("timeout");
          }
        }, new RecoveryCallback<String>() {
          @Override
          public String recover(RetryContext context) throws Exception {
            return "default";
          }
        }, state);
        log.info("result: {}", result);
      } catch (Exception e) {
        System.out.println(e);
      }
    }

這里由于設(shè)置了isForceRefresh = false，則key = "circuit"的值（也就是RetryContext）會從緩存中獲取，所以當(dāng)重試失敗且滿足this.time < this.openWindow發(fā)生熔斷的時候，后面仍然可以繼續(xù)已全局模式實現(xiàn)重試（拿到的RetryContext是同一個）。

注解開發(fā)

如果每次有重試需求的時候都寫一個RetryTemplate太臃腫了，使用注解可以大大簡化開發(fā)，減少重復(fù)代碼。下面是一個使用注解實現(xiàn)的最大重試策略的重試：

@Retryable(value = SQLDataException.class, backoff = @Backoff(value = 0L))
  public String service3() throws SQLDataException {
    log.info("service3 open");
    throw new SQLDataException();
  }

  @Recover
  public String recover(SQLDataException ne) {
    return "SQLDataException recover";
  }

注解包括：

@EnableRetry

@Retryable

@Recover

@Backoff

@CircuitBreaker

@EnableRetry：能否重試，proxyTargetClass屬性為true時（默認(rèn)false），使用CGLIB代理

@Retryable：注解需要被重試的方法

1. include 指定處理的異常類。默認(rèn)為空
2. exclude指定不需要處理的異常。默認(rèn)為空
3. vaue指定要重試的異常。默認(rèn)為空
4. maxAttempts 最大重試次數(shù)。默認(rèn)3次
5. backoff 重試等待策略。默認(rèn)使用@Backoff注解

@Backoff：重試回退策略（立即重試還是等待一會再重試）

1. 不設(shè)置參數(shù)時，默認(rèn)使用FixedBackOffPolicy，重試等待1000ms
2. 只設(shè)置delay()屬性時，使用FixedBackOffPolicy，重試等待指定的毫秒數(shù)
3. 當(dāng)設(shè)置delay()和maxDealy()屬性時，重試等待在這兩個值之間均態(tài)分布
4. 使用delay()，maxDealy()和multiplier()屬性時，使用ExponentialBackOffPolicy
5. 當(dāng)設(shè)置multiplier()屬性不等于0時，同時也設(shè)置了random()屬性時，使用ExponentialRandomBackOffPolicy

@Recover: 用于方法。用于@Retryable失敗時的“兜底”處理方法。 @Recover注釋的方法必須要與@Retryable注解的方法“簽名”保持一致，第一入?yún)橐卦嚨漠惓?，其他參?shù)與@Retryable保持一致，返回值也要一樣，否則無法執(zhí)行！

@CircuitBreaker：用于方法，實現(xiàn)熔斷模式。

1. include 指定處理的異常類。默認(rèn)為空
2. exclude指定不需要處理的異常。默認(rèn)為空
3. vaue指定要重試的異常。默認(rèn)為空
4. maxAttempts 最大重試次數(shù)。默認(rèn)3次
5. openTimeout 配置熔斷器打開的超時時間，默認(rèn)5s，當(dāng)超過openTimeout之后熔斷器電路變成半打開狀態(tài)（只要有一次重試成功，則閉合電路）
6. resetTimeout 配置熔斷器重新閉合的超時時間，默認(rèn)20s，超過這個時間斷路器關(guān)閉

更多的例子歡迎到我的Github(https://github.com/happyxiaofan/springboot-learning-example) star。謝謝

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評論