云計算設(shè)計模式（十八）——重試模式

啟用應(yīng)用程序來處理預(yù)期的，暫時的失敗時，它會嘗試連接到由透明的重試操作了以前失敗的期望，失敗的原因是瞬時的服務(wù)或網(wǎng)絡(luò)資源。這種模式可以提高應(yīng)用程序的穩(wěn)定性。

背景和問題

該通信的應(yīng)用程序與在云中運行的元素必須是可能發(fā)生在這樣的環(huán)境中的瞬時故障敏感。這些故障包括網(wǎng)絡(luò)連接的過程中出現(xiàn)時，一個服務(wù)是忙碌的瞬時損失的組件和服務(wù)中，服務(wù)的臨時不可用，或超時。

這些故障一般是自校正的，如果經(jīng)過一個合適的延遲被重復(fù)觸發(fā)一個故障的動作很可能是成功的。例如，數(shù)據(jù)庫服務(wù)，它正在處理大量并發(fā)請求可以實現(xiàn)節(jié)流策略，暫時拒絕，直到它的工作量有所緩和任何進(jìn)一步的請求。試圖訪問該數(shù)據(jù)庫的應(yīng)用程序可能無法連接，但如果它經(jīng)過一個合適的延遲再次嘗試它可能會成功。

解決方案

在云中，瞬時故障的情況并不少見和應(yīng)用應(yīng)該被設(shè)計為優(yōu)雅和透明地處理它們，減少的影響，這種故障可能對應(yīng)用程序正在執(zhí)行業(yè)務(wù)任務(wù)。

如果一個應(yīng)用程序檢測到故障時，它試圖將請求發(fā)送到遠(yuǎn)程服務(wù)，它可以通過使用以下策略處理失?。?/p>

• 如果故障指示故障不是瞬時的或不太成功，如果重復(fù)（例如，所造成的無效提供憑據(jù)的認(rèn)證失敗是不可能成功的，無論是多少次未遂），應(yīng)用程序應(yīng)中止操作和報告一個合適的異常。
• 如果報道的具體故障是不尋常的或罕見的，這可能是由于反常的情況，如網(wǎng)絡(luò)數(shù)據(jù)包成為損壞，同時它被發(fā)送。在這種情況下，應(yīng)用程序可以再次立即重試失敗的請求，因為相同的故障是不可能被重復(fù)和請求將可能是成功的。
• 如果故障是由一種更加普遍的連接，或“忙”的失敗，網(wǎng)絡(luò)或服務(wù)可能需要在短期內(nèi)同時連接問題糾正或工作的積壓被清除。應(yīng)用程序應(yīng)該等待請求重試前一個合適的時間。

對于比較常見的短暫故障，重試期間，應(yīng)選擇以傳播從應(yīng)用程序中盡可能均勻的多個實例的請求。這可以減少繁忙的業(yè)務(wù)持續(xù)過載的可能性。如果一個應(yīng)用程序的多個實例不斷轟擊與重試請求的服務(wù)，則可能需要該服務(wù)更長的時間來恢復(fù)。

如果請求仍然失敗，應(yīng)用程序可以等待進(jìn)一步的時期，再次嘗試。如果需要的話，這個過程可以重復(fù)而增加重試的延遲，直到請求的某一最大數(shù)目已經(jīng)嘗試都失敗了。延遲時間可以逐步增加，或可使用的定時策略，如指數(shù)回退，取決于故障的性質(zhì)和可能性，這將在這段時間內(nèi)被校正。

圖1示出了這種模式。如果嘗試后的預(yù)定數(shù)量的請求不成功，應(yīng)用程序應(yīng)將故障為異常，并相應(yīng)地處理它。

圖1 - 使用重試模式中調(diào)用托管服務(wù)的操作

應(yīng)用程序應(yīng)該換所有試圖訪問遠(yuǎn)程服務(wù)，實現(xiàn)重試政策配套上面列出的策略之一的代碼。發(fā)送到不同的服務(wù)請求會受到不同的政策，有的供應(yīng)商提供封裝這種方法庫。這些庫通常執(zhí)行的政策是參數(shù)化的，而應(yīng)用程序開發(fā)人員可以指定，如重試次數(shù)和重試之間的時間項的值。

在檢測故障和重試失敗的操作都應(yīng)該記錄這些故障的詳細(xì)信息的應(yīng)用程序的代碼。這個信息可能是有用的運算符。如果一個服務(wù)被頻繁報道為不可用或忙，往往是因為該服務(wù)已耗盡其資源。則可以減少與這些故障發(fā)生時通過換算出該服務(wù)的頻率。例如，如果數(shù)據(jù)庫服務(wù)正在不斷超載，它可能是有利的分區(qū)數(shù)據(jù)庫和負(fù)載分散到多個服務(wù)器。

