本文研究的主要是Java編程Retry重試機(jī)制實(shí)例詳解，分享了相關(guān)代碼示例，小編覺得還是挺不錯(cuò)的，具有一定借鑒價(jià)值，需要的朋友可以參考下

1、業(yè)務(wù)場景

應(yīng)用中需要實(shí)現(xiàn)一個(gè)功能： 需要將數(shù)據(jù)上傳到遠(yuǎn)程存儲服務(wù)，同時(shí)在返回處理成功情況下做其他操作。這個(gè)功能不復(fù)雜，分為兩個(gè)步驟：第一步調(diào)用遠(yuǎn)程的Rest服務(wù)邏輯包裝給處理方法返回處理結(jié)果；第二步拿到第一步結(jié)果或者捕捉異常，如果出現(xiàn)錯(cuò)誤或異常實(shí)現(xiàn)重試上傳邏輯，否則繼續(xù)邏輯操作。

2、常規(guī)解決方案演化

1）try-catch-redo簡單重試模式：

包裝正常上傳邏輯基礎(chǔ)上，通過判斷返回結(jié)果或監(jiān)聽異常決策是否重試，同時(shí)為了解決立即重試的無效執(zhí)行(假設(shè)異常是有外部執(zhí)行不穩(wěn)定導(dǎo)致的)，休眠一定延遲時(shí)間重新執(zhí)行功能邏輯。

public void commonRetry(Map<String, Object> dataMap) throws InterruptedException { 
    Map<String, Object> paramMap = Maps.newHashMap(); 
    paramMap.put("tableName", "creativeTable"); 
    paramMap.put("ds", "20160220"); 
    paramMap.put("dataMap", dataMap); 
    boolean result = false; 
    try { 
      result = uploadToOdps(paramMap); 
      if (!result) { 
        Thread.sleep(1000); 
        uploadToOdps(paramMap); //一次重試 
      } 
    } catch (Exception e) { 
      Thread.sleep(1000); 
      uploadToOdps(paramMap);//一次重試 
    } 
  } 

2）try-catch-redo-retry strategy策略重試模式：

上述方案還是有可能重試無效，解決這個(gè)問題嘗試增加重試次數(shù)retrycount以及重試間隔周期interval，達(dá)到增加重試有效的可能性。

public void commonRetry(Map<String, Object> dataMap) throws InterruptedException { 
    Map<String, Object> paramMap = Maps.newHashMap(); 
    paramMap.put("tableName", "creativeTable"); 
    paramMap.put("ds", "20160220"); 
    paramMap.put("dataMap", dataMap); 
    boolean result = false; 
    try { 
      result = uploadToOdps(paramMap); 
      if (!result) { 
        reuploadToOdps(paramMap,1000L,10);//延遲多次重試 
      } 
    } catch (Exception e) { 
      reuploadToOdps(paramMap,1000L,10);//延遲多次重試 
    } 
  } 

方案一和方案二存在一個(gè)問題：正常邏輯和重試邏輯強(qiáng)耦合，重試邏輯非常依賴正常邏輯的執(zhí)行結(jié)果，對正常邏輯預(yù)期結(jié)果被動重試觸發(fā)，對于重試根源往往由于邏輯復(fù)雜被淹沒，可能導(dǎo)致后續(xù)運(yùn)維對于重試邏輯要解決什么問題產(chǎn)生不一致理解。重試正確性難保證而且不利于運(yùn)維，原因是重試設(shè)計(jì)依賴正常邏輯異?；蛑卦嚫吹囊軠y。

3、優(yōu)雅重試方案嘗試：

那有沒有可以參考的方案實(shí)現(xiàn)正常邏輯和重試邏輯解耦，同時(shí)能夠讓重試邏輯有一個(gè)標(biāo)準(zhǔn)化的解決思路？答案是有：那就是基于代理設(shè)計(jì)模式的重試工具，我們嘗試使用相應(yīng)工具來重構(gòu)上述場景。

1）應(yīng)用命令設(shè)計(jì)模式解耦正常和重試邏輯：

