共用方式為

使用 JavaScript 或 TypeScript 實作重試原則

  • 發行項

在雲端中執行或與遠端服務和資源通訊的任何應用程式都必須能夠處理暫時性錯誤。 這些應用程式通常會因為網路連線短暫中斷、服務或資源忙碌時的要求逾時，或其他因素而遇到錯誤。 開發人員應該建置應用程式，以透明方式處理暫時性錯誤，進而改善穩定性和復原能力。

在本文中，您將瞭解如何使用適用於 JavaScript 的 Azure 儲存體 客戶端連結庫，為聯機到 Azure Blob 儲存體 的應用程式設定重試原則。 重試原則會定義應用程式如何處理失敗的要求，而且應該一律進行調整，以符合應用程式的商務需求和失敗的性質。

設定重試選項

Blob 儲存體的重試原則是以程式設計方式設定，可控制如何將重試選項套用至各種服務要求和案例。 例如，根據使用者互動發出要求的 Web 應用程式，可能會實作具有較少重試和較短延遲的原則，以增加回應性並在發生錯誤時通知使用者。 或者，在背景中執行批次要求的應用程式或元件可能會增加重試次數，並使用指數輪詢策略來允許要求時間順利完成。

下表列出建立 StorageRetryOptions 實例時可用的參數，以及類型、簡短描述，以及未進行任何變更時的預設值。 您應該主動調整這些屬性的值，以符合應用程式的需求。

屬性 類型​ 描述 預設值
maxRetryDelayInMs number 選擇性。 指定重試作業之前允許的最大延遲。 120 秒 （或 120 * 1000 毫秒）
maxTries number 選擇性。 放棄之前重試次數上限。 4
retryDelayInMs number 選擇性。 指定重試作業之前要使用的延遲量。 4 秒 （或 4 * 1000 毫秒）
retryPolicyType StorageRetryPolicyType 選擇性。 StorageRetryPolicyType，預設值為指數重試原則。 StorageRetryPolicyType.Exponential
secondaryHost string 選擇性。 要重試要求的次要記憶體帳戶端點。 設定此值之前，您應該先了解讀取過時和可能不一致數據的問題。 若要深入了解，請參閱使用異地備援來設計高可用性應用程式。 無
tryTimeoutInMs number 選擇性。 取消要求並假設失敗之前所允許的時間上限。 此逾時適用於作業要求，且應以主計算機可用的頻寬和記憶體服務的鄰近性為基礎。 值為 0 或未定義會導致客戶端沒有預設逾時，而且會使用伺服器端預設逾時。 若要深入瞭解，請參閱 Blob 服務作業的逾時。

在下列程式代碼範例中，我們會在 StorageRetryOptions 實例中設定重試選項、將它傳遞至新的 StoragePipelineOptions 實例，並在具現化BlobServiceClient時傳遞 pipeline ：

const options = {
  retryOptions: {
    maxTries: 4,
    retryDelayInMs: 3 * 1000,
    maxRetryDelayInMs: 120 * 1000,
    retryPolicyType: StorageRetryPolicyType.EXPONENTIAL
  },
};

const pipeline = newPipeline(credential, options);

const blobServiceClient = new BlobServiceClient(
  `https://${accountName}.blob.core.windows.net`,
  credential,
  pipeline
);

在此範例中 BlobServiceClient ，從對象發出的每個服務要求都會使用 中所 retryOptions定義的重試選項。 此原則適用於用戶端要求。 您可以根據應用程式的需求，為服務用戶端設定各種重試策略。

相關內容

  • 如需重試原則的架構指引和一般最佳做法，請參閱暫時性錯誤處理。
  • 如需針對暫時性失敗實作重試模式的指引，請參閱重試模式。