注意： 微軟 Azure 提供了重試模式的廣泛支持。該模式與實踐瞬態(tài)故障處理塊允許應(yīng)用程序通過一系列的重試策略來處理許多 Azure 服務(wù)瞬態(tài)故障。微軟實體框架版本6提供了用于重新嘗試數(shù)據(jù)庫操作。此外，許多在 Azure Service Bus 和 Azure 存儲的 API 透明地執(zhí)行重試邏輯。

問題和注意事項

在決定如何實現(xiàn)這個模式時，您應(yīng)考慮以下幾點：

• 重試政策應(yīng)進(jìn)行調(diào)整，以滿足應(yīng)用和故障性質(zhì)的業(yè)務(wù)需求。它可能是更好一些非關(guān)鍵操作失敗快而不是重試幾次，并影響應(yīng)用程序的吞吐量。例如，在試圖訪問遠(yuǎn)程服務(wù)的交互式Web應(yīng)用程序，這可能是更好的重試之后用重試之間只有一個短的延遲的數(shù)量較少失敗，并顯示一個適當(dāng)?shù)南⒔o用戶（例如，“請稍后“），再次嘗試阻止應(yīng)用程序變得反應(yīng)遲鈍。對于批處理應(yīng)用程序，它可以是更合適的，以增加重試嘗試的次數(shù)與嘗試之間的指數(shù)增加的延遲。
• 與嘗試之間最小的延遲和大量的重試的高攻擊重試的政策，可能會進(jìn)一步降低正在接近運行或容量的占用。此重試策略也可能會影響應(yīng)用程序的響應(yīng)，如果它被不斷地在嘗試執(zhí)行失敗的操作，而不是做有用功。
• 如果后一個顯著次數(shù)的重試請求仍然失敗，則可能是更好的應(yīng)用程序，以防止進(jìn)一步的請求將要在相同的資源為一個周期，并簡單地立即報告故障。當(dāng)期限屆滿后，該應(yīng)用程序可以暫時允許通過一個或多個請求，看看他們是否成功。對于這一策略的詳細(xì)信息，請參閱斷路器格局。
• 在由它實現(xiàn)了一個重試策略可能需要為冪等的應(yīng)用程序調(diào)用的服務(wù)的操作。例如，發(fā)送到服務(wù)的請求可以被接收和處理成功，但是，由于瞬時故障，它可能無法發(fā)送響應(yīng)，指示該處理已完成。然后在應(yīng)用程序的重試邏輯可能試圖重復(fù)上沒有接收到所述第一請求的假定該請求。
• 一個請求到服務(wù)失敗可能由于各種原因而提出不同的異常，根據(jù)故障的性質(zhì)。一些例外可指示故障，可以非常迅速地得到解決，而另一些可能表明該故障持續(xù)時間更長?？赡苁怯幸娴闹卦嚥呗?，調(diào)整基于所述異常的類型的重試嘗試之間的時間。
• 考慮如何重試的操作是事務(wù)的一部分，會影響整體交易的一致性。這可能是有用的微調(diào)對于事務(wù)性操作的重試政策，最大限度地取得成功的機(jī)會，并減少需要撤消所有交易步驟。
• 確保所有重試代碼是完全針對各種故障條件下進(jìn)行測試。檢查它不會嚴(yán)重影響應(yīng)用程序的性能或可靠性，導(dǎo)致在服務(wù)和資源的過度負(fù)荷，或產(chǎn)生競態(tài)條件或瓶頸。
• 實現(xiàn)只在一個失敗的操作的全方面了解重試邏輯。例如，如果包含的重試策略任務(wù)調(diào)用另一個任務(wù)還包含一個重試策略，這個額外的重試的層可加長的延遲的處理。它可能是更好的配置的低級任務(wù)失敗快速并報告失敗返回調(diào)用它的任務(wù)的原因。然后這個更高級別的任務(wù)可以決定如何處理是根據(jù)它自己的策略失效。
• 記錄所有的連接故障，提示了重試，使?jié)撛诘膯栴}與該應(yīng)用程序，服務(wù)或資源可以被識別是很重要的。
• 研究是最有可能發(fā)生于一個服務(wù)或資源發(fā)現(xiàn)，如果它們有可能是持久或終端的故障。如果是這樣的話，它可能是更好地處理該故障為異常。該應(yīng)用程序可以報告或記錄該異常，然后試圖通過調(diào)用另一個服務(wù)，持續(xù)或者（如果有一個可用的），或通過提供降級功能。關(guān)于如何檢測和處理持久故障的更多信息，請參閱斷路器格局。

