Azure hizmetleri için yeniden deneme Kılavuzu

Ç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 Azure hizmetlerinin büyük bölümü için yeniden deneme mekanizması özelliklerini özetler ve söz konusu hizmet için yeniden deneme mekanizmasını kullanma, uyarlama ve 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.

Azure Active Directory

Azure Active Directory (Azure AD), temel dizin hizmetleri, gelişmiş kimlik yönetimi, güvenlik ve uygulama erişim yönetimi özelliklerini bir araya getiren kapsamlı bir kimlik ve erişim yönetimi bulut çözümüdür. Ayrıca, Azure AD geliştiricilerin uygulamalarına olan erişimi denetleyebileceği, merkezi ilke ve kurallara dayanan bir kimlik yönetim platformu sunar.

Yeniden deneme mekanizması

Microsoft kimlik doğrulama kitaplığı 'nda (MSAL) Azure Active Directory için yerleşik bir yeniden deneme mekanizması vardır. Beklenmedik kilitleme işlemleri önlemek için, üçüncü taraf kitaplıkların ve uygulama kodunun başarısız bağlantıları yeniden denememesi , ancak msal yeniden denemeleri işlemesini öneririz.

Yeniden deneme kullanım kılavuzu

Azure Active Directory 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.
• Azure Active Directory için REST API kullanıyorsanız, sonuç kodu 429 (çok fazla istek) veya 5xx aralığında bir hata olması durumunda işlemi yeniden deneyin. Diğer hatalar için yeniden denemeyin.
• 429 hata için, yalnızca retry-After üst bilgisinde belirtilen süreden sonra yeniden deneyin.
• 5 xx hata için, yanıttan sonra ilk yeniden denemeye kadar üstel geri dönüş kullanın.
• 429 ve 5 xx dışındaki hatalarda yeniden denemeyin.

Daha fazla bilgi

• Microsoft kimlik doğrulama kitaplığı (MSAL)

Cosmos DB

Cosmos DB, şemasız JSON verilerini destekleyen, tam olarak yönetilen bir çok modelli 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ı

CosmosClient sınıfı başarısız girişimleri otomatik olarak yeniden dener. Yeniden deneme sayısını ve en uzun bekleme süresini ayarlamak için Cosmosclientoptionsöğesini yapılandırın. İstemcinin oluşturduğu özel durumlar, yeniden deneme ilkesi dışındadır veya geçici hatalar değildir. Cosmos DB istemciyi kısıtlarsa HTTP 429 hatasını döndürür. Sınıftaki durum kodunu denetleyin CosmosException .

İlke yapılandırması

Aşağıdaki tabloda CosmosClientOptions sınıfına ilişkin varsayılan ayarlar gösterilmektedir.

Örnek

CosmosClient cosmosClient = new CosmosClient("connection-string", new CosmosClientOptions()
{
    MaxRetryAttemptsOnRateLimitedRequests = 5,
    MaxRetryWaitTimeOnRateLimitedRequests = TimeSpan.FromSeconds(15)
});

Telemetri

Yeniden deneme girişimleri bir .NET TraceSource aracılığıyla yapılandırılmamış izleme iletileri halinde günlüğe kaydedilir. Olayları yakalamak ve uygun bir hedef günlüğüne yazmak için bir TraceListener yapılandırmanız gerekir.

Örneğin, App.config dosyanıza aşağıdakileri eklerseniz, izlemeler yürütülebilir dosya ile aynı konumdaki bir metin dosyasında oluşturulur:

<configuration>
  <system.diagnostics>
    <switches>
      <add name="SourceSwitch" value="Verbose"/>
    </switches>
    <sources>
      <source name="DocDBTrace" switchName="SourceSwitch" switchType="System.Diagnostics.SourceSwitch" >
        <listeners>
          <add name="MyTextListener" type="System.Diagnostics.TextWriterTraceListener" traceOutputOptions="DateTime,ProcessId,ThreadId" initializeData="CosmosDBTrace.txt"></add>
        </listeners>
      </source>
    </sources>
  </system.diagnostics>