命令設(shè)計(jì)模式具體定義不展開闡述，主要該方案看中命令模式能夠通過執(zhí)行對象完成接口操作邏輯，同時(shí)內(nèi)部封裝處理重試邏輯，不暴露實(shí)現(xiàn)細(xì)節(jié)，對于調(diào)用者來看就是執(zhí)行了正常邏輯，達(dá)到解耦的目標(biāo)，具體看下功能實(shí)現(xiàn)。（類圖結(jié)構(gòu)）

IRetry約定了上傳和重試接口，其實(shí)現(xiàn)類OdpsRetry封裝ODPS上傳邏輯，同時(shí)封裝重試機(jī)制和重試策略。與此同時(shí)使用recover方法在結(jié)束執(zhí)行做恢復(fù)操作。

而我們的調(diào)用者LogicClient無需關(guān)注重試，通過重試者Retryer實(shí)現(xiàn)約定接口功能，同時(shí) Retryer需要對重試邏輯做出響應(yīng)和處理， Retryer具體重試處理又交給真正的IRtry接口的實(shí)現(xiàn)類OdpsRetry完成。通過采用命令模式，優(yōu)雅實(shí)現(xiàn)正常邏輯和重試邏輯分離，同時(shí)通過構(gòu)建重試者角色，實(shí)現(xiàn)正常邏輯和重試邏輯的分離，讓重試有更好的擴(kuò)展性。

2）spring-retry 規(guī)范正常和重試邏輯

spring-retry是一個(gè)開源工具包，目前可用的版本為1.1.2.RELEASE，該工具把重試操作模板定制化，可以設(shè)置重試策略和回退策略。同時(shí)重試執(zhí)行實(shí)例保證線程安全，具體場景操作實(shí)例如下：

public void upload(final Map<String, Object> map) throws Exception { 
    // 構(gòu)建重試模板實(shí)例 
    RetryTemplate retryTemplate = new RetryTemplate(); 
    // 設(shè)置重試策略，主要設(shè)置重試次數(shù) 
    SimpleRetryPolicy policy = new SimpleRetryPolicy(3, Collections.<Class<? extends Throwable>, Boolean> singletonMap(Exception.class, true)); 
    // 設(shè)置重試回退操作策略，主要設(shè)置重試間隔時(shí)間 
    FixedBackOffPolicy fixedBackOffPolicy = new FixedBackOffPolicy(); 
    fixedBackOffPolicy.setBackOffPeriod(100); 
    retryTemplate.setRetryPolicy(policy); 
    retryTemplate.setBackOffPolicy(fixedBackOffPolicy); 
    // 通過RetryCallback 重試回調(diào)實(shí)例包裝正常邏輯邏輯，第一次執(zhí)行和重試執(zhí)行執(zhí)行的都是這段邏輯 
    final RetryCallback<Object, Exception> retryCallback = new RetryCallback<Object, Exception>() { 
      //RetryContext 重試操作上下文約定，統(tǒng)一spring-try包裝  
      public Object doWithRetry(RetryContext context) throws Exception { 
        System.out.println("do some thing"); 
        Exception e = uploadToOdps(map); 
        System.out.println(context.getRetryCount()); 
        throw e;//這個(gè)點(diǎn)特別注意，重試的根源通過Exception返回 
      } 
    }; 
    // 通過RecoveryCallback 重試流程正常結(jié)束或者達(dá)到重試上限后的退出恢復(fù)操作實(shí)例 
    final RecoveryCallback<Object> recoveryCallback = new RecoveryCallback<Object>() { 
      public Object recover(RetryContext context) throws Exception { 
        System.out.println("do recory operation"); 
        return null; 
      } 
    }; 
    try { 
      // 由retryTemplate 執(zhí)行execute方法開始邏輯執(zhí)行 
      retryTemplate.execute(retryCallback, recoveryCallback); 
    } catch (Exception e) { 
      e.printStackTrace(); 
    } 
  } 

簡單剖析下案例代碼，RetryTemplate 承擔(dān)了重試執(zhí)行者的角色，它可以設(shè)置SimpleRetryPolicy(重試策略，設(shè)置重試上限，重試的根源實(shí)體)，F(xiàn)ixedBackOffPolicy（固定的回退策略，設(shè)置執(zhí)行重試回退的時(shí)間間隔）。RetryTemplate通過execute提交執(zhí)行操作，需要準(zhǔn)備RetryCallback 和RecoveryCallback 兩個(gè)類實(shí)例，前者對應(yīng)的就是重試回調(diào)邏輯實(shí)例，包裝正常的功能操作，RecoveryCallback實(shí)現(xiàn)的是整個(gè)執(zhí)行操作結(jié)束的恢復(fù)操作實(shí)例。

