Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Bulutta çalışan veya uzak hizmetlerle ve kaynaklarla iletişim kuran tüm uygulamaların geçici hataları işleyebilmesi gerekir. Bu uygulamaların bir anlık ağ bağlantısı kaybı, bir hizmet veya kaynak meşgul olduğunda istek zaman aşımı veya diğer faktörler nedeniyle hatalarla karşılaşması yaygın bir durumdur. Geliştiriciler, kararlılığı ve dayanıklılığı geliştirmek için geçici hataları şeffaf bir şekilde işlemek için uygulamalar derlemelidir.
Bu makalede, javascript için Azure Depolama istemci kitaplığını kullanarak Azure Blob Depolama bağlanan bir uygulama için yeniden deneme ilkesi yapılandırmayı öğreneceksiniz. Yeniden deneme ilkeleri, uygulamanın başarısız istekleri nasıl işlediğini tanımlar ve her zaman uygulamanın iş gereksinimlerini ve hatanın niteliğini karşılayacak şekilde ayarlanmalıdır.
Yeniden deneme seçeneklerini yapılandırma
Blob Depolama için yeniden deneme ilkeleri program aracılığıyla yapılandırılır ve yeniden deneme seçeneklerinin çeşitli hizmet isteklerine ve senaryolarına nasıl uygulanacağı üzerinde denetim sağlar. Örneğin, kullanıcı etkileşimini temel alan istekler veren bir web uygulaması, yanıt hızını artırmak ve bir hata oluştuğunda kullanıcıyı bilgilendirmek için daha az yeniden deneme ve daha kısa gecikme süresine sahip bir ilke uygulayabilir. Alternatif olarak, arka planda toplu iş istekleri çalıştıran bir uygulama veya bileşen yeniden deneme sayısını artırabilir ve istek süresinin başarıyla tamamlanmasını sağlamak için üstel bir geri alma stratejisi kullanabilir.
Aşağıdaki tabloda, StorageRetryOptions örneği oluşturulurken kullanılabilen parametreler, tür, kısa bir açıklama ve değişiklik yapmazsanız varsayılan değer listelenir. Uygulamanızın gereksinimlerini karşılamak için bu özelliklerin değerlerini ayarlama konusunda proaktif olmanız gerekir.
| Özellik | Türü | Açıklama | Default value |
|---|---|---|---|
maxRetryDelayInMs |
number |
isteğe bağlı. bir işlemi yeniden denemeden önce izin verilen en uzun gecikmeyi belirtir. | 120 saniye (veya 120 * 1000 ms) |
maxTries |
number |
isteğe bağlı. Vazgeçmeden önce en fazla yeniden deneme denemesi sayısı. | 4 |
retryDelayInMs |
number |
isteğe bağlı. Bir işlemi yeniden denemeden önce kullanılacak gecikme miktarını belirtir. | 4 saniye (veya 4 * 1000 ms) |
retryPolicyType |
StorageRetryPolicyType | isteğe bağlı. StorageRetryPolicyType, varsayılan değer üstel yeniden deneme ilkesidir. | StorageRetryPolicyType.Exponential |
secondaryHost |
string |
isteğe bağlı. İstekleri yeniden denemek için ikincil depolama hesabı uç noktası. Bu değeri ayarlamadan önce eski ve tutarsız olabilecek verileri okumayla ilgili sorunları anlamanız gerekir. Daha fazla bilgi edinmek için bkz . Yüksek oranda kullanılabilir uygulamalar tasarlamak için coğrafi yedekliliği kullanma. | Hiçbiri |
tryTimeoutInMs |
number |
isteğe bağlı. İstek iptal edilmeden ve başarısız kabul edilmeden önce izin verilen en uzun süre. Bu zaman aşımı işlem isteği için geçerlidir ve konak makinede kullanılabilen bant genişliğine ve Depolama hizmetine yakınlığı temel almalıdır. | 0 veya tanımsız bir değer istemcide varsayılan zaman aşımına neden olmaz ve sunucu tarafı varsayılan zaman aşımı kullanılır. Daha fazla bilgi edinmek için bkz . Blob hizmeti işlemleri için zaman aşımları. |
Aşağıdaki kod örneğinde, StorageRetryOptions örneğinde yeniden deneme seçeneklerini yapılandırıyoruz, yeni bir StoragePipelineOptions örneğine geçiriyor ve örneği oluştururken BlobServiceClientgeçiriyoruzpipeline:
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
);
Bu örnekte, nesnesinden BlobServiceClient verilen her hizmet isteğinde retryOptionstanımlanan yeniden deneme seçenekleri kullanılır. Bu ilke istemci istekleri için geçerlidir. Uygulamanızın gereksinimlerine göre hizmet istemcileri için çeşitli yeniden deneme stratejileri yapılandırabilirsiniz.
İlgili içerik
- Mimari rehberlik ve yeniden deneme ilkelerine yönelik genel en iyi yöntemler için bkz . Geçici hata işleme.
- Geçici hatalar için yeniden deneme deseni uygulama yönergeleri için bkz . Yeniden deneme düzeni.