</configuration>

Event Hubs

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

Yeniden deneme mekanizması

Azure Event Hubs İstemci Kitaplığındaki yeniden deneme davranışı, EventHubClient sınıfındaki RetryPolicy özelliği tarafından denetlenir. Varsayılan ilke, Azure Event Hub geçici EventHubsException veya OperationCanceledException hatası döndürdüğünde üstel geri alma ile yeniden dener. Event Hubs için varsayılan yeniden deneme ilkesi, en fazla 30 saniyelik bir üstel geri dönüş zamanına 9 kez yeniden denendir.

Örnek

EventHubClient client = EventHubClient.CreateFromConnectionString("[event_hub_connection_string]");
client.RetryPolicy = RetryPolicy.Default;

Daha fazla bilgi

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

IoT Hub

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

Yeniden deneme mekanizması

Azure IoT cihaz SDK 'Sı, ağ, protokol veya uygulamadaki hataları tespit edebilir. Hata türüne göre SDK, yeniden deneme gerçekleştirilmesi gerekip gerekmediğini denetler. Hata kurtarılabilirIse, SDK, yapılandırılan yeniden deneme ilkesini kullanarak yeniden denemeye başlar.

Varsayılan yeniden deneme ilkesi rastgele değişim ile üstel olarak yeniden kapalıdır, ancak yapılandırılabilir.

İlke yapılandırması

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

Daha fazla bilgi

• IoT Hub yeniden deneme ilkesi
• Cihaz bağlantısının kesilmesi IoT Hub sorunlarını giderme

Redis için Azure Cache

Redsıs için Azure önbelleği, popüler açık kaynaklı redo önbelleğini temel alan hızlı veri erişimi ve düşük gecikmeli ö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 istemcisinin tek bir bağlantı üzerinden çoğullama kullandığını unutmayın. Ö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. Redsıs istemcisi, aşağıdakiler de dahil olmak üzere 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 üzerinden 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.

Yeniden deneme kullanım kılavuzu

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

• StackExchange Redis istemcisi kendi yeniden denemelerini yönetir, ancak yalnızca uygulama ilk kez başlatıldığında önbellekle bağlantı kurarken bunu yapar. Bu bağlantıyı kurmak için bağlantı zaman aşımı, yeniden deneme sayısı ve yeniden denemeler arasındaki süreyi yapılandırabilirsiniz, ancak yeniden deneme ilkesi önbelleğe yönelik işlemler için geçerli olmaz.
• Ç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ğinin yalnızca kod tarafından ayarlanabildiğini unutmayın.

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.

Daha fazla bilgi

• Redis web sitesi

Azure Search

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ı

Azure Search SDK’sında yeniden deneme davranışı SetRetryPolicy ve SearchIndexClient sınıflarında SetRetryPolicy yöntemiyle denetlenir. Azure Search bir 5xx veya 408 (İstek Zaman Aşımı) yanıtı döndürdüğünde üstel geri alma ile yeniden dener.

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ı

Service Bus soyut RetryPolicy sınıfının uygulamaları kullanılarak yeniden denemeler uygulanır. Ad alanı ve yapılandırma ayrıntılarının bazıları, hangi Service Bus SDK paketinin kullanıldıklarına bağlıdır:

İstemci kitaplığının her iki sürümü de aşağıdaki yerleşik uygulamasını RetryPolicy sağlar:

• RetryExponential. Üstel geri tarak uygulayan.

• NoRetry. Yeniden deneme gerçekleştirmez. Service Bus API düzeyinde yeniden denemelere ihtiyacınız yoksa, örneğin başka bir işlem toplu veya çok adımlı bir işlem kapsamında yeniden denemeleri yönetirken bu sınıfı kullanın.

özelliği, RetryPolicy.Default türünde bir varsayılan ilke RetryExponential döndürür. Bu ilke nesnesi aşağıdaki ayarlara sahip:

Ayrıca, aşağıdaki özellik eski pakette WindowsAzure.ServiceBus tanımlanmıştır:

