Azure hizmetleri için yeniden deneme kılavuzu

  • Makale

Çoğu Azure hizmeti ve istemci SDK'sı bir yeniden deneme mekanizması içerir. Ancak, her hizmet farklı özellik ve gereksinimlere sahip olduğundan birbirinden farklıdır ve bu yüzden her yeniden deneme mekanizması belirli bir hizmete göre ayarlanmıştır. Bu kılavuz, çoğu Azure hizmetinin yeniden deneme mekanizması özelliklerini özetler ve söz konusu hizmet için yeniden deneme mekanizmasını kullanmanıza, uyarlamanıza veya genişletmenize yardımcı olacak bilgiler içerir.

Geçici hataların işlenmesi ve bağlantılar ile işlemlerin hizmetler ile kaynaklara karşı yeniden denenmesi hakkında genel yönergeler için bkz. Yeniden deneme kılavuzu.

Aşağıdaki tabloda, bu kılavuzda açıklanan Azure hizmetlerinin yeniden deneme özellikleri özetlenmektedir.

Hizmet Yeniden deneme özellikleri İlke yapılandırması Scope Telemetri özellikleri
Microsoft Entra ID MSAL kitaplığında yerel MSAL kitaplığına eklenmiş Şirket İçi Hiçbiri
Azure Cosmos DB Hizmette yerel Yapılandırılamaz Global TraceSource
Data Lake Store İstemcide yerel Yapılandırılamaz Tek tek işlemler Hiçbiri
Event Hubs İstemcide yerel Programlı İstemci Hiçbiri
IoT Hub İstemci SDK'sında yerel Programlı İstemci Hiçbiri
Redis için Azure Önbelleği İstemcide yerel Programlı İstemci TextWriter
Arama yap İstemcide yerel Programlı İstemci Windows için Olay İzleme (ETW) veya Özel
Service Bus İstemcide yerel Programlı Namespace Manager, Messaging Factory ve Client ETW
Service Fabric İstemcide yerel Programlı İstemci Hiçbiri
ADO.NET ile SQL Veritabanı Polly Bildirim temelli ve programlı Tek deyimler veya kod blokları Özel
Entity Framework ile SQL Veritabanı İstemcide yerel Programlı Uygulama Etki Alanı başına genel Hiçbiri
Entity Framework Core ile SQL Veritabanı İstemcide yerel Programlı Uygulama Etki Alanı başına genel Hiçbiri
Depolama İstemcide yerel Programlı İstemci ve tek işlemler TraceSource

Not

Azure'daki yerleşik yeniden deneme mekanizmalarının çoğu için şu anda farklı hata veya özel durum türleri için farklı bir yeniden deneme ilkesi uygulama imkanı yoktur. En iyi ortalama performansı ve kullanılabilirliği sağlayan bir ilke yapılandırmanız gerekir. İlkeye ince ayar yapmanın bir yolu, günlük dosyalarını analiz ederek gerçekleşen geçici hataların türünü belirlemektir.

Microsoft Entra Kimlik

Microsoft Entra ID, temel dizin hizmetlerini, gelişmiş kimlik idaresini, güvenliği ve uygulama erişim yönetimini birleştiren kapsamlı bir kimlik ve erişim yönetimi bulut çözümüdür. Microsoft Entra ID, geliştiricilere merkezi ilke ve kurallara göre uygulamalarına erişim denetimi sağlamak için bir kimlik yönetimi platformu da sunar.

Not

Yönetilen Hizmet Kimliği uç noktalarıyla ilgili yeniden deneme kılavuzu için bkz . Belirteç alımı için Azure VM Yönetilen Hizmet Kimliği (MSI) kullanma.

Yeniden deneme mekanizması

Microsoft Kimlik Doğrulama Kitaplığı'nda (MSAL) Microsoft Entra Id için yerleşik bir yeniden deneme mekanizması vardır. Beklenmeyen kilitlemeleri önlemek için, üçüncü taraf kitaplıklarının ve uygulama kodunun başarısız bağlantıları yeniden denememesi, ancak MSAL'nin yeniden denemeleri işlemesine izin vermenizi öneririz.

Yeniden deneme kullanım kılavuzu

Microsoft Entra Id kullanırken aşağıdaki yönergeleri göz önünde bulundurun:

  • Mümkün olduğunda, yeniden denemeler için MSAL kitaplığını ve yerleşik desteği kullanın.
  • Microsoft Entra Id için REST API kullanıyorsanız, sonuç kodu 429 (Çok Fazla İstek) veya 5xx aralığında bir hataysa işlemi yeniden deneyin. Diğer hataları yeniden denemeyin.
  • 429 hataları için yalnızca Yeniden Dene-Sonra üst bilgisinde belirtilen süreden sonra yeniden deneyin.
  • 5xx hataları için üstel geri alma kullanın ve ilk yeniden deneme yanıttan en az 5 saniye sonra olur.
  • 429 ve 5xx dışındaki hataları yeniden denemeyin.

Sonraki adımlar

Azure Cosmos DB

Azure Cosmos DB, şemasız JSON verilerini destekleyen tam olarak yönetilen çok modelli bir veritabanıdır. Yapılandırılabilir ve güvenilir bir performans, yerel JavaScript işlem tabanlı işleme sağlar ve bulut için esnek bir ölçekle oluşturulmuştur.

Yeniden deneme mekanizması

Azure Cosmos DB SDK'ları belirli hata koşullarında otomatik olarak yeniden dener ve kullanıcı uygulamalarının kendi yeniden deneme ilkelerine sahip olması teşvik edilir. Hata koşullarının tam listesi ve ne zaman yeniden denenecekleri için Azure Cosmos DB SDK'ları ile dayanıklı uygulamalar tasarlama kılavuzuna bakın.

Telemetri

Uygulamanızın diline bağlı olarak, tanılamalar ve telemetri işlem yanıtlarında günlükler veya yükseltilen özellikler olarak gösterilir. Daha fazla bilgi için Azure Cosmos DB C# SDK'sı ve Azure Cosmos DB Java SDK'sının "Tanılamayı yakalama" bölümüne bakın.

Data Lake Storage

Data Lake Storage 2. Nesil, Azure Depolama'yı Azure'da kurumsal veri gölleri oluşturmanın temeli haline getirir. Data Lake Storage 2. Nesil, çok büyük miktarda veriyi kolayca yönetmenize olanak tanır.

Azure Storage Files Data Lake istemci kitaplığı, geliştiricilerin, veri bilimcilerinin ve analistlerin her boyutta, şekilde ve hızda veri depolamasını ve platformlar ile diller arasında her türlü işleme ve analiz gerçekleştirmesini kolaylaştırmak için gereken tüm özellikleri içerir.

Yeniden deneme mekanizması