RetryTemplate的execute 是線程安全的，實(shí)現(xiàn)邏輯使用ThreadLocal保存每個(gè)執(zhí)行實(shí)例的RetryContext執(zhí)行上下文。

Spring-retry工具雖能優(yōu)雅實(shí)現(xiàn)重試，但是存在兩個(gè)不友好設(shè)計(jì)：一個(gè)是 重試實(shí)體限定為Throwable子類，說明重試針對的是可捕捉的功能異常為設(shè)計(jì)前提的，但是我們希望依賴某個(gè)數(shù)據(jù)對象實(shí)體作為重試實(shí)體，但Sping-retry框架必須強(qiáng)制轉(zhuǎn)換為Throwable子類。另一個(gè)就是重試根源的斷言對象使用的是doWithRetry的Exception 異常實(shí)例，不符合正常內(nèi)部斷言的返回設(shè)計(jì)。

Spring Retry提倡以注解的方式對方法進(jìn)行重試，重試邏輯是同步執(zhí)行的，重試的“失敗”針對的是Throwable，如果你要以返回值的某個(gè)狀態(tài)來判定是否需要重試，可能只能通過自己判斷返回值然后顯式拋出異常了。

Spring 對于Retry的抽象

“抽象”是每個(gè)程序員必備的素質(zhì)。對于資質(zhì)平平的我來說，沒有比模仿與理解優(yōu)秀源碼更好地進(jìn)步途徑了吧。為此，我將其核心邏輯重寫了一遍...下面就看看Spring Retry對于“重試”的抽象。

Spring retry相關(guān)接口.jpg

• RetryCallback: 封裝你需要重試的業(yè)務(wù)邏輯（上文中的doSth）
• RecoverCallback：封裝在多次重試都失敗后你需要執(zhí)行的業(yè)務(wù)邏輯(上文中的doSthWhenStillFail)
• RetryContext: 重試語境下的上下文，可用于在多次Retry或者Retry 和Recover之間傳遞參數(shù)或狀態(tài)（在多次doSth或者doSth與doSthWhenStillFail之間傳遞參數(shù)）
• RetryOperations : 定義了“重試”的基本框架（模板），要求傳入RetryCallback，可選傳入RecoveryCallback；
• RetryListener：典型的“監(jiān)聽者”，在重試的不同階段通知“監(jiān)聽者”（例如doSth，wait等階段時(shí)通知）
• RetryPolicy : 重試的策略或條件，可以簡單的進(jìn)行多次重試，可以是指定超時(shí)時(shí)間進(jìn)行重試（上文中的someCondition）
• BackOffPolicy: 重試的回退策略，在業(yè)務(wù)邏輯執(zhí)行發(fā)生異常時(shí)。如果需要重試，我們可能需要等一段時(shí)間(可能服務(wù)器過于繁忙，如果一直不間隔重試可能拖垮服務(wù)器)，當(dāng)然這段時(shí)間可以是0，也可以是固定的，可以是隨機(jī)的（參見tcp的擁塞控制算法中的回退策略）。回退策略在上文中體現(xiàn)為wait()；
• RetryTemplate :RetryOperations的具體實(shí)現(xiàn)，組合了RetryListener[]，BackOffPolicy，RetryPolicy。

3）guava-retryer 分離正常和重試邏輯

Guava retryer工具與spring-retry類似，都是通過定義重試者角色來包裝正常邏輯重試，但是Guava retryer有更優(yōu)的策略定義，在支持重試次數(shù)和重試頻度控制基礎(chǔ)上，能夠兼容支持多個(gè)異常或者自定義實(shí)體對象的重試源定義，讓重試功能有更多的靈活性。Guava Retryer也是線程安全的，入口調(diào)用邏輯采用的是Java.util.concurrent.Callable的call方法，示例代碼如下：

