使用Java實作重試原則
在雲端中執行或與遠端服務和資源通訊的任何應用程式都必須能夠處理暫時性錯誤。 這些應用程式通常會因為網路連線短暫中斷、服務或資源忙碌時的要求逾時，或其他因素而遇到錯誤。 開發人員應該建置應用程式，以透明方式處理暫時性錯誤，進而改善穩定性和復原能力。
在本文中，您將瞭解如何使用適用於 Java 的 Azure 儲存體 用戶端連結庫，為聯機到 Azure Blob 儲存體 的應用程式設定重試原則。 重試原則會定義應用程式如何處理失敗的要求，而且應該一律進行調整，以符合應用程式的商務需求和失敗的性質。
設定重試選項
Blob 儲存體的重試原則是以程式設計方式設定，可控制如何將重試選項套用至各種服務要求和案例。 例如，根據使用者互動發出要求的 Web 應用程式，可能會實作具有較少重試和較短延遲的原則，以增加回應性並在發生錯誤時通知使用者。 或者，在背景中執行批次要求的應用程式或元件可能會增加重試次數，並使用指數輪詢策略來允許要求時間順利完成。
下表列出建構 RequestRetryOptions 實例時可用的參數，以及類型、簡短描述，以及未進行任何變更時的預設值。 您應該主動調整這些屬性的值，以符合應用程式的需求。
| 屬性 | 類型 | 描述 | 預設值 |
|---|---|---|---|
retryPolicyType |
RetryPolicyType | 選擇性。 用於計算重試延遲的方法。 | 指數 |
maxTries |
整數 | 選擇性。 放棄之前重試次數上限。 | 4 |
tryTimeoutInSeconds |
整數 | 選擇性。 取消要求並假設失敗之前所允許的時間上限。 請注意，逾時適用於作業要求，而不是整體作業端對端。 此值應以主計算機可用的頻寬和記憶體服務的鄰近性為基礎。 良好的起點可能是每個 MB 預期的承載大小 60 秒。 | Integer.MAX_VALUE （秒） |
retryDelayInMs |
Long | 選擇性。 指定重試作業之前要使用的延遲量。 | 指數為 4 毫秒，固定 30 毫秒 |
maxRetryDelayInMs |
Long | 選擇性。 指定重試作業之前允許的最大延遲。 | 120 毫秒 |
secondaryHost |
String | 選擇性。 要重試要求的次要記憶體帳戶端點。 設定此值之前，您應該先了解讀取過時和可能不一致數據的問題。 若要深入了解，請參閱使用異地備援來設計高可用性應用程式。 | 無 |
在下列程式代碼範例中，我們會在 RequestRetryOptions 實例中設定重試選項，並將它BlobServiceClientBuilder傳遞給以建立客戶端物件：
RequestRetryOptions retryOptions = new RequestRetryOptions(RetryPolicyType.FIXED, 2, 3, 1000L, 1500L, null);
BlobServiceClient client = new BlobServiceClientBuilder()
.endpoint("https://<storage-account-name>.blob.core.windows.net/")
.credential(credential)
.retryOptions(retryOptions)
.buildClient();
在此範例中，從 BlobServiceClient 對象發出的每個服務要求都會使用 實例中所 RequestRetryOptions 定義的重試選項。 此原則適用於用戶端要求。 您可以根據應用程式的需求，為服務用戶端設定各種重試策略。