DataLakeServiceClient, Azure Data Lake hizmet kaynaklarını ve dosya sistemlerini işlemenize olanak tanır. Depolama hesabı, Data Lake hizmeti için en üst düzey ad alanını sağlar. İstemciyi oluşturduğunuzda Azure Data Lake hizmetine (DataLakeClientOptions) bağlanmak için istemci yapılandırma seçeneklerini sağlayabilirsiniz. DataLakeClientOptions, yapılandırılabilir bir Retry özelliği (Azure.Core.ClientOptions'tan devralınmış) içerir (RetryOptions sınıfı).

Telemetri

Azure Depolama'nın kullanımını ve performansını izlemek , hizmetinizi kullanıma hazır hale getirmenin önemli bir parçasıdır. Örnekler arasında sık yapılan işlemler, yüksek gecikme süresine sahip işlemler veya hizmet tarafı azaltmaya neden olan işlemler verilebilir.

Depolama hesabınızın tüm telemetri verilerini Azure İzleyici'deki Azure Depolama günlükleri aracılığıyla kullanabilirsiniz. Bu özellik, depolama hesabınızı Log Analytics ve Event Hubs ile tümleştirir ve günlükleri başka bir depolama hesabına arşivlemenizi sağlar. Ölçümlerin ve kaynak günlüklerinin ve ilişkili şemalarının tam listesini görmek için bkz . Azure Depolama izleme verileri başvurusu.

Event Hubs

Azure Event Hubs, milyonlarca olayı toplayan, dönüştüren ve depolayan bir hiper ölçek telemetri alımı hizmetidir.

Yeniden deneme mekanizması

Azure Event Hubs İstemci Kitaplığındaki yeniden deneme davranışı, EventHubClient sınıfındaki RetryPolicy özelliği tarafından denetlenir. Azure Event Hubs geçici EventHubsException veya OperationCanceledExceptiondöndürdüğünde varsayılan ilke üstel geri alma ile yeniden denenir. Event Hubs için varsayılan yeniden deneme ilkesi, 30 saniyeye kadar üstel geri alma süresiyle en fazla 9 kez yeniden denemektir.

Örnek

EventHubClient client = EventHubClient.CreateWithManagedIdentity(new Uri("sb://full_namespace_url", "entity_path");
client.RetryPolicy = RetryPolicy.Default;

Sonraki adımlar

.NET için Azure Event Hubs istemci kitaplığı

IoT Hub

Azure IoT Hub, Nesnelerin İnterneti (IoT) uygulamaları geliştirmek için cihazları bağlamaya, izlemeye ve yönetmeye yönelik bir hizmettir.

Yeniden deneme mekanizması

Azure IoT cihaz SDK'sı ağ, protokol veya uygulamadaki hataları algılayabilir. Sdk, hata türüne bağlı olarak yeniden deneme yapılması gerekip gerekmediğini denetler. Hata kurtarılabilirse SDK, yapılandırılmış yeniden deneme ilkesini kullanarak yeniden denemeye başlar.

Varsayılan yeniden deneme ilkesi, rastgele değişimli üstel geri almadır, ancak yapılandırılabilir.

İlke yapılandırması

İlke yapılandırması dile göre farklılık gösterir. Daha fazla bilgi için bkz . IoT Hub yeniden deneme ilkesi yapılandırması.

Sonraki adımlar

Redis için Azure Önbelleği

Redis için Azure Cache, popüler açık kaynak Redis önbelleğini temel alan hızlı bir veri erişimi ve düşük gecikme süreli önbellek hizmetidir. Güvenlidir, Microsoft tarafından yönetilir ve Azure'daki herhangi bir uygulamadan erişilebilir.

Bu bölümdeki yönergeler, önbelleğe erişmek için StackExchange.Redis istemcisini kullanmayı temel alır. Diğer uygun istemcilerin listesi Redis web sitesinde bulunabilir ve bu istemciler farklı yeniden deneme mekanizmalarına sahip olabilir.

StackExchange.Redis istemcisi, tek bir bağlantı üzerinden çoğullama kullanır. Önerilen kullanım, uygulama başlangıcında istemcinin bir örneğinin oluşturulması ve bu örneğin önbelleğe yönelik tüm işlemlerde kullanılmasıdır. Bu nedenle, önbellekle bağlantı yalnızca bir kez yapılır ve bu yüzden bu bölümdeki tüm yönergeler bu ilk bağlantının yeniden deneme ilkesiyle ilgilidir; önbelleğe erişen her işlemle ilgili değildir.

Yeniden deneme mekanizması

StackExchange.Redis istemcisi, aşağıdakiler gibi bir dizi seçenek aracılığıyla yapılandırılan bir bağlantı yöneticisi sınıfı kullanır:

  • ConnectRetry. Önbellekle başarısız bir bağlantıyı yeniden deneme sayısı.
  • ReconnectRetryPolicy. Kullanılacak yeniden deneme stratejisi.
  • ConnectTimeout. Milisaniye cinsinden en fazla bekleme süresi.

İlke yapılandırması

Yeniden deneme ilkeleri, önbellekle bağlantı kurulmadan önce istemci seçenekleri ayarlanarak program aracılığıyla yapılandırılır. Bu işlem ConfigurationOptions sınıfının bir örneği oluşturularak, özellikleri doldurularak ve Connect yöntemine geçirilerek yapılabilir.

Yerleşik sınıflar, rastgele yeniden deneme aralıkları seçimi ile doğrusal (sabit gecikme) ve üstel geri almayı destekler. Ayrıca IReconnectRetryPolicy arabirimini uygulayarak özel bir yeniden deneme ilkesi oluşturabilirsiniz.

Aşağıdaki örnek, üstel geri almayı kullanarak bir yeniden deneme stratejisini yapılandırır.

var deltaBackOffInMilliseconds = TimeSpan.FromSeconds(5).TotalMilliseconds;
var maxDeltaBackOffInMilliseconds = TimeSpan.FromSeconds(20).TotalMilliseconds;
var options = new ConfigurationOptions
{
    EndPoints = {"localhost"},
    ConnectRetry = 3,
    ReconnectRetryPolicy = new ExponentialRetry(deltaBackOffInMilliseconds, maxDeltaBackOffInMilliseconds),
    ConnectTimeout = 2000
};
ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

Alternatif olarak, seçenekleri bir dize olarak belirtebilir ve bu dizeyi Connecy yöntemine geçirebilirsiniz. ReconnectRetryPolicy özelliği yalnızca kod aracılığıyla bu şekilde ayarlanamaz.

var options = "localhost,connectRetry=3,connectTimeout=2000";
ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

Önbelleğe bağladığınızda seçenekleri doğrudan da belirtebilirsiniz.

var conn = ConnectionMultiplexer.Connect("redis0:6380,redis1:6380,connectRetry=3");

Daha fazla bilgi için StackExchange.Redis belgelerinde Stack Exchange Redis Yapılandırması bölümüne bakın.

Aşağıdaki tabloda yerleşik yeniden deneme ilkelerine ilişkin varsayılan ayarlar gösterilmektedir.

Bağlam Ayar Varsayılan değer
(v 1.2.2)		 Anlamı
ConfigurationOptions ConnectRetry

ConnectTimeout

SyncTimeout

ReconnectRetryPolicy		 3

En fazla 5000 ms ve SyncTimeout
1000

LinearRetry 5000 ms		 İlk bağlantı işlemi sırasında bağlantı girişimlerini yineleme sayısı.
Bağlantı işlemleri için zaman aşımı (ms). Yeniden deneme girişimleri gecikme yoktur.
Zaman uyumlu işlemler izin verilecek süre (ms).

Her 5000 ms’de yeniden deneyin.

Not

Zaman uyumlu işlemler için SyncTimeout uçtan uca gecikme süresi ekleyebilir, ancak değerin çok düşük ayarlanması aşırı miktarda zaman aşımıne neden olabilir. Daha fazla bilgi için bkz. Redis için Azure Cache sorunlarını giderme. Genel olarak, zaman uyumlu işlemler kullanmaktan kaçının ve onun yerine zaman uyumsuz işlemler kullanın. Daha fazla bilgi için bkz . İşlem Hatları ve Çoğullayıcılar.

Yeniden deneme kullanım kılavuzu

Redis için Azure Cache kullanırken aşağıdaki yönergeleri göz önünde bulundurun:

  • StackExchange Redis istemcisi kendi yeniden denemelerini yönetir, ancak yalnızca uygulama ilk kez başlatıldığında önbellekle bağlantı kurarken bunu yapar. Bağlantı zaman aşımını, yeniden deneme denemelerinin sayısını ve bu bağlantıyı kurmak için yeniden denemeler arasındaki süreyi yapılandırabilirsiniz, ancak yeniden deneme ilkesi önbellekteki işlemler için geçerli değildir.
  • Çok sayıda yeniden deneme girişimi kullanmak yerine özgün veri kaynağına erişerek geri almayı düşünün.

Telemetri

Bir TextWriter kullanarak bağlantılar hakkında (diğer işlemler hakkında değil) bilgi toplayabilirsiniz.

var writer = new StringWriter();
ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

Bu işlemin oluşturduğu çıktı aşağıda gösterilmiştir.

localhost:6379,connectTimeout=2000,connectRetry=3
1 unique nodes specified
Requesting tie-break from localhost:6379 > __Booksleeve_TieBreak...
Allowing endpoints 00:00:02 to respond...
localhost:6379 faulted: SocketFailure on PING
localhost:6379 failed to nominate (Faulted)
> UnableToResolvePhysicalConnection on GET
No masters detected
localhost:6379: Standalone v2.0.0, master; keep-alive: 00:01:00; int: Connecting; sub: Connecting; not in use: DidNotRespond
localhost:6379: int ops=0, qu=0, qs=0, qc=1, wr=0, sync=1, socks=2; sub ops=0, qu=0, qs=0, qc=0, wr=0, socks=2
Circular op-count snapshot; int: 0 (0.00 ops/s; spans 10s); sub: 0 (0.00 ops/s; spans 10s)
Sync timeouts: 0; fire and forget: 0; last heartbeat: -1s ago
resetting failing connections to retry...
retrying; attempts left: 2...
...

Örnekler

Aşağıdaki kod örneğinde StackExchange.Redis istemcisi başlatılırken yeniden denemeler arasında sabit (doğrusal) bir gecikme yapılandırılmaktadır. Bu örnekte bir ConfigurationOptions örneği kullanılarak yapılandırmanın nasıl ayarlanacağı gösterilmektedir.

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using StackExchange.Redis;

namespace RetryCodeSamples
{
    class CacheRedisCodeSamples
    {
        public async static Task Samples()
        {
            var writer = new StringWriter();
            {
                try
                {
                    var retryTimeInMilliseconds = TimeSpan.FromSeconds(4).TotalMilliseconds; // delay between retries

                    // Using object-based configuration.
                    var options = new ConfigurationOptions
                                        {
                                            EndPoints = { "localhost" },
                                            ConnectRetry = 3,
                                            ReconnectRetryPolicy = new LinearRetry(retryTimeInMilliseconds)
                                        };
                    ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

                    // Store a reference to the multiplexer for use in the application.
                }
                catch
                {
                    Console.WriteLine(writer.ToString());
                    throw;
                }
            }
        }
    }
}

Sonraki örnek, seçenekleri bir dize olarak belirterek yapılandırmayı ayarlar. Bağlantı zaman aşımı, yeniden deneme girişimleri arasındaki gecikme değil, önbellekle bağlantı kurmak için beklenecek en uzun süredir. ReconnectRetryPolicy özelliği yalnızca kodla ayarlanabilir.

using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using StackExchange.Redis;

namespace RetryCodeSamples
{
    class CacheRedisCodeSamples
    {
        public async static Task Samples()
        {
            var writer = new StringWriter();
            {
                try
                {
                    // Using string-based configuration.
                    var options = "localhost,connectRetry=3,connectTimeout=2000";
                    ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

                    // Store a reference to the multiplexer for use in the application.
                }
                catch
                {
                    Console.WriteLine(writer.ToString());
                    throw;
                }
            }
        }
    }
}

Daha fazla örnek için proje web sitesindeki Yapılandırma sayfasına bakın.

Sonraki adımlar

Azure Search bir web sitesine ya da uygulamaya güçlü ve çok yönlü arama özellikleri eklemek, arama sonuçlarını hızlı ve kolay bir şekilde ayarlamak ve zengin ve ince ayarlı sıralama modelleri oluşturmak için kullanılabilir.

Yeniden deneme mekanizması

.NET için Azure SDK, Azure SDK ekibinden bir Azure.Search.Documents istemci kitaplığı içerir ve bu kitaplık, önceki istemci kitaplığı olan Microsoft.Azure.Search ile işlevsel olarak eşdeğerdir.

Microsoft.Azure.Search'teki yeniden deneme davranışı, SearchServiceClient ve SearchIndexClient sınıflarındaki SetRetryPolicy yöntemi tarafından denetlenilir. Azure Search bir 5xx veya 408 (İstek Zaman Aşımı) yanıtı döndürdüğünde üstel geri alma ile yeniden dener.

Azure.Search.Documents içindeki yeniden deneme davranışı, Azure.Core.RetryOptions sınıfına (tüm yapılandırmaların kullanılabildiği) ait olan Retry özelliğindeki SearchClientOptions (SearchClient oluşturucusunun bir parçasıdır) tarafından denetlenir.

Telemetri

ETW ile veya bir özel izleme sağlayıcısı kaydederek izleyin. Daha fazla bilgi için bkz. AutoRest belgeleri.

Service Bus

Service Bus, bulutta veya şirket içinde barındırılan bir uygulamanın bileşenleri için geliştirilmiş ölçek ve dayanıklılık ile gevşek bağlanmış ileti alışverişi sağlayan bir bulut mesajlaşma platformudur.

Yeniden deneme mekanizması

Ad alanı ve bazı yapılandırma ayrıntıları, hangi Service Bus istemci SDK paketinin kullanıldığına bağlıdır:

Paket Açıklama Ad Alanı
Azure.Messaging.ServiceBus .NET için Azure Service Bus istemci kitaplığı Azure.Messaging.ServiceBus
WindowsAzure.ServiceBus Bu paket eski Service Bus istemci kitaplığıdır. .NET Framework 4.5.2 gerektirir. Microsoft.Azure.ServiceBus

Yeniden deneme kullanım kılavuzu

ServiceBusRetryOptions özelliği, nesnesi için ServiceBusClient yeniden deneme seçeneklerini belirtir:

Ayar Default value Anlamı
CustomRetryPolicy Tek tek seçenek değerleri yerine kullanılacak özel bir yeniden deneme ilkesi.
Delay (Gecikme Süresi) 0,8 saniye Sabit bir yaklaşım için yeniden deneme girişimleri arasındaki gecikme veya geri alma tabanlı bir yaklaşım için hesaplamaların temel alındığı gecikme.
MaxDelay 60 saniye Yeniden deneme girişimleri arasındaki izin verilen maksimum gecikme.
MaxRetries 3 İlişkili işlemin başarısız olduğu düşünülmeden önce en fazla yeniden deneme deneme sayısı.
Mod Üstel Yeniden deneme gecikmelerini hesaplamak için kullanılacak yaklaşım.
TryTimeout 60 saniye İlk deneme veya yeniden deneme olsun, tek bir denemenin tamamlanmasını bekleme süresi üst sınırı.

Mode ServiceBusRetryMode'ı şu değerlerden herhangi biriyle yapılandırmak için özelliğini ayarlayın:

Özellik Değer Açıklama
Üstel 1 Yeniden deneme girişimleri, geri alma stratejisine göre gecikecek ve her deneme yeniden denemeden önce beklediği süreyi artıracaktır.
Sabit 0 Yeniden deneme girişimleri sabit aralıklarla gerçekleşir; her gecikme tutarlı bir süredir.

Örnek:

using Azure.Identity;
using Azure.Messaging.ServiceBus;

string namespace = "<namespace>";
string queueName = "<queue_name>";

// Because ServiceBusClient implements IAsyncDisposable, we'll create it
// with "await using" so that it is automatically disposed for us.
var options = new ServiceBusClientOptions();
options.RetryOptions = new ServiceBusRetryOptions
{
    Delay = TimeSpan.FromSeconds(10),
    MaxDelay = TimeSpan.FromSeconds(30),
    Mode = ServiceBusRetryMode.Exponential,
    MaxRetries = 3,
};
await using var client = new ServiceBusClient(namespace, new DefaultAzureCredential(), options);

Telemetri

Service Bus, diğer Azure kaynaklarıyla aynı izleme verilerini toplar. Azure İzleyici kullanarak Azure Service Bus'i izleyebilirsiniz.

Ayrıca Service Bus .NET istemci kitaplıklarıyla telemetri göndermek için çeşitli seçenekleriniz vardır.

Örnek

Aşağıdaki kod örneğinde paketin nasıl kullanılacağı gösterilmektedir Azure.Messaging.ServiceBus :

  • Yeni ServiceBusClientOptionsbir kullanarak için ServiceBusClient yeniden deneme ilkesini ayarlayın.
  • yeni bir örneğiyle yeni bir ServiceBusMessageileti oluşturun.
  • yöntemini kullanarak Service Bus'a ServiceBusSender.SendMessageAsync(message) bir ileti gönderin.
  • Nesne olarak ServiceBusReceivedMessage temsil edilen öğesini kullanarak ServiceBusReceiveralma.
using Azure.Identity;
using Azure.Messaging.ServiceBus;

string namespace = "<namespace>";
string queueName = "queue1";

// Because ServiceBusClient implements IAsyncDisposable, we'll create it 
// with "await using" so that it is automatically disposed for us.
var options = new ServiceBusClientOptions();
options.RetryOptions = new ServiceBusRetryOptions
{
    Delay = TimeSpan.FromSeconds(10),
    MaxDelay = TimeSpan.FromSeconds(30),
    Mode = ServiceBusRetryMode.Exponential,
    MaxRetries = 3,
};
await using var client = new ServiceBusClient(namespace, new DefaultAzureCredential(), options);

// The sender is responsible for publishing messages to the queue.
ServiceBusSender sender = client.CreateSender(queueName);
ServiceBusMessage message = new ServiceBusMessage("Hello world!");

await sender.SendMessageAsync(message);

// The receiver is responsible for reading messages from the queue.
ServiceBusReceiver receiver = client.CreateReceiver(queueName);
ServiceBusReceivedMessage receivedMessage = await receiver.ReceiveMessageAsync();

string body = receivedMessage.Body.ToString();
Console.WriteLine(body);

Sonraki adımlar

Service Fabric

Bir Service Fabric kümesinde güvenilir hizmetlerin dağıtılması, bu makalede ele alınan olası geçici hataların birçoğuna karşı koruma sağlar. Ancak yine de bazı geçici hatalar oluşabilir. Örneğin, adlandırma hizmeti bir istek aldığında bir yönlendirme isteğinin ortasındaysa özel durum oluşturabilir. Aynı istek 100 milisaniye sonra gelirse büyük olasılıkla başarılı olur.

Dahili olarak, Service Fabric bu tür bir geçici hatayı yönetir. Hizmetlerinizi ayarlarken OperationRetrySettings sınıfını kullanarak bazı ayarları yapılandırabilirsiniz. Aşağıdaki kodda bir örneği gösterilmiştir. Çoğu durumda, bu gerekli olmamalıdır ve varsayılan ayarlar iyi olacaktır.

FabricTransportRemotingSettings transportSettings = new FabricTransportRemotingSettings
{
    OperationTimeout = TimeSpan.FromSeconds(30)
};

var retrySettings = new OperationRetrySettings(TimeSpan.FromSeconds(15), TimeSpan.FromSeconds(1), 5);

var clientFactory = new FabricTransportServiceRemotingClientFactory(transportSettings);

var serviceProxyFactory = new ServiceProxyFactory((c) => clientFactory, retrySettings);

var client = serviceProxyFactory.CreateServiceProxy<ISomeService>(
    new Uri("fabric:/SomeApp/SomeStatefulReliableService"),
    new ServicePartitionKey(0));

Sonraki adımlar

ADO.NET kullanarak SQL Veritabanı

SQL Veritabanı, çeşitli boyutlarda ve hem standart (paylaşılan) hem de premium (paylaşılmayan) hizmet olarak kullanılabilen barındırılan bir SQL Veritabanı.

Yeniden deneme mekanizması

SQL Veritabanı, ADO.NET kullanarak erişildiğinde yeniden denemeler için yerleşik bir destek sunmaz. Ancak, bir isteğin neden başarısız olduğunu belirlemek için isteklerden alınan dönüş kodları kullanılabilir. SQL Veritabanı ağ kapasitesini azaltma hakkında daha fazla bilgi için bkz. Azure SQL Veritabanı kaynak limitleri. İlgili hata kodlarının listesi için bkz. SQL Veritabanı istemci uygulamaları için SQL hata kodları.

SQL Veritabanı için yeniden denemeleri uygulamak üzere Polly kitaplığını kullanabilirsiniz. Daha fazla bilgi için bkz . Polly ile geçici hata işleme.

Yeniden deneme kullanım kılavuzu

ADO.NET kullanarak SQL Veritabanına erişirken aşağıdaki yönergeleri göz önünde bulundurun:

  • Uygun hizmet seçeneğini belirleyin (paylaşılan veya premium). Paylaşılan bir örnek, paylaşılan sunucunun diğer kiracıları tarafından kullanım nedeniyle normalden uzun bağlantı gecikmeleri ve ağ kapasitesi azalmaları yaşayabilir. Daha tahmin edilebilir performansa ve güvenilir düşük gecikme sürelerine sahip işlemler gerekiyorsa premium seçeneğini tercih etmeyi düşünün.
  • Verilerde tutarsızlığa yol açan bir kez etkili olmayan işlemleri önlemek için yeniden denemeleri uygun düzeyde veya kapsamda gerçekleştirdiğinizden emin olun. Tüm işlemlerin tutarsızlığa neden olmadan tekrarlanabilmesi için bir kez etkili olması idealdir. Böyle bir durum söz konusu olmadığında, bir işlem başarısız olursa tüm ilgili değişikliklerin geri alınmasına izin veren bir düzeyde veya kapsamda yeniden deneme gerçekleştirilmelidir; örneğin, işlem kapsamından. Daha fazla bilgi için bkz. Bulut Hizmeti Temelleri Veri Erişim Katmanı – Geçici Hata İşleme.
  • Kısa aralıklarla yalnızca birkaç yeniden denemenin olduğu etkileşimli senaryolar dışında sabit aralık stratejisi Azure SQL Veritabanı kullanılması önerilmez. Bunun yerine, çoğu senaryo için üstel bir geri alma stratejisi kullanmayı göz önünde bulundurun.
  • Bağlantıları tanımlarken bağlantı ve komut zaman aşımları için uygun bir değer seçin. Bir zaman aşımının çok kısa olması, veritabanı meşgul olduğunda bağlantıların erken başarısız olmasına neden olabilir. Zaman aşımının çok uzun olması, başarısız bir bağlantıyı algılamak için çok uzun süre bekleyerek yeniden deneme mantığının doğru çalışmasını önleyebilir. Zaman aşımının değeri, uçtan uca gecikme süresinin bir bileşenidir; her yeniden deneme girişimi için yeniden deneme ilkesinde belirtilen yeniden deneme gecikmesine etkili bir şekilde eklenir.
  • Üstel geri alma yeniden deneme mantığı kullanırken bile bazı yeniden denemeler sonrasında bağlantıyı kapatın ve işlemi yeni bir bağlantıda yeniden deneyin. Aynı işlemin aynı bağlantı üzerinde birden çok kez yeniden denenmesi bağlantı sorunlarına katkıda bulunan bir etken olabilir. Bu tekniğin bir örneği için bkz. Bulut Hizmeti Temelleri Veri Erişim Katmanı – Geçici Hata İşleme.
  • Bağlantı havuzu kullanımda olduğunda (varsayılan) bağlantı kapatılıp yeniden açıldıktan sonra bile havuzdan aynı bağlantının seçilmesi olasılığı vardır. Öyleyse, sorunu çözmek için bir teknik, bağlantıyı yeniden kullanılamaz olarak işaretlemek için SqlConnection sınıfının ClearPool yöntemini çağırmaktır. Ancak, bunu ancak birkaç bağlantı girişimi başarısız olduktan sonra ve yalnızca arızalı bağlantılarla ilgili SQL zaman aşımları (hata kodu -2) gibi belirli bir geçici hata sınıfı ile karşılaşıldığında yapmalısınız.
  • Veri erişim kodu TransactionScope örnekleri olarak başlatılan işlemleri kullanıyorsa, yeniden deneme mantığı bağlantıyı yeniden açmalı ve yeni bir işlem kapsamı başlatmalıdır. Bu nedenle, yeniden denenebilir kod bloğu tüm işlem kapsamını içine almalıdır.

Yeniden deneme işlemleri için aşağıdaki ayarlarla başlamayı düşünün. Bu ayarlar genel amaçlıdır ve işlemleri izlemeniz ve değerleri kendi senaryonuza uyacak şekilde ayarlamanız gerekir.

Bağlam Örnek hedef E2E
maksimum gecikme süresi		 Yeniden deneme stratejisi Ayarlar Değerler Nasıl çalışır?
Etkileşimli, UI,
veya ön plan		 2 sn FixedInterval Yeniden deneme sayısı
Yeniden deneme aralığı
İlk hızlı yeniden deneme		 3
500 ms
true		 Deneme 1 - 0 sn gecikme
Deneme 2 - 500 ms gecikme
Deneme 3 - 500 ms gecikme
Background
veya toplu iş		 30 sn ExponentialBackoff Yeniden deneme sayısı
En düşük geri alma
En yüksek geri alma
Delta geri alma
İlk hızlı yeniden deneme		 5
0 sn
60 sn
2 sn
yanlış		 Deneme 1 - 0 sn gecikme
Deneme 2 - yaklaşık 2 sn gecikme
Deneme 3 - yaklaşık 6 sn gecikme
Deneme 4 - yaklaşık 14 sn gecikme
Deneme 5 - yaklaşık 30 sn gecikme

Not

Uçtan uca gecikme hedefleri, hizmetle kurulan bağlantılar için varsayılan zaman aşımını kabul eder. Daha uzun bağlantı zaman aşımları belirtirseniz, uçtan uca gecikme süresi her yeniden deneme girişimi için bu ek süre kadar genişletilir.

Örnekler

Bu bölümde, Policy sınıfında yapılandırılmış bir dizi yeniden deneme ilkesini kullanarak Azure SQL veritabanına erişmek için nasıl Polly kullanabileceğiniz gösterilmektedir.

Aşağıdaki kod, üstel geri alma ile ExecuteAsync çağıran SqlCommand sınıfı üzerinde bir genişletme yöntemi göstermektedir.

public async static Task<SqlDataReader> ExecuteReaderWithRetryAsync(this SqlCommand command)
{
    GuardConnectionIsNotNull(command);

    var policy = Policy.Handle<Exception>().WaitAndRetryAsync(
        retryCount: 3, // Retry 3 times
        sleepDurationProvider: attempt => TimeSpan.FromMilliseconds(200 * Math.Pow(2, attempt - 1)), // Exponential backoff based on an initial 200 ms delay.
        onRetry: (exception, attempt) =>
        {
            // Capture some information for logging/telemetry.
            logger.LogWarn($"ExecuteReaderWithRetryAsync: Retry {attempt} due to {exception}.");
        });

    // Retry the following call according to the policy.
    await policy.ExecuteAsync<SqlDataReader>(async token =>
    {
        // This code is executed within the Policy

        if (conn.State != System.Data.ConnectionState.Open) await conn.OpenAsync(token);
        return await command.ExecuteReaderAsync(System.Data.CommandBehavior.Default, token);

    }, cancellationToken);
}

Bu zaman uyumsuz genişletme yöntemi aşağıdaki gibi kullanılabilir.

var sqlCommand = sqlConnection.CreateCommand();
sqlCommand.CommandText = "[some query]";

using (var reader = await sqlCommand.ExecuteReaderWithRetryAsync())
{
    // Do something with the values
}

Sonraki adımlar

Entity Framework 6 kullanarak SQL Veritabanı

SQL Veritabanı, çeşitli boyutlarda ve hem standart (paylaşılan) hem de premium (paylaşılmayan) hizmet olarak kullanılabilen barındırılan bir SQL Veritabanı. Entity Framework, .NET geliştiricilerinin etki alanına özel nesneler kullanarak ilişkisel verilerle çalışmasını sağlayan bir nesne-ilişkisel eşleyicisidir. Geliştiricilerin genellikle yazması gereken çoğu veri erişim kodu gereksinimini ortadan kaldırır.

Yeniden deneme mekanizması

Entity Framework 6.0 ve üzerini kullanarak SQL Veritabanı erişirken Bağlantı dayanıklılığı / yeniden deneme mantığı adlı bir mekanizma aracılığıyla yeniden deneme desteği sağlanır. Yeniden deneme mekanizmasının ana özellikleri şunlardır:

  • Birincil soyutlama IDbExecutionStrategy arabirimidir. Bu arabirim:
    • Zaman uyumlu ve zaman uyumsuz Execute yöntemlerini tanımlar.
    • Doğrudan kullanılabilen veya varsayılan bir strateji olarak veritabanı bağlamında yapılandırılabilen, sağlayıcı adı ile ya da sağlayıcı adı ve sunucu adı ile eşlenebilen sınıfları tanımlar. Bir bağlamda yapılandırıldığında, yeniden denemeler belirli bir bağlam işlemi için birden fazla olabilecek tek veritabanı işlemi düzeyinde gerçekleşir.
    • Başarısız bir bağlantının ne zaman ve nasıl yeniden deneneceğini tanımlar.
  • IDbExecutionStrategy arabiriminin birkaç yerleşik uygulamasını içerir:
    • Varsayılan: yeniden deneme yok.
    • SQL Veritabanı için varsayılan (otomatik): yeniden deneme yoktur, ancak özel durumları inceler ve SQL Veritabanı stratejisini kullanma önerisiyle sarmalar.
    • SQL Veritabanı için varsayılan: üstel (temel sınıftan devralınan) artı SQL Veritabanı algılama mantığı.
  • Rastgele seçim içeren bir üstel geri alma stratejisi uygular.
  • Yerleşik yeniden deneme sınıfları durum bilgisine sahiptir ve iş parçacığı açısından güvenli değildir. Ancak, geçerli işlem tamamlandıktan sonra yeniden kullanılabilirler.
  • Belirtilen yeniden deneme sayısı aşılırsa sonuçlar yeni bir özel durumda sarmalanır. Geçerli özel durumun kabarması gerekmez.

İlke yapılandırması

Entity Framework kullanan SQL Veritabanı 6.0 ve üzerine erişirken yeniden deneme desteği sağlanır. Yeniden deneme ilkeleri programlı olarak yapılandırılır. Yapılandırma her işlem için değiştirilemez.

Varsayılan olarak bağlam üzerinde bir stratejiyi yapıladırırken, isteğe bağlı olarak yeni strateji oluşturan bir işlev belirtin. Aşağıdaki kod, DbConfiguration temel sınıfını genişleten bir yeniden deneme yapılandırma sınıfını nasıl oluşturabileceğinizi gösterir.

public class BloggingContextConfiguration : DbConfiguration
{
  public BlogConfiguration()
  {
    // Set up the execution strategy for SQL Database (exponential) with 5 retries and 4 sec delay
    this.SetExecutionStrategy(
         "System.Data.SqlClient", () => new SqlAzureExecutionStrategy(5, TimeSpan.FromSeconds(4)));
  }
}

Daha sonra uygulama başladığında DbConfiguration örneğinin SetConfiguration yöntemini kullanarak bunu tüm işlemler için varsayılan yeniden deneme stratejisi olarak belirtebilirsiniz. Varsayılan olarak EF, yapılandırma sınıfını otomatik olarak bulur ve kullanır.

DbConfiguration.SetConfiguration(new BloggingContextConfiguration());

Bir DbConfigurationType özniteliği ile bağlam sınıfına açıklama ekleyerek bir bağlamiçin yeniden deneme yapılandırma sınıfı belirtebilirsiniz. Ancak, yalnızca bir yapılandırma sınıfınız varsa EF bağlama açıklama eklemeye gerek kalmadan bu sınıfı kullanır.

[DbConfigurationType(typeof(BloggingContextConfiguration))]
public class BloggingContext : DbContext

Belirli işlemler için farklı yeniden deneme stratejileri kullanmanız veya belirli işlemler için yeniden denemeleri devre dışı bırakmanız gerekirse, CallContext içinde bir bayrak ayarlayarak stratejileri askıya almanıza veya takas etmenize olanak tanıyan bir yapılandırma sınıfı oluşturabilirsiniz. Yapılandırma sınıfı bu bayrağı kullanarak stratejiler arasında geçiş yapabilir veya sağladığınız stratejiyi devre dışı bırakıp varsayılan stratejiyi kullanabilir. Daha fazla bilgi için bkz . Yürütme Stratejisini Askıya Alma (EF6 ileri).

Tekil işlemler için belirli yeniden deneme stratejileri kullanmaya yönelik başka bir teknik ise gerekli strateji sınıfının bir örneğini oluşturmak ve parametreler aracılığıyla istenen ayarları sağlamaktır. Daha sonra ExecuteAsync yöntemini çağırın.

var executionStrategy = new SqlAzureExecutionStrategy(5, TimeSpan.FromSeconds(4));
var blogs = await executionStrategy.ExecuteAsync(
    async () =>
    {
        using (var db = new BloggingContext("Blogs"))
        {
            // Acquire some values asynchronously and return them
        }
    },
    new CancellationToken()
);

Bir DbConfiguration sınıfını kullanmanın en basit yolu, onu DbContext sınıfı ile aynı bütünleştirilmiş kod içinde konumlandırmaktır. Ancak, farklı etkileşimli ve arka plan yeniden deneme stratejileri gibi farklı senaryolarda aynı bağlam gerektiğinde bu uygun değildir. Ayrı AppDomainlerde farklı bağlamlar yürütülüyorsa, yapılandırma dosyasındaki yapılandırma sınıflarını belirtmeye yönelik yerleşik desteği kullanabilir veya kod kullanarak açıkça ayarlayabilirsiniz. Aynı AppDomain içinde farklı bağlamların yürütülmesi gerekiyorsa özel bir çözüm gerekli olur.

Daha fazla bilgi için bkz . Kod Tabanlı Yapılandırma (EF6 ileri).

Aşağıdaki tabloda EF6 kullanırken yerleşik yeniden deneme ilkelerine ilişkin varsayılan ayarlar gösterilmektedir.

Ayar Default value Anlamı
İlke Üstel Üstel geri alma.
MaxRetryCount 5 En fazla yeniden deneme sayısı.
MaxDelay 30 saniye Yeniden denemeler arasındaki en büyük gecikme. Bu değer, gecikme serisinin nasıl hesaplanmış olduğunu etkilemez. Yalnızca bir üst sınır tanımlar.
DefaultCoefficient 1 saniye Üstel geri alma hesaplaması için katsayı. Bu değer değiştirilemez.
DefaultRandomFactor 1.1 Her giriş için rastgele bir gecikme eklerken kullanılan çarpan. Bu değer değiştirilemez.
DefaultExponentialBase 2 Sonraki gecikmeyi hesaplamak için kullanılan çarpan. Bu değer değiştirilemez.

Yeniden deneme kullanım kılavuzu

EF6 kullanarak SQL Veritabanına erişirken aşağıdaki yönergeleri göz önünde bulundurun:

  • Uygun hizmet seçeneğini belirleyin (paylaşılan veya premium). Paylaşılan bir örnek, paylaşılan sunucunun diğer kiracıları tarafından kullanım nedeniyle normalden uzun bağlantı gecikmeleri ve ağ kapasitesi azalmaları yaşayabilir. Tahmin edilebilir performansa ve güvenilir düşük gecikme sürelerine sahip işlemler gerekiyorsa premium seçeneğini tercih etmeyi düşünün.

  • Azure SQL Veritabanı ile kullanmak için sabit aralık stratejisi önerilmez. Bunun yerine, hizmet aşırı yüklenebileceği ve uzun gecikmelerin kurtarılması için daha fazla beklemek gerekeceği için bir üstel geri alma stratejisi kullanın.

  • Bağlantıları tanımlarken bağlantı ve komut zaman aşımları için uygun bir değer seçin. Zaman aşımını hem iş mantığınıza hem de testlere göre belirleyin. Zaman içinde veri hacimleri ve iş süreçleri değiştikçe bu değeri değiştirmeniz gerekebilir. Bir zaman aşımının çok kısa olması, veritabanı meşgul olduğunda bağlantıların erken başarısız olmasına neden olabilir. Zaman aşımının çok uzun olması, başarısız bir bağlantıyı algılamak için çok uzun süre bekleyerek yeniden deneme mantığının doğru çalışmasını önleyebilir. Zaman aşımının değeri, uçtan uca gecikme süresinin bir bileşenidir, ancak bağlamı kaydederken kaç komutun yürütüleceğini kolayca saptayamazsınız. DbContext örneğinin CommandTimeout özelliğini ayarlayarak varsayılan zaman aşımını değiştirebilirsiniz.

  • Entity Framework, yapılandırma dosyalarında tanımlanan yeniden deneme yapılandırmalarını destekler. Ancak, Azure’da en üst düzey esneklik için yapılandırmayı uygulama içinde program aracılığıyla oluşturmayı düşünmeniz gerekir. Yeniden deneme sayısı ve yeniden deneme aralıkları gibi yeniden deneme ilkelerine özgü parametreler, hizmet yapılandırma dosyasında depolanabilir ve uygun ilkeleri oluşturmak için çalışma zamanında kullanılabilir. Böylece ayarlar uygulamanın yeniden başlatılmasına gerek olmadan değiştirilebilir.

Yeniden deneme işlemleri için aşağıdaki ayarlarla başlamayı düşünün. Yeniden deneme girişimleri arasındaki gecikmeyi belirtemezsiniz (sabittir ve üstel bir dizi olarak oluşturulur). Özel bir yeniden deneme stratejisi oluşturmadığınız sürece, aşağıda gösterildiği gibi yalnızca en yüksek değerleri belirtebilirsiniz. Bu ayarlar genel amaçlıdır ve işlemleri izlemeniz ve değerleri kendi senaryonuza uyacak şekilde ayarlamanız gerekir.

Bağlam Örnek hedef E2E
maksimum gecikme süresi		 Yeniden deneme ilkesi Ayarlar Değerler Nasıl çalışır?
Etkileşimli, UI,
veya ön plan		 2 saniye Üstel MaxRetryCount
MaxDelay		 3
750 ms		 Deneme 1 - 0 sn gecikme
Deneme 2 - 750 ms gecikme
Deneme 3 - 750 ms gecikme
Background
veya toplu iş		 30 saniye Üstel MaxRetryCount
MaxDelay		 5
12 saniye		 Deneme 1 - 0 sn gecikme
Deneme 2 - yaklaşık 1 sn gecikme
Deneme 3 - yaklaşık 3 sn gecikme
Deneme 4 - yaklaşık 7 sn gecikme
Deneme 5 - 12 sn gecikme

Not

Uçtan uca gecikme hedefleri, hizmetle kurulan bağlantılar için varsayılan zaman aşımını kabul eder. Daha uzun bağlantı zaman aşımları belirtirseniz, uçtan uca gecikme süresi her yeniden deneme girişimi için bu ek süre kadar genişletilir.

Örnekler

Aşağıdaki kod örneğinde Entity Framework kullanan bir basit veri erişimi çözümü tanımlanmaktadır. DbConfiguration özelliğini genişleten BlogConfiguration adlı bir sınıfın örneğini tanımlayarak belirli bir yeniden deneme stratejisi ayarlar.

using System;
using System.Collections.Generic;
using System.Data.Entity;
using System.Data.Entity.SqlServer;
using System.Threading.Tasks;

namespace RetryCodeSamples
{
    public class BlogConfiguration : DbConfiguration
    {
        public BlogConfiguration()
        {
            // Set up the execution strategy for SQL Database (exponential) with 5 retries and 12 sec delay.
            // These values could be loaded from configuration rather than being hard-coded.
            this.SetExecutionStrategy(
                    "System.Data.SqlClient", () => new SqlAzureExecutionStrategy(5, TimeSpan.FromSeconds(12)));
        }
    }

    // Specify the configuration type if more than one has been defined.
    // [DbConfigurationType(typeof(BlogConfiguration))]
    public class BloggingContext : DbContext
    {
        // Definition of content goes here.
    }

    class EF6CodeSamples
    {
        public async static Task Samples()
        {
            // Execution strategy configured by DbConfiguration subclass, discovered automatically or
            // or explicitly indicated through configuration or with an attribute. Default is no retries.
            using (var db = new BloggingContext("Blogs"))
            {
                // Add, edit, delete blog items here, then:
                await db.SaveChangesAsync();
            }
        }
    }
}

Entity Framework yeniden deneme mekanizmasını kullanmaya ilişkin diğer örnekler Bağlantı dayanıklılığı / yeniden deneme mantığı bölümünde bulunabilir.

Entity Framework Core kullanarak SQL Veritabanı

Entity Framework Core, .NET Core geliştiricilerinin etki alanına özel nesneler kullanarak verilerle çalışmasını sağlayan bir nesne-ilişkisel eşleyicisidir. Geliştiricilerin genellikle yazması gereken çoğu veri erişim kodu gereksinimini ortadan kaldırır. Entity Framework'ün bu sürümü sıfırdan yazılmıştır EF6.x sürümünün tüm özelliklerini otomatik olarak devralmaz.

Yeniden deneme mekanizması

Bağlantı dayanıklılığı adlı bir mekanizma aracılığıyla Entity Framework Core kullanılarak SQL Veritabanı erişilirken yeniden deneme desteği sağlanır. Bağlantı dayanıklılığı EF Core 1.1.0 sürümünde kullanıma sunulmuştur.

Birincil soyutlama IExecutionStrategy arabirimidir. Azure SQL de dahil olmak üzere SQL Server için yürütme stratejisi, yeniden denenebilecek özel durum türlerinin farkındadır ve en fazla yeniden deneme sayısı, yeniden denemeler arasındaki gecikme vb. için mantıklı varsayılanlara sahiptir.

Örnekler

Aşağıdaki kod, veritabanı ile bir oturumu temsil eden DbContext nesnesini yapılandırırken otomatik yeniden denemeleri etkinleştirir.

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder
        .UseSqlServer(
            @"Server=(localdb)\mssqllocaldb;Database=EFMiscellaneous.ConnectionResiliency;Trusted_Connection=True;",
            options => options.EnableRetryOnFailure());
}

Aşağıdaki kod, bir yürütme stratejisi kullanarak otomatik yeniden denemelerle bir işlemi yürütmeyi göstermektedir. İşlem bir temsilcide tanımlanır. Geçici bir hata oluşursa yürütme stratejisi temsilciyi yeniden çağırır.

using (var db = new BloggingContext())
{
    var strategy = db.Database.CreateExecutionStrategy();

    strategy.Execute(() =>
    {
        using (var transaction = db.Database.BeginTransaction())
        {
            db.Blogs.Add(new Blog { Url = "https://blogs.msdn.com/dotnet" });
            db.SaveChanges();

            db.Blogs.Add(new Blog { Url = "https://blogs.msdn.com/visualstudio" });
            db.SaveChanges();

            transaction.Commit();
        }
    });
}

Azure Depolama

Azure Depolama hizmetleri blob depolamayı, dosyaları ve depolama kuyruklarını içerir.

Bloblar, Kuyruklar ve Dosyalar

ClientOptions Sınıfı, tüm istemci seçenek türleri için temel türdür ve Tanılama, Yeniden Deneme, Aktarım gibi çeşitli ortak istemci seçeneklerini kullanıma sunar. Azure Kuyruk, Blob ve Dosya Depolama'ya bağlanmak için istemci yapılandırma seçeneklerini sağlamak için ilgili türetilmiş türü kullanmanız gerekir. Sonraki örnekte, bir istemciyi Azure Kuyruk Hizmeti'ne bağlanacak şekilde yapılandırmak için QueueClientOptions sınıfını (ClientOptions'tan türetilmiştir) kullanırsınız. Retry özelliği, yeniden deneme girişimlerinin nasıl yapıldığını ve bir hatanın yeniden denenmeye nasıl uygun olduğunu etkilemek için belirtilebilen seçenekler kümesidir.

using System;
using System.Threading;
using Azure.Core;
using Azure.Identity;
using Azure.Storage;
using Azure.Storage.Queues;
using Azure.Storage.Queues.Models;

namespace RetryCodeSamples
{
    class AzureStorageCodeSamples {

        public async static Task Samples() {

               // Provide the client configuration options for connecting to Azure Queue Storage
                QueueClientOptions queueClientOptions = new QueueClientOptions()
                {
                    Retry = {
                    Delay = TimeSpan.FromSeconds(2),     //The delay between retry attempts for a fixed approach or the delay on which to base
                                                         //calculations for a backoff-based approach
                    MaxRetries = 5,                      //The maximum number of retry attempts before giving up
                    Mode = RetryMode.Exponential,        //The approach to use for calculating retry delays
                    MaxDelay = TimeSpan.FromSeconds(10)  //The maximum permissible delay between retry attempts
                    },

                    GeoRedundantSecondaryUri = new Uri("https://...")
                    // If the GeoRedundantSecondaryUri property is set, the secondary Uri will be used for GET or HEAD requests during retries.
                    // If the status of the response from the secondary Uri is a 404, then subsequent retries for the request will not use the
                    // secondary Uri again, as this indicates that the resource may not have propagated there yet.
                    // Otherwise, subsequent retries will alternate back and forth between primary and secondary Uri.
                };

                Uri queueServiceUri = new Uri("https://storageaccount.queue.core.windows.net/");
                string accountName = "Storage account name";
                string accountKey = "storage account key";

                // Create a client object for the Queue service, including QueueClientOptions.
                QueueServiceClient serviceClient = new QueueServiceClient(queueServiceUri, new DefaultAzureCredential(), queueClientOptions);

                CancellationTokenSource source = new CancellationTokenSource();
                CancellationToken cancellationToken = source.Token;

                // Return an async collection of queues in the storage account.
                var queues = serviceClient.GetQueuesAsync(QueueTraits.None, null, cancellationToken);

Tablo Desteği

Not

WindowsAzure.Storage Nuget Paketi ve Microsoft.Azure.Cosmos.Table Nuget Paketi kullanım dışı bırakıldı. Azure tablo desteği için bkz . Azure.Data.Tables Nuget Paketi

Yeniden deneme mekanizması

İstemci kitaplığı, diğer istemci kitaplıklarına çapraz kesme hizmetleri sağlayan bir kitaplık olan Azure Core kitaplığını temel alır.

İstemci uygulaması bir hizmete ağ isteği göndermeye çalıştığında hata oluşmasının birçok nedeni vardır. Bazı örnekler zaman aşımı, ağ altyapısı hataları, kısıtlama/meşgul nedeniyle isteği reddeden hizmet, hizmet ölçeğinin küçültülmesi nedeniyle sonlandırılan hizmet örneği, hizmet örneğinin başka bir sürümle değiştirilmesi, işlenmeyen özel durum nedeniyle hizmetin kilitlenmesi vb. verilebilir. Yerleşik bir yeniden deneme mekanizması sunarak (tüketicinin geçersiz kabileceği varsayılan bir yapılandırmayla), SDK'larımız ve tüketicinin uygulaması bu tür hatalara dayanıklı hale gelir. Bazı hizmetlerin her istek için gerçek para ücretlendirdiğini ve bu nedenle tüketicilerin dayanıklılık konusunda tasarruf etmek istediklerinde yeniden denemeleri tamamen devre dışı bırakabilmeleri gerektiğini unutmayın.

İlke yapılandırması

Yeniden deneme ilkeleri programlı olarak yapılandırılır. Yapılandırma RetryOption sınıfını temel alır. TableClientOptions üzerinde ClientOptions'dan devralınan bir öznitelik var

var tableClientOptions = new TableClientOptions();
tableClientOptions.Retry.Mode = RetryMode.Exponential;
tableClientOptions.Retry.MaxRetries = 5;
var serviceClient = new TableServiceClient("<endpoint>", new DefaultAzureCredential(), tableClientOptions);

Aşağıdaki tablolarda yerleşik yeniden deneme ilkelerine yönelik olasılıklar gösterilmektedir.

RetryOption

Ayar Anlamı
Delay (Gecikme Süresi) Sabit bir yaklaşım için yeniden deneme girişimleri arasındaki gecikme veya geri alma tabanlı bir yaklaşım için hesaplamaların temel alındığı gecikme. Hizmet bir Retry-After yanıt üst bilgisi sağlarsa, sonraki yeniden deneme üst bilgi değeri tarafından belirtilen süre kadar geciktirilir.
MaxDelay Hizmet bir Yeniden Deneme Sonrası yanıt üst bilgisi sağlamadığında yeniden deneme girişimleri arasındaki izin verilen en yüksek gecikme. Hizmet bir Retry-After yanıt üst bilgisi sağlarsa, sonraki yeniden deneme üst bilgi değeri tarafından belirtilen süre kadar geciktirilir.
Mod Yeniden deneme gecikmelerini hesaplamak için kullanılacak yaklaşım.
NetworkTimeout Tek bir ağ işlemlerine uygulanan zaman aşımı.

RetryMode

Ayar Anlamı
Üstel Yeniden deneme girişimleri, geri alma stratejisine göre gecikecek ve her deneme yeniden denemeden önce beklediği süreyi artıracaktır.
MaxDelay Yeniden deneme girişimleri sabit aralıklarla gerçekleşir; her gecikme tutarlı bir süredir.

Telemetri

Günlükleri görmenin en basit yolu konsol günlüğünü etkinleştirmektir. Konsola ileti çıkışı veren bir Azure SDK günlük dinleyicisi oluşturmak için AzureEventSourceListener.CreateConsoleLogger yöntemini kullanın.

// Setup a listener to monitor logged events.
using AzureEventSourceListener listener = AzureEventSourceListener.CreateConsoleLogger();

Örnekler

Aşağıdaki kod örneğini depolama öykünücüsü kapatılmış olarak yürütmek, konsoldaki yeniden denemeler hakkındaki bilgileri görmemizi sağlar.

using Azure.Core;
using Azure.Core.Diagnostics;
using Azure.Data.Tables;
using Azure.Data.Tables.Models;
using Azure.Identity;

namespace RetryCodeSamples
{
    class AzureStorageCodeSamples
    {
        private const string tableName = "RetryTestTable";

        public async static Task SamplesAsync()
        {
            // Setup a listener to monitor logged events.
            using AzureEventSourceListener listener = AzureEventSourceListener.CreateConsoleLogger();

            var tableClientOptions = new TableClientOptions();
            tableClientOptions.Retry.Mode = RetryMode.Exponential;
            tableClientOptions.Retry.MaxRetries = 5;

            var serviceClient = new TableServiceClient("<endpoint>", new DefaultAzureCredential(), tableClientOptions);

            TableItem table = await serviceClient.CreateTableIfNotExistsAsync(tableName);
            Console.WriteLine($"The created table's name is {table.Name}.");
        }
    }
}

Genel REST ve yeniden deneme yönergeleri

Azure veya üçüncü taraf hizmetlerine erişirken aşağıdakileri göz önünde bulundurun:

  • Yeniden denemeleri yönetirken, belki de yeniden kullanılabilir bir kod halinde sistematik bir yaklaşım kullanın; böylece tüm istemciler ve tüm çözümlerde tutarlı bir yöntem uygulayabilirsiniz.

  • Hedef hizmet veya istemcinin yerleşik bir yeniden deneme mekanizması yoksa yeniden denemeleri yönetmek için Polly gibi bir yeniden deneme çerçevesi kullanmayı göz önünde bulundurun. Bunun yapılması tutarlı bir yeniden deneme davranışı uygulamanıza yardımcı olur ve hedef hizmet için uygun bir varsayılan yeniden deneme stratejisi sağlayabilir. Ancak, geçici hataları göstermek için özel durumları kullanmayan standart olmayan davranışlara sahip hizmetler için veya yeniden deneme davranışını yönetmek için Yeniden Deneme Yanıtı yanıtı kullanmak istiyorsanız özel yeniden deneme kodu oluşturmanız gerekebilir.

  • Geçici algılama mantığı, REST çağrılarını gerçekleştirmek için kullandığını gerçek istemci API’sine bağlıdır. Yeni HttpClient sınıfı gibi bazı istemciler, başarılı olmayan HTTP durum koduyla tamamlanmış istekler için özel durumlar oluşturmaz.

  • Hizmetten döndürülen HTTP durum kodu, hatanın geçici olup olmadığını belirtmeye yardımcı olabilir. Bir istemci veya yeniden deneme çerçevesi tarafından durum koduna erişmek veya eşdeğer özel durum türünü belirlemek için oluşturulan özel durumları incelemeniz gerekebilir. Aşağıdaki HTTP kodları genellikle bir yeniden denemenin uygun olduğunu gösterir:

    • 408 İstek Zaman Aşımı
    • 429 Çok Fazla İstek Var
    • 500 İç Sunucu Hatası
    • 502 Hatalı Ağ Geçidi
    • 503 Hizmet Kullanılamıyor
    • 504 Ağ Geçidi Zaman Aşımı

  • Yeniden deneme mantığınız özel durumları temel alıyorsa, aşağıdakiler genellikle bağlantı kurulamayan geçici bir hatayı gösterir:

    • WebExceptionStatus.ConnectionClosed
    • WebExceptionStatus.ConnectFailure
    • WebExceptionStatus.Timeout
    • WebExceptionStatus.RequestCanceled

  • Hizmet kullanılamıyor durumunda hizmet Retry-After yanıt üst bilgisini yeniden veya farklı özel üst bilgiyi yeniden denemeden önce uygun gecikmeyi gösterebilir. Hizmetler ayrıca özel üst bilgi olarak ya da yanıtın içeriğine eklenmiş halde ek bilgi gönderebilir.

  • 408 İstek Zaman Aşımı ve 429 Çok Fazla İstek dışında istemci hatalarını (4xx aralığındaki hatalar) temsil eden durum kodları için yeniden denemeyin.

  • Yeniden deneme stratejilerinizi ve mekanizmalarınızı, farklı ağ durumları ve değişen sistem yükleri gibi birkaç koşul altında iyice test edin.

Yeniden deneme stratejileri

Yeniden deneme stratejisi aralıklarının tipik türleri şunlardır:

  • Üstel. Yeniden denemeler arasındaki aralığı belirlemek için rastgele bir üstel geri alma yaklaşımı kullanarak belirtilen sayıda yeniden deneme gerçekleştiren bir yeniden deneme ilkesi. Örneğin:

    var random = new Random();

var delta = (int)((Math.Pow(2.0, currentRetryCount) - 1.0) *
            random.Next((int)(this.deltaBackoff.TotalMilliseconds * 0.8),
            (int)(this.deltaBackoff.TotalMilliseconds * 1.2)));
var interval = (int)Math.Min(checked(this.minBackoff.TotalMilliseconds + delta),
                this.maxBackoff.TotalMilliseconds);
retryInterval = TimeSpan.FromMilliseconds(interval);

  • Artımlı. Belirtilen sayıda yeniden deneme denemesi ve yeniden denemeler arasında artımlı zaman aralığı içeren bir yeniden deneme stratejisi. Örneğin:

    retryInterval = TimeSpan.FromMilliseconds(this.initialInterval.TotalMilliseconds +
                (this.increment.TotalMilliseconds * currentRetryCount));

  • LinearRetry. Yeniden denemeler arasında belirli bir sabit zaman aralığı kullanarak belirtilen sayıda yeniden deneme gerçekleştiren bir yeniden deneme ilkesi. Örneğin:

    retryInterval = this.deltaBackoff;

Polly ile geçici hata işleme

Polly , yeniden denemeleri ve devre kesici stratejilerini program aracılığıyla işleyen bir kitaplıktır. Polly projesi .NET Foundation’ın bir üyesidir. İstemcinin yeniden denemeleri yerel olarak desteklemediği hizmetler için Polly geçerli bir alternatiftir ve doğru şekilde uygulanması zor olabilecek özel yeniden deneme kodu yazma gereğini önler. Polly ayrıca yeniden denemeleri günlüğe kaydetmeniz için oluşan hataları izlemenin bir yolunu sağlar.

Sonraki adımlar