Service Bus eylemleri, mesajlaşma özel durumlarında listelenen bir Service Bus özel durumlarını Service Bus olabilir. İstemciden döndürülen Service Bus istemcinin işlemi yeniden denemesi gerekip gerek olmadığını belirten IsTransient özelliğini ortaya çıkarır. Yerleşik RetryExponential ilkesi, yeniden denemeden önce bu özelliği denetler.

Karşılaşılan son özel durum ServerBusyExceptionise, RetryExponential ilkesi hesaplanan yeniden deneme aralığına 10 saniye ekler. Bu değer değiştirilemez.

Özel uygulamalar, yeniden deneme eylemleri üzerinde daha ince denetim sağlamak için özel durum türü ile IsTransient özelliğinin bir birleşimini kullanabilir. Örneğin, bir QuotaExceededException algılayabilir ve ileti göndermeyi yeniden denemeden önce kuyruğu boşaltacak bir işlem yapabilirsiniz.

Aşağıdaki kod, kitaplığını kullanarak bir Service Bus istemcisinde yeniden deneme ilkesi Microsoft.Azure.ServiceBus ayarlar:

const string QueueName = "queue1";
const string ServiceBusConnectionString = "<your_connection_string>";

var policy = new RetryExponential(
    minimumBackoff: TimeSpan.FromSeconds(10),
    maximumBackoff: TimeSpan.FromSeconds(30),
    maximumRetryCount: 3);
var queueClient = new QueueClient(ServiceBusConnectionString, QueueName, ReceiveMode.PeekLock, policy);

Yeniden deneme ilkesi tek işlem düzeyinde ayarlanamaz. İstemci için tüm işlemler için geçerlidir.

Yeniden deneme kullanım kılavuzu

Service Bus kullanırken aşağıdaki yönergeleri göz önünde bulundurun:

• İlke, Sunucu Meşgul özel durumlarına yanıt verip uygun bir yeniden deneme moduna otomatik olarak geçtiğinden, yerleşik RetryExponential uygulamasını kullanırken bir geri alma işlemi uygulamayın.
• Service Bus, birincil ad alanı içinde kuyruk başarısız olursa ayrı bir ad alanı içinde yedekleme kuyruğuna otomatik yük devretme uygulayan Eşleştirilmiş Ad Alanları adlı bir özelliği destekler. İkincil kuyruktan alınan iletiler, kurtarıldığında birincil kuyruğa geri gönderilebilir. Bu özellik, geçici hataları gidermeye yardımcı olur. Daha fazla bilgi için bkz. Zaman Uyumsuz Mesajlaşma Düzenleri ve Yüksek Kullanılabilirlik.

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 izlemeli ve değerleri kendi senaryonıza uyacak şekilde ayarlamanız gerekir.

* Sunucu Meşgul yanıtı alınarak eklenen ek gecikmeler dahil değildir.

Telemetri

Service Bus, yeniden denemeleri bir EventSource kullanarak ETW olayı olarak kaydeder. Olayları yakalamak ve Performans Görüntüleyici’de görüntülemek ya da uygun bir hedef günlüğüne yazmak için olay kaynağına bir EventListener iliştirmeniz gerekir. Yeniden deneme olayları aşağıdaki biçimdedir:

Microsoft-ServiceBus-Client/RetryPolicyIteration
ThreadID="14,500"
FormattedMessage="[TrackingId:] RetryExponential: Operation Get:https://retry-tests.servicebus.windows.net/TestQueue/?api-version=2014-05 at iteration 0 is retrying after 00:00:00.1000000 sleep because of Microsoft.ServiceBus.Messaging.MessagingCommunicationException: The remote name could not be resolved: 'retry-tests.servicebus.windows.net'.TrackingId:6a26f99c-dc6d-422e-8565-f89fdd0d4fe3, TimeStamp:9/5/2014 10:00:13 PM."
trackingId=""
policyType="RetryExponential"
operation="Get:https://retry-tests.servicebus.windows.net/TestQueue/?api-version=2014-05"
iteration="0"
iterationSleep="00:00:00.1000000"
lastExceptionType="Microsoft.ServiceBus.Messaging.MessagingCommunicationException"
exceptionMessage="The remote name could not be resolved: 'retry-tests.servicebus.windows.net'.TrackingId:6a26f99c-dc6d-422e-8565-f89fdd0d4fe3,TimeStamp:9/5/2014 10:00:13 PM"