public void uploadOdps(final Map<String, Object> map) { 
    // RetryerBuilder 構(gòu)建重試實(shí)例 retryer,可以設(shè)置重試源且可以支持多個(gè)重試源，可以配置重試次數(shù)或重試超時(shí)時(shí)間，以及可以配置等待時(shí)間間隔 
    Retryer<Boolean> retryer = RetryerBuilder.<Boolean> newBuilder() 
        .retryIfException().//設(shè)置異常重試源 
        retryIfResult(new Predicate<Boolean>() {//設(shè)置自定義段元重試源， 
      @Override 
      public boolean apply(Boolean state) {//特別注意：這個(gè)apply返回true說明需要重試，與操作邏輯的語義要區(qū)分 
        return true; 
      } 
    }) 
    .withStopStrategy(StopStrategies.stopAfterAttempt(5))//設(shè)置重試5次，同樣可以設(shè)置重試超時(shí)時(shí)間 
    .withWaitStrategy(WaitStrategies.fixedWait(100L, TimeUnit.MILLISECONDS)).build();//設(shè)置每次重試間隔 
 
    try { 
      //重試入口采用call方法，用的是java.util.concurrent.Callable<V>的call方法,所以執(zhí)行是線程安全的 
      boolean result = retryer.call(new Callable<Boolean>() {  
        @Override 
        public Boolean call() throws Exception { 
          try { 
            //特別注意：返回false說明無需重試，返回true說明需要繼續(xù)重試 
            return uploadToOdps(map); 
          } catch (Exception e) { 
            throw new Exception(e); 
          } 
        } 
      }); 
 
    } catch (ExecutionException e) { 
    } catch (RetryException ex) { 
    } 
  } 

示例代碼原理分析：

RetryerBuilder是一個(gè)factory創(chuàng)建者，可以定制設(shè)置重試源且可以支持多個(gè)重試源，可以配置重試次數(shù)或重試超時(shí)時(shí)間，以及可以配置等待時(shí)間間隔，創(chuàng)建重試者Retryer實(shí)例。

RetryerBuilder的重試源支持Exception異常對象 和自定義斷言對象，通過retryIfException 和retryIfResult設(shè)置，同時(shí)支持多個(gè)且能兼容。

RetryerBuilder的等待時(shí)間和重試限制配置采用不同的策略類實(shí)現(xiàn)，同時(shí)對于等待時(shí)間特征可以支持無間隔和固定間隔方式。

Retryer 是重試者實(shí)例，通過call方法執(zhí)行操作邏輯，同時(shí)封裝重試源操作。

優(yōu)雅重試共性和原理

正常和重試優(yōu)雅解耦，重試斷言條件實(shí)例或邏輯異常實(shí)例是兩者溝通的媒介。
約定重試間隔，差異性重試策略，設(shè)置重試超時(shí)時(shí)間，進(jìn)一步保證重試有效性以及重試流程穩(wěn)定性。
都使用了命令設(shè)計(jì)模式，通過委托重試對象完成相應(yīng)的邏輯操作，同時(shí)內(nèi)部封裝實(shí)現(xiàn)重試邏輯。
Spring-tryer和guava-tryer工具都是線程安全的重試，能夠支持并發(fā)業(yè)務(wù)場景的重試邏輯正確性。

優(yōu)雅重試適用場景

功能邏輯中存在不穩(wěn)定依賴場景，需要使用重試獲取預(yù)期結(jié)果或者嘗試重新執(zhí)行邏輯不立即結(jié)束。比如遠(yuǎn)程接口訪問，數(shù)據(jù)加載訪問，數(shù)據(jù)上傳校驗(yàn)等等。
對于異常場景存在需要重試場景，同時(shí)希望把正常邏輯和重試邏輯解耦。
對于需要基于數(shù)據(jù)媒介交互，希望通過重試輪詢檢測執(zhí)行邏輯場景也可以考慮重試方案。

總結(jié)

以上就是本文關(guān)于Java編程Retry重試機(jī)制實(shí)例詳解的全部內(nèi)容，希望對大家有所幫助。感興趣的朋友可以繼續(xù)參閱本站其他相關(guān)專題，如有不足之處，歡迎留言指出。感謝朋友們對本站的支持！