何時使用這個模式

使用這種模式：

• 當(dāng)一個應(yīng)用程序可能會經(jīng)歷短暫的故障，因為它與遠(yuǎn)程服務(wù)進(jìn)行交互，或訪問遠(yuǎn)程資源。這些故障預(yù)計將是短暫的，并重復(fù)了以前沒有能夠成功的后續(xù)嘗試的請求。

這種模式可能不適合：

• 當(dāng)故障很可能是持久的，因為這可能會影響應(yīng)用程序的響應(yīng)性。該應(yīng)用程序可以簡單地是浪費時間和資源試圖重復(fù)請求是最有可能失敗。
• 對于處理故障是不因瞬時故障，如在應(yīng)用程序的業(yè)務(wù)邏輯引起錯誤的內(nèi)部的異常。
• 作為一種替代解決系統(tǒng)中的可擴(kuò)展性問題。如果一個應(yīng)用程序有頻繁的“忙”的故障，這是通常指示被訪問的服務(wù)或資源應(yīng)相應(yīng)加大。

例子

本實施例說明的重試模式的實現(xiàn)。該 OperationWithBasicRetryAsync 方法，如下所示，通過 TransientOperationAsync 方法異步調(diào)用外部服務(wù)（該方法的細(xì)節(jié)將特定于服務(wù)，并從樣本代碼被省略）。

private int retryCount = 3;  
...  
?
public async Task OperationWithBasicRetryAsync()  
{  
  int currentRetry = 0;  
?
  for (; ;)  
  {  
    try  
    {  
      // Calling external service.  
      await TransientOperationAsync();  
?
      // Return or break.  
      break;  
    }  
    catch (Exception ex)  
    {  
      Trace.TraceError("Operation Exception");  
?
      currentRetry++;  
?
      // Check if the exception thrown was a transient exception  
      // based on the logic in the error detection strategy.  
      // Determine whether to retry the operation, as well as how   
      // long to wait, based on the retry strategy.  
      if (currentRetry > this.retryCount || !IsTransient(ex))  
      {  
        // If this is not a transient error   
        // or we should not retry re-throw the exception.   
        throw;  
      }  
    }  
?
    // Wait to retry the operation.  
    // Consider calculating an exponential delay here and   
    // using a strategy best suited for the operation and fault.  
    Await.Task.Delay();  
  }  
}  
?
// Async method that wraps a call to a remote service (details not shown).  
private async Task TransientOperationAsync()  
{  
  ...  
}

調(diào)用此方法的聲明被包裹在一個循環(huán)一個 try/ catch 塊中封裝。如果調(diào)用 TransientOperationAsync 方法成功，沒有拋出異常的 for 循環(huán)退出。如果 TransientOperationAsync 方法失敗，catch 塊檢查為失敗的原因，并且如果它被認(rèn)為是一個瞬時錯誤代碼等待一個短暫的延時，然后重試該操作。

在 for 循環(huán)還跟蹤該操作已經(jīng)嘗試的次數(shù)，并且如果代碼失敗三次異常被認(rèn)為是更持久。如果該異常是不是暫時的，或者是長久的，catch 處理拋出的異常。此異常退出 for 循環(huán)，應(yīng)捕獲調(diào)用該OperationWithBasicRetryAsync 方法的代碼。

該 IsTransient 方法，如下所示，檢查是否有特定的一組是相關(guān)的，其中所述代碼運行的環(huán)境的異常。一過異常的定義可以根據(jù)被訪問的資源，并在其上執(zhí)行的操作環(huán)境的不同而不同。

private bool IsTransient(Exception ex)  
{  
  // Determine if the exception is transient.  
  // In some cases this may be as simple as checking the exception type, in other   
  // cases it may be necessary to inspect other properties of the exception.  
  if (ex is OperationTransientException)  
    return true;  
?
  var webException = ex as WebException;  
  if (webException != null)  
  {  
    // If the web exception contains one of the following status values   
    // it may be transient.  
    return new[] {WebExceptionStatus.ConnectionClosed,   
                  WebExceptionStatus.Timeout,   
                  WebExceptionStatus.RequestCanceled }.  
            Contains(webException.Status);  
  }  
?
  // Additional exception checking logic goes here.  
  return false;  
}