Örnekler

Aşağıdaki kod örneği, şunun için yeniden deneme ilkesinin nasıl ayarlanacağını gösterir:

• Bir ad alanı yöneticisi. İlke bu yönetici üzerindeki tüm işlemler için geçerlidir ve tek işlemler için geçersiz kılınamaz.
• Bir mesajlaşma fabrikası. İlke bu fabrikadan oluşturulan tüm istemciler için geçerlidir ve tek istemci oluşturulurken geçersiz kılınamaz.
• Tek bir mesajlaşma istemcisi. Bir istemci oluşturulduktan sonra o istemci için yeniden deneme ilkesi ayarlayabilirsiniz. İlke, o istemci üzerindeki tüm işlemler için geçerli olur.

using System;
using System.Threading.Tasks;
using Microsoft.ServiceBus;
using Microsoft.ServiceBus.Messaging;

namespace RetryCodeSamples
{
    class ServiceBusCodeSamples
    {
        private const string connectionString =
            @"Endpoint=sb://[my-namespace].servicebus.windows.net/;
                SharedAccessKeyName=RootManageSharedAccessKey;
                SharedAccessKey=C99..........Mk=";

        public async static Task Samples()
        {
            const string QueueName = "TestQueue";

            ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Http;

            var namespaceManager = NamespaceManager.CreateFromConnectionString(connectionString);

            // The namespace manager will have a default exponential policy with 10 retry attempts
            // and a 3 second delay delta.
            // Retry delays will be approximately 0 sec, 3 sec, 9 sec, 25 sec and the fixed 30 sec,
            // with an extra 10 sec added when receiving a ServiceBusyException.

            {
                // Set different values for the retry policy, used for all operations on the namespace manager.
                namespaceManager.Settings.RetryPolicy =
                    new RetryExponential(
                        minBackoff: TimeSpan.FromSeconds(0),
                        maxBackoff: TimeSpan.FromSeconds(30),
                        maxRetryCount: 3);

                // Policies cannot be specified on a per-operation basis.
                if (!await namespaceManager.QueueExistsAsync(QueueName))
                {
                    await namespaceManager.CreateQueueAsync(QueueName);
                }
            }

            var messagingFactory = MessagingFactory.Create(
                namespaceManager.Address, namespaceManager.Settings.TokenProvider);
            // The messaging factory will have a default exponential policy with 10 retry attempts
            // and a 3 second delay delta.
            // Retry delays will be approximately 0 sec, 3 sec, 9 sec, 25 sec and the fixed 30 sec,
            // with an extra 10 sec added when receiving a ServiceBusyException.

            {
                // Set different values for the retry policy, used for clients created from it.
                messagingFactory.RetryPolicy =
                    new RetryExponential(
                        minBackoff: TimeSpan.FromSeconds(1),
                        maxBackoff: TimeSpan.FromSeconds(30),
                        maxRetryCount: 3);

                // Policies cannot be specified on a per-operation basis.
                var session = await messagingFactory.AcceptMessageSessionAsync();
            }

            {
                var client = messagingFactory.CreateQueueClient(QueueName);
                // The client inherits the policy from the factory that created it.

                // Set different values for the retry policy on the client.
                client.RetryPolicy =
                    new RetryExponential(
                        minBackoff: TimeSpan.FromSeconds(0.1),
                        maxBackoff: TimeSpan.FromSeconds(30),
                        maxRetryCount: 3);

                // Policies cannot be specified on a per-operation basis.
                var session = await client.AcceptMessageSessionAsync();
            }
        }
    }
}

Daha fazla bilgi

• Zaman Uyumsuz Mesajlaşma Desenleri ve Yüksek Kullanılabilirlik

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 örnek gösterilmektedir. Çoğu durumda bu gerekli olmaz ve varsayılan ayarlar yeterli olur.

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));

Daha fazla bilgi

• Uzaktan özel durum işleme

SQL Veritabanı kullanarak ADO.NET

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

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. 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. Bu durum söz konusu olmadığında yeniden deneme işlemi, bir işlemin başarısız olması halinde tüm ilgili değişikliklerin geri alınmasına izin veren bir düzey ya da kapsamda (örn. işlem kapsamında) gerçekleştirilmelidir. Daha fazla bilgi için bkz. Bulut Hizmeti Temelleri Veri Erişim Katmanı – Geçici Hata İşleme.
• Çok kısa aralıklarda yalnızca birkaç yeniden denemenin yapıldığı etkileşimli senaryolar dışında Azure SQL Veritabanı ile sabit aralık stratejisinin kullanılması önerilmez. Bunun yerine, senaryoların büyük bölümü için bir üstel geri alma stratejisi kullanmayı düşünün.
• 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.
• Üstek geri alma yeniden deneme mantığı kullanırken bile, belirli bir sayıda yeniden deneme sonrasında bağlantıyı kapatın ve işlemi yeni bir bağlantı üzerinde 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ımdayken (varsayılan), bağlantı kapatılıp yeniden açıldıktan sonra bile havuzdan aynı bağlantının seçilme olasılığı vardır. Bu durum söz konusuysa, SqlConnection sınıfının ClearPool yöntemini çağırarak bağlantıyı yeniden kullanılamaz olarak işaretlemek bir çözüm tekniğidir. 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 izlemeli ve değerleri kendi senaryonıza uyacak şekilde ayarlamanız gerekir.

Ö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
}

Daha fazla bilgi

• Bulut Hizmeti Temelleri Veri Erişim Katmanı – Geçici Hata İşleme

SQL Veritabanı en iyi şekilde elde etme hakkında genel yönergeler için bkz. Azure SQL Veritabanı performans ve esneklik kılavuzu.

Entity Framework 6 kullanarak SQL Veritabanı

SQL Veritabanı çeşitli boyutlarda ve hem standart (paylaşılan) hem de premium (paylaşılmayan) bir hizmet olarak mevcut olan, barındırılan bir SQL veritabanıdır. 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ı

bağlantı dayanıklılığı/yeniden deneme mantığıadlı bir mekanizma aracılığıyla Entity Framework 6,0 ve üzeri kullanılarak SQL Veritabanı erişirken 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 yürütme 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 denenmeyen, ancak özel durumları inceler ve SQL Veritabanı stratejisini kullanma önerisiyle kaydırılır.
  • SQL Veritabanı için varsayılan değer: üstel (taban sınıftan devralınır) ve SQL Veritabanı algılama mantığı.
• Rastgele seçim içeren bir üstel geri alma stratejisi uygular.
• Yerleşik yeniden deneme sınıflarının durum bilgisi vardır 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 durumu aniden ortaya çıkarmaz.

İ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, işlem başına temelinde 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 ve sonraki sürümler).

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 gerekli olduğunda bu yol 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 ve sonraki sürümler).

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

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 sabit bir aralık stratejisinin kullanılması ö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. Bağlamı kaydederken kaç tane komutun yürütüleceğini kolayca belirleyemeseniz de, zaman aşımının değeri uçtan uca gecikmenin bir bileşenidir. 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 (sabit bir değerdir 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ı olduğundan işlemleri izlemeniz ve değerleri kendi senaryonuza uyacak şekilde ayarlamanız gerekir.

Ö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 yönelik daha fazla örnek, bağlantı dayanıklılığı/yeniden deneme mantığıiçinde bulunabilir.

Daha fazla bilgi

• Azure SQL Veritabanı performans ve esneklik kılavuzu

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 kullanarak SQL Veritabanı erişirken 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. SQL Azure dahil olmak üzere SQL Server için yürütme stratejisi, yeniden denenebilecek özel durum türlerinin bilincindedir ve en fazla yeniden deneme sayısı, yeniden denemeler arasındaki gecikme vb. duyarlı 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 Storage

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

Blob 'lar, kuyruklar ve dosyalar

ClientOptions sınıfı tüm istemci seçenek türlerinin temel türüdür ve tanılama, yeniden deneme, taşıma gibi çeşitli ortak istemci seçeneklerini gösterir. Azure kuyruğu, Blob ve dosya Depolama bağlanmak için istemci yapılandırma seçeneklerini sağlamak üzere, karşılık gelen türetilmiş türü kullanmanız gerekir. Bir sonraki örnekte, bir istemciyi Azure Queue Service 'e bağlanacak şekilde yapılandırmak için QueueClientOptions sınıfını (ClientOptions öğesinden türetilir) kullanırsınız. Retry özelliği, yeniden deneme girişimlerinin nasıl yapıldığını ve bir hatanın yeniden denenmeye uygun olduğunu etkilemek için belirtilebilecek 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

Yeniden deneme mekanizması

Yeniden denemeler tek REST işlem düzeyinde gerçekleşir ve istemci API uygulamasının ayrılmaz bir parçasıdır. İstemci depolama SDK'sı, IExtendedRetryPolicy Arabirimi uygulayan sınıflar kullanır.

Yerleşik sınıflar, rastgele yeniden deneme aralığı seçimi ile doğrusal (sabit gecikme) ve üstel desteği sağlar. Ayrıca, yeniden denemeler daha yüksek bir düzeyde başka bir işlem tarafından uygulanırken kullanılacak bir yeniden denememe ilkesi mevcuttur. Ancak, yerleşik sınıfları tarafından sağlanmayan özel gereksinimleriniz varsa kendi yeniden deneme sınıflarınızı uygulayabilirsiniz.

Okuma erişimli coğrafi olarak yedekli depolama (RA-GRS) kullanıyorsanız ve isteğin sonucu yeniden denenebilir bir hata ise alternatif yeniden denemeler birincil ile ikincil depolama hizmeti konumu arasında geçiş yapar. Daha fazla bilgi için bkz. Azure Depolama Yedekliliği Seçenekleri.

İlke yapılandırması

Yeniden deneme ilkeleri programlı olarak yapılandırılır. Bir TableRequestOptions, BlobRequestOptions, FileRequestOptions ya da QueueRequestOptions örneğinin oluşturulup doldurulması tipik bir yordamdır.

TableRequestOptions interactiveRequestOption = new TableRequestOptions()
{
  RetryPolicy = new LinearRetry(TimeSpan.FromMilliseconds(500), 3),
  // For Read-access geo-redundant storage, use PrimaryThenSecondary.
  // Otherwise set this to PrimaryOnly.
  LocationMode = LocationMode.PrimaryThenSecondary,
  // Maximum execution time based on the business use case.
  MaximumExecutionTime = TimeSpan.FromSeconds(2)
};

Bundan sonra istek seçenekleri örneği istemci üzerinde ayarlanabilir ve istemci ile yapılan tüm işlemlerde belirtilen istek seçenekleri kullanılır.

client.DefaultRequestOptions = interactiveRequestOption;
var stats = await client.GetServiceStatsAsync();

İstek seçenekleri sınıfının doldurulmuş bir örneğini işlem yöntemlerine parametre olarak geçirerek, istemci istek seçeneklerini geçersiz kılabilirsiniz.

var stats = await client.GetServiceStatsAsync(interactiveRequestOption, operationContext: null);

Bir yeniden deneme işlemi gerçekleştirildiğinde ve bir işlem tamamlandığında yürütülecek kodu belirtmek için OperationContext örneğini kullanabilirsiniz. Bu kod, günlüklerde ve telemetride kullanıma yönelik işlemler hakkında bilgi toplayabilir.

// Set up notifications for an operation
var context = new OperationContext();
context.ClientRequestID = "some request id";
context.Retrying += (sender, args) =>
{
    // Collect retry information
};
context.RequestCompleted += (sender, args) =>
{
    // Collect operation completion information
};
var stats = await client.GetServiceStatsAsync(null, context);

Genişletilmiş yeniden deneme ilkeleri bir hatanın yeniden deneme için uygun olup olmadığını belirtmesine ek olarak yeniden deneme sayısını, son isteğin sonuçlarını, sonraki yeniden denemenin birincil veya ikincil konumda olacağını belirten bir RetryContext nesnesi döndürür (ayrıntılar için aşağıdaki tabloya bakın). RetryContext nesnesinin özellikleri bir yeniden deneme işleminin denenip denenmeyeceğine ve ne zaman deneneceğine karar vermek için kullanılabilir. Daha fazla bilgi için bkz. ıextendedretrypolicy. değerlendir yöntemi.

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

İstek seçenekleri:

Üstel ilke:

Doğrusal ilke:

Yeniden deneme kullanım kılavuzu

Depolama istemcisi API’sini kullanarak Azure depolama hizmetlerine erişirken aşağıdaki yönergeleri göz önünde bulundurun:

• Microsoft. Azure ' dan yerleşik yeniden deneme ilkelerini kullanın. Depolama. Gereksinimlerinizin uygun olduğu, RetryPolicies ad alanı. Çoğu durumda bu ilkeler yeterli olacaktır.

• ExponentialRetry ilkesini toplu işlemlerde, arka plan görevlerinde veya etkileşimli olmayan senaryolarda kullanın. Bu senaryolarda genellikle hizmetin kurtarılması için daha fazla zaman verebilirsiniz ve işlemin zamanla başarılı olma olasılığı artar.

• Toplam yürütme süresini sınırlamak için RequestOptions parametresinin MaximumExecutionTime özelliğini belirtmeyi düşünün, ancak bir zaman aşımı değeri seçerken işlemin türünü ve boyutunu hesaba katın.

• Özel bir yeniden deneme uygulamanız gerekirse, depolama istemcisi sınıflarının çevresinde sarmalayıcılar oluşturmaktan kaçının. Bunun yerine, IExtendedRetryPolicy arabirimi ile var olan ilkeleri genişletme özelliklerini kullanın.

• Okuma erişimli coğrafi olarak yedekli depolama (RA-GRS) kullanıyorsanız, birincil erişimin başarısız olması durumunda yeniden deneme girişimlerinin ikincil salt okunur depo kopyasına erişeceğini belirtmek için LocationMode seçeneğini kullanın. Ancak, bu seçeneği kullanırken birincil depodan çoğaltmanın henüz tamamlanmaması durumunda uygulamanızın süresi geçmiş olabilecek verilerle başarılı bir şekilde çalışabildiğinden emin olmanız gerekir.

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

Telemetri

Yeniden deneme girişimleri bir TraceSource günlüğüne kaydedilir. Olayları yakalamak ve uygun bir hedef günlüğüne yazmak için bir TraceListener yapılandırmanız gerekir. Verileri bir günlük dosyasına yazmak için TextWriterTraceListener veya XmlWriterTraceListener, Windows Olay Günlüğüne yazmak için EventLogTraceListener ya da izleme verilerini ETW alt sistemine yazmak için EventProviderTraceListener kullanabilirsiniz. Ayrıca, arabelleğin ve günlüğe kaydedilecek olayların ayrıntı düzeyini (örneğin, hata, uyarı, bilgilendirici ve ayrıntılı) yapılandırabilirsiniz. Daha fazla bilgi için bkz. .NET Depolama İstemci Kitaplığı ile İstemci Tarafı Günlük Kaydı.

İşlemler, özel telemetri mantığı eklemek için kullanılabilen bir Retrying olayını kullanıma sunan OperationContext örneğini alabilir. Daha fazla bilgi için bkz. OperationContext.Retrying Olayı.

Örnekler

Aşağıdaki kod örneğinde iki farklı yeniden deneme ayarı ile biri etkileşimli istekler ve diğeri arka plan istekleri için olmak üzere iki TableRequestOptions örneği oluşturma işlemi gösterilmektedir. Örnek daha sonra tüm isteklerde geçerli olması için bu iki yeniden deneme ilkesini istemci üzerinde ayarlar ve ayrıca istemciye uygulanan varsayılan ayarları geçersiz kılmak için belirli bir istekte etkileşimli stratejiyi ayarlar.

using System;
using System.Threading.Tasks;
using Microsoft.Azure.Cosmos.Table;

namespace RetryCodeSamples
{
    class AzureStorageCodeSamples
    {
        private const string connectionString = "UseDevelopmentStorage=true";

        public async static Task Samples()
        {
            var storageAccount = CloudStorageAccount.Parse(connectionString);

            TableRequestOptions interactiveRequestOption = new TableRequestOptions()
            {
                RetryPolicy = new LinearRetry(TimeSpan.FromMilliseconds(500), 3),
                // For Read-access geo-redundant storage, use PrimaryThenSecondary.
                // Otherwise set this to PrimaryOnly.
                LocationMode = LocationMode.PrimaryThenSecondary,
                // Maximum execution time based on the business use case.
                MaximumExecutionTime = TimeSpan.FromSeconds(2)
            };

            TableRequestOptions backgroundRequestOption = new TableRequestOptions()
            {
                // Client has a default exponential retry policy with 4 sec delay and 3 retry attempts
                // Retry delays will be approximately 3 sec, 7 sec, and 15 sec
                MaximumExecutionTime = TimeSpan.FromSeconds(30),
                // PrimaryThenSecondary in case of Read-access geo-redundant storage, else set this to PrimaryOnly
                LocationMode = LocationMode.PrimaryThenSecondary
            };

            var client = storageAccount.CreateCloudTableClient();
            // Client has a default exponential retry policy with 4 sec delay and 3 retry attempts
            // Retry delays will be approximately 3 sec, 7 sec, and 15 sec
            // ServerTimeout and MaximumExecutionTime are not set

            {
                // Set properties for the client (used on all requests unless overridden)
                // Different exponential policy parameters for background scenarios
                client.DefaultRequestOptions = backgroundRequestOption;
                // Linear policy for interactive scenarios
                client.DefaultRequestOptions = interactiveRequestOption;
            }

            {
                // set properties for a specific request
                var stats = await client.GetServiceStatsAsync(interactiveRequestOption, operationContext: null);
            }

            {
                // Set up notifications for an operation
                var context = new OperationContext();
                context.ClientRequestID = "some request id";
                context.Retrying += (sender, args) =>
                {
                    // Collect retry information
                };
                context.RequestCompleted += (sender, args) =>
                {
                    // Collect operation completion information
                };
                var stats = await client.GetServiceStatsAsync(null, context);
            }
        }
    }
}

Daha fazla bilgi

• Azure Depolama İstemci Kitaplığı yeniden deneme ilkesi önerileri

• Depolama kitaplığı 2.0 – Yeniden deneme ilkelerini uygulama

Genel REST ve yeniden deneme yönergeleri

Azure veya üçüncü taraf hizmetlere erişirken aşağıdakilere dikkat edin:

• 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 bulundurabilirsiniz. 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 istediğiniz hizmetler için özel yeniden deneme kodu oluşturmanız gerekir.

• 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 kodu ile 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 kapatma yaklaşımı kullanarak belirtilen sayıda yeniden deneme gerçekleştiren yeniden deneme ilkesi. Örnek:

  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ındaki artımlı zaman aralığına sahip bir yeniden deneme stratejisi. Örnek:

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

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

  retryInterval = this.deltaBackoff;
  

Polly ile geçici hata işleme

Polly, yeniden denemeleri ve devre kesici stratejilerini program aracılığıyla işlemek için 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 olabilen özel yeniden deneme kodu yazma gereksinimini ortadan kaldırır. Polly ayrıca yeniden denemeleri günlüğe kaydetmeniz için oluşan hataları izlemenin bir yolunu sağlar.

Daha fazla bilgi

• bağlantının daha iyi bir şekilde
• Veri Noktaları - EF Core 1.1