Belirli hizmetlere yönelik yeniden deneme kılavuzuRetry guidance for specific services

Çoğu Azure hizmeti ve istemci SDK'sı bir yeniden deneme mekanizması içerir.Most Azure services and client SDKs include a retry mechanism. 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.However, these differ because each service has different characteristics and requirements, and so each retry mechanism is tuned to a specific service. 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.This guide summarizes the retry mechanism features for the majority of Azure services, and includes information to help you use, adapt, or extend the retry mechanism for that service.

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.For general guidance on handling transient faults, and retrying connections and operations against services and resources, see Retry guidance.

Aşağıdaki tabloda, bu kılavuzda açıklanan Azure hizmetlerinin yeniden deneme özellikleri özetlenmektedir.The following table summarizes the retry features for the Azure services described in this guidance.

HizmetService Yeniden deneme özellikleriRetry capabilities İlke yapılandırmasıPolicy configuration KapsamScope Telemetri özellikleriTelemetry features
Azure Active DirectoryAzure Active Directory ADAL kitaplığında yerelNative in ADAL library ADAL kitaplığına eklenmişEmbeded into ADAL library İçInternal NoneNone
Cosmos DBCosmos DB Hizmette yerelNative in service YapılandırılamazNon-configurable GenelGlobal TraceSourceTraceSource
Data Lake StoreData Lake Store İstemcide yerelNative in client YapılandırılamazNon-configurable Tek işlemlerIndividual operations NoneNone
Event HubsEvent Hubs İstemcide yerelNative in client ProgramlıProgrammatic İstemciClient NoneNone
IOT hub'ıIoT Hub Yerel İstemci SDK'sıNative in client SDK ProgramlıProgrammatic İstemciClient NoneNone
Redis CacheRedis Cache İstemcide yerelNative in client ProgramlıProgrammatic İstemciClient TextWriterTextWriter
AramaSearch İstemcide yerelNative in client ProgramlıProgrammatic İstemciClient ETW veya ÖzelETW or Custom
Service BusService Bus İstemcide yerelNative in client ProgramlıProgrammatic Namespace Manager, Messaging Factory ve ClientNamespace Manager, Messaging Factory, and Client ETWETW
Service FabricService Fabric İstemcide yerelNative in client ProgramlıProgrammatic İstemciClient NoneNone
ADO.NET ile SQL VeritabanıSQL Database with ADO.NET PollyPolly Bildirim temelli ve programlıDeclarative and programmatic Tek deyimler veya kod bloklarıSingle statements or blocks of code ÖzelCustom
Entity Framework ile SQL VeritabanıSQL Database with Entity Framework İstemcide yerelNative in client ProgramlıProgrammatic Uygulama Etki Alanı başına genelGlobal per AppDomain NoneNone
Entity Framework Core ile SQL VeritabanıSQL Database with Entity Framework Core İstemcide yerelNative in client ProgramlıProgrammatic Uygulama Etki Alanı başına genelGlobal per AppDomain NoneNone
DepolamaStorage İstemcide yerelNative in client ProgramlıProgrammatic İstemci ve tek işlemlerClient and individual operations TraceSourceTraceSource

Not

Birçok yerleşik Azure yeniden deneme mekanizmalarının için var. şu anda hiçbir şekilde uygulamadığınız bir hata veya özel durum farklı türleri için farklı yeniden deneme ilkesi.For most of the Azure built-in retry mechanisms, there is currently no way apply a different retry policy for different types of error or exception. En iyi ortalama performans ve kullanılabilirlik sağlayan bir ilke yapılandırmanız gerekir.You should configure a policy that provides the optimum average performance and availability. İ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.One way to fine-tune the policy is to analyze log files to determine the type of transient faults that are occurring.

Azure Active DirectoryAzure 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.Azure Active Directory (Azure AD) is a comprehensive identity and access management cloud solution that combines core directory services, advanced identity governance, security, and application access management. Ayrıca, Azure AD geliştiricilerin uygulamalarına olan erişimi denetleyebileceği, merkezi ilke ve kurallara dayanan bir kimlik yönetim platformu sunar.Azure AD also offers developers an identity management platform to deliver access control to their applications, based on centralized policy and rules.

Not

Yönetilen hizmet kimliği uç üzerinde yeniden deneme yönergeleri için bkz belirtecinin alınması için bir Azure VM yönetilen hizmet kimliği (MSI) kullanma.For retry guidance on Managed Service Identity endpoints, see How to use an Azure VM Managed Service Identity (MSI) for token acquisition.

Yeniden deneme mekanizmasıRetry mechanism

Azure Active Directory için Active Directory Kimlik Doğrulama Kitaplığı (ADAL) içinde yerleşik bir yeniden deneme mekanizması vardır.There is a built-in retry mechanism for Azure Active Directory in the Active Directory Authentication Library (ADAL). Beklenmeyen kilitlenmeleri önlemek için üçüncü taraf kitaplıkların ve uygulama kodunun başarısız bağlantıları yeniden denememesi ve yeniden denemelerin ADAL tarafından gerçekleştirilmesine izin verilmesi önerilir.To avoid unexpected lockouts, we recommend that third party libraries and application code do not retry failed connections, but allow ADAL to handle retries.

Yeniden deneme kullanım kılavuzuRetry usage guidance

Azure Active Directory kullanırken aşağıdaki yönergeleri göz önünde bulundurun:Consider the following guidelines when using Azure Active Directory:

  • Mümkün olduğunda, yeniden denemeler için ADAL kitaplığını ve yerleşik desteği kullanın.When possible, use the ADAL library and the built-in support for retries.
  • 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.If you are using the REST API for Azure Active Directory, retry the operation if the result code is 429 (Too Many Requests) or an error in the 5xx range. Diğer hatalar için yeniden denemeyin.Do not retry for any other errors.
  • Azure Active Directory ile toplu iş senaryolarında bir üstel geri alma ilkesinin kullanılması önerilir.An exponential back-off policy is recommended for use in batch scenarios with Azure Active Directory.

Yeniden deneme işlemleri için aşağıdaki ayarlarla başlamayı düşünün.Consider starting with the following settings for retrying operations. Bunlar genel amaçlı ayarlardır ve kendi senaryonuza uygun olması için işlemleri izlemeniz ve değerlere ince ayar yapmanız gerekir.These are general purpose settings, and you should monitor the operations and fine tune the values to suit your own scenario.

BağlamContext Örnek hedef E2E
en uzun gecikme süresi
Sample target E2E
max latency
Yeniden deneme stratejisiRetry strategy AyarlarSettings DeğerlerValues Nasıl çalışır?How it works
Etkileşimli, UI,Interactive, UI,
veya ön planor foreground
2 sn2 sec FixedIntervalFixedInterval Yeniden deneme sayısıRetry count
Yeniden deneme aralığıRetry interval
İlk hızlı yeniden denemeFirst fast retry
33
500 ms500 ms
truetrue
Deneme 1 - 0 sn gecikmeAttempt 1 - delay 0 sec
Deneme 2 - 500 ms gecikmeAttempt 2 - delay 500 ms
Deneme 3 - 500 ms gecikmeAttempt 3 - delay 500 ms
Arka plan veyaBackground or
toplu işbatch
60 sn60 sec ExponentialBackoffExponentialBackoff Yeniden deneme sayısıRetry count
En düşük geri almaMin back-off
En yüksek geri almaMax back-off
Delta geri almaDelta back-off
İlk hızlı yeniden denemeFirst fast retry
55
0 sn0 sec
60 sn60 sec
2 sn2 sec
falsefalse
Deneme 1 - 0 sn gecikmeAttempt 1 - delay 0 sec
Deneme 2 - yaklaşık 2 sn gecikmeAttempt 2 - delay ~2 sec
Deneme 3 - yaklaşık 6 sn gecikmeAttempt 3 - delay ~6 sec
Deneme 4 - yaklaşık 14 sn gecikmeAttempt 4 - delay ~14 sec
Deneme 5 - yaklaşık 30 sn gecikmeAttempt 5 - delay ~30 sec

Daha fazla bilgiMore information

Cosmos DBCosmos DB

Cosmos DB, şemasız JSON verilerini destekleyen tam yönetilen, çok modelli bir veritabanıdır.Cosmos DB is a fully-managed multi-model database that supports schema-less JSON data. 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.It offers configurable and reliable performance, native JavaScript transactional processing, and is built for the cloud with elastic scale.

Yeniden deneme mekanizmasıRetry mechanism

DocumentClient sınıfı başarısız girişimleri otomatik olarak yeniden dener.The DocumentClient class automatically retries failed attempts. Yeniden deneme sayısını ve en uzun bekleme süresini ayarlamak için ConnectionPolicy.RetryOptions özelliğini yapılandırın.To set the number of retries and the maximum wait time, configure ConnectionPolicy.RetryOptions. İstemcinin oluşturduğu özel durumlar, yeniden deneme ilkesi dışındadır veya geçici hatalar değildir.Exceptions that the client raises are either beyond the retry policy or are not transient errors.

Cosmos DB istemciyi kısıtlarsa HTTP 429 hatasını döndürür.If Cosmos DB throttles the client, it returns an HTTP 429 error. DocumentClientException içindeki durum kodunu denetleyin.Check the status code in the DocumentClientException.

İlke yapılandırmasıPolicy configuration

Aşağıdaki tabloda RetryOptions sınıfına ilişkin varsayılan ayarlar gösterilmektedir.The following table shows the default settings for the RetryOptions class.

AyarSetting Varsayılan değerDefault value AçıklamaDescription
MaxRetryAttemptsOnThrottledRequestsMaxRetryAttemptsOnThrottledRequests 99 Cosmos DB istemci üzerinde hız sınırlaması uyguladığı için istek başarısız olursa en fazla yeniden deneme sayısı.The maximum number of retries if the request fails because Cosmos DB applied rate limiting on the client.
MaxRetryWaitTimeInSecondsMaxRetryWaitTimeInSeconds 3030 Saniye cinsinden en fazla yeniden deneme süresi.The maximum retry time in seconds.

ÖrnekExample

DocumentClient client = new DocumentClient(new Uri(endpoint), authKey); ;
var options = client.ConnectionPolicy.RetryOptions;
options.MaxRetryAttemptsOnThrottledRequests = 5;
options.MaxRetryWaitTimeInSeconds = 15;

TelemetriTelemetry

Yeniden deneme girişimleri bir .NET TraceSource aracılığıyla yapılandırılmamış izleme iletileri halinde günlüğe kaydedilir.Retry attempts are logged as unstructured trace messages through a .NET TraceSource. Olayları yakalamak ve uygun bir hedef günlüğüne yazmak için bir TraceListener yapılandırmanız gerekir.You must configure a TraceListener to capture the events and write them to a suitable destination log.

Ö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:For example, if you add the following to your App.config file, traces will be generated in a text file in the same location as the executable:

<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 HubsEvent Hubs

Azure Event Hubs, milyonlarca olayı toplayan, dönüştüren ve depolayan hiper ölçekli bir telemetri alma hizmetidir.Azure Event Hubs is a hyper-scale telemetry ingestion service that collects, transforms, and stores millions of events.

Yeniden deneme mekanizmasıRetry mechanism

Azure Event Hubs İstemci Kitaplığındaki yeniden deneme davranışı, EventHubClient sınıfındaki RetryPolicy özelliği tarafından denetlenir.Retry behavior in the Azure Event Hubs Client Library is controlled by the RetryPolicy property on the EventHubClient class. Varsayılan ilke, Azure Event Hub geçici EventHubsException veya OperationCanceledException hatası döndürdüğünde üstel geri alma ile yeniden dener.The default policy retries with exponential backoff when Azure Event Hub returns a transient EventHubsException or an OperationCanceledException.

ÖrnekExample

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

Daha fazla bilgiMore information

Azure Event Hubs için .NET standard istemci kitaplığı.NET Standard client library for Azure Event Hubs

IoT HubIoT Hub

Azure IOT hub'a bağlanma, izleme ve nesnelerin interneti (IOT) uygulamaları geliştirmek için cihazları yönetmek için bir hizmettir.Azure IoT Hub is a service for connecting, monitoring, and managing devices to develop Internet of Things (IoT) applications.

Yeniden deneme mekanizmasıRetry mechanism

Azure IOT cihaz SDK'sı, ağ, protokolü veya uygulama hatalarını algılayabilir.The Azure IoT device SDK can detect errors in the network, protocol, or application. Hata türüne göre SDK'sı bir yeniden deneme gerçekleştirilmesi gerekip gerekmediğini denetler.Based on the error type, the SDK checks whether a retry needs to be performed. Hata kurtarılabilir, SDK'sı yapılandırılan yeniden deneme İlkesi kullanarak yeniden başlar.If the error is recoverable, the SDK begins to retry using the configured retry policy.

Varsayılan yeniden deneme ilkesi üstel geri alma rastgele değişimi ile, ancak yapılandırılabilir.The default retry policy is exponential back-off with random jitter, but it can be configured.

İlke yapılandırmasıPolicy configuration

İlke Yapılandırması, dile göre farklılık gösterir.Policy configuration differs by language. Daha fazla ayrıntı için IOT hub'ı yeniden deneme ilkesi yapılandırması.For more details, see IoT Hub retry policy configuration.

Daha fazla bilgiMore information

Azure Redis CacheAzure Redis Cache

Azure Redis Cache, popüler açık kaynak Redis Önbelleğini temel alan hızlı veri erişimi ve düşük gecikmeli önbelleğe alma hizmetidir.Azure Redis Cache is a fast data access and low latency cache service based on the popular open source Redis Cache. Güvenlidir, Microsoft tarafından yönetilir ve Azure'daki herhangi bir uygulamadan erişilebilir.It is secure, managed by Microsoft, and is accessible from any application in Azure.

Bu bölümdeki yönergeler, önbelleğe erişmek için StackExchange.Redis istemcisini kullanmayı temel alır.The guidance in this section is based on using the StackExchange.Redis client to access the cache. Diğer uygun istemcilerin listesi Redis web sitesinde bulunabilir ve bu istemciler farklı yeniden deneme mekanizmalarına sahip olabilir.A list of other suitable clients can be found on the Redis website, and these may have different retry mechanisms.

StackExchange.Redis istemcisinin tek bir bağlantı üzerinden çoğullama kullandığını unutmayın.Note that the StackExchange.Redis client uses multiplexing through a single connection. Ö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.The recommended usage is to create an instance of the client at application startup and use this instance for all operations against the cache. 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.For this reason, the connection to the cache is made only once, and so all of the guidance in this section is related to the retry policy for this initial connection—and not for each operation that accesses the cache.

Yeniden deneme mekanizmasıRetry mechanism

StackExchange.Redis istemcisi seçenekleri dahil olmak üzere, bir dizi aracılığıyla yapılandırılan bir bağlantı Yöneticisi sınıfı kullanır:The StackExchange.Redis client uses a connection manager class that is configured through a set of options, including:

  • ConnectRetry.ConnectRetry. Önbellekle başarısız bir bağlantıyı yeniden deneme sayısı.The number of times a failed connection to the cache will be retried.
  • ReconnectRetryPolicy.ReconnectRetryPolicy. Kullanılacak yeniden deneme stratejisi.The retry strategy to use.
  • ConnectTimeout.ConnectTimeout. Milisaniye cinsinden en fazla bekleme süresi.The maximum waiting time in milliseconds.

İlke yapılandırmasıPolicy configuration

Yeniden deneme ilkeleri, önbellekle bağlantı kurulmadan önce istemci seçenekleri ayarlanarak program aracılığıyla yapılandırılır.Retry policies are configured programmatically by setting the options for the client before connecting to the cache. Bu işlem ConfigurationOptions sınıfının bir örneği oluşturularak, özellikleri doldurularak ve Connect yöntemine geçirilerek yapılabilir.This can be done by creating an instance of the ConfigurationOptions class, populating its properties, and passing it to the Connect method.

Yerleşik sınıflar, rastgele yeniden deneme aralıkları seçimi ile doğrusal (sabit gecikme) ve üstel geri almayı destekler.The built-in classes support linear (constant) delay and exponential backoff with randomized retry intervals. Ayrıca IReconnectRetryPolicy arabirimini uygulayarak özel bir yeniden deneme ilkesi oluşturabilirsiniz.You can also create a custom retry policy by implementing the IReconnectRetryPolicy interface.

Aşağıdaki örnek, üstel geri almayı kullanarak bir yeniden deneme stratejisini yapılandırır.The following example configures a retry strategy using exponential backoff.

var deltaBackOffInMilliseconds = TimeSpan.FromSeconds(5).Milliseconds;
var maxDeltaBackOffInMilliseconds = TimeSpan.FromSeconds(20).Milliseconds;
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.Alternatively, you can specify the options as a string, and pass this to the Connect method. ReconnectRetryPolicy özelliğinin bu şekilde ayarlanamadığını, yalnızca kod aracılığıyla ayarlanabildiğini unutmayın.Note that the ReconnectRetryPolicy property cannot be set this way, only through code.

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.You can also specify options directly when you connect to the cache.

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.For more information, see Stack Exchange Redis Configuration in the StackExchange.Redis documentation.

Aşağıdaki tabloda yerleşik yeniden deneme ilkelerine ilişkin varsayılan ayarlar gösterilmektedir.The following table shows the default settings for the built-in retry policy.

BağlamContext AyarSetting Varsayılan değerDefault value
(v 1.2.2)(v 1.2.2)
AnlamıMeaning
ConfigurationOptionsConfigurationOptions ConnectRetryConnectRetry

ConnectTimeoutConnectTimeout

SyncTimeoutSyncTimeout

ReconnectRetryPolicyReconnectRetryPolicy
33

En fazla 5000 ms ve SyncTimeoutMaximum 5000 ms plus SyncTimeout
10001000

LinearRetry 5000 msLinearRetry 5000 ms
İlk bağlantı işlemi sırasında bağlantı girişimlerini yineleme sayısı.The number of times to repeat connect attempts during the initial connection operation.
Bağlantı işlemleri için zaman aşımı (ms).Timeout (ms) for connect operations. Yeniden deneme girişimleri gecikme yoktur.Not a delay between retry attempts.
Zaman uyumlu işlemler izin verilecek süre (ms).Time (ms) to allow for synchronous operations.

Her 5000 ms’de yeniden deneyin.Retry every 5000 ms.

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.For synchronous operations, SyncTimeout can add to the end-to-end latency, but setting the value too low can cause excessive timeouts. Bkz. Azure Redis Cache sorunlarını giderme.See How to troubleshoot Azure Redis Cache. Genel olarak, zaman uyumlu işlemler kullanmaktan kaçının ve onun yerine zaman uyumsuz işlemler kullanın.In general, avoid using synchronous operations, and use asynchronous operations instead. Daha fazla bilgi için bkz. İşlem Hatları ve Çoğullayıcılar.For more information see Pipelines and Multiplexers.

Yeniden deneme kullanım kılavuzuRetry usage guidance

Azure Redis Cache kullanırken aşağıdaki yönergeleri göz önünde bulundurun:Consider the following guidelines when using Azure Redis 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.The StackExchange Redis client manages its own retries, but only when establishing a connection to the cache when the application first starts. 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.You can configure the connection timeout, the number of retry attempts, and the time between retries to establish this connection, but the retry policy does not apply to operations against the cache.
  • Çok sayıda yeniden deneme girişimi kullanmak yerine özgün veri kaynağına erişerek geri almayı düşünün.Instead of using a large number of retry attempts, consider falling back by accessing the original data source instead.

TelemetriTelemetry

Bir TextWriter kullanarak bağlantılar hakkında (diğer işlemler hakkında değil) bilgi toplayabilirsiniz.You can collect information about connections (but not other operations) using a TextWriter.

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

Bu işlemin oluşturduğu çıktı aşağıda gösterilmiştir.An example of the output this generates is shown below.

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...
...

ÖrneklerExamples

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.The following code example configures a constant (linear) delay between retries when initializing the StackExchange.Redis client. Bu örnekte bir ConfigurationOptions örneği kullanılarak yapılandırmanın nasıl ayarlanacağı gösterilmektedir.This example shows how to set the configuration using a ConfigurationOptions instance.

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).Milliseconds; // 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.The next example sets the configuration by specifying the options as a string. 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.The connection timeout is the maximum period of time to wait for a connection to the cache, not the delay between retry attempts. ReconnectRetryPolicy özelliğinin yalnızca kod tarafından ayarlanabildiğini unutmayın.Note that the ReconnectRetryPolicy property can only be set by code.

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.For more examples, see Configuration on the project website.

Daha fazla bilgiMore information

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.Azure Search can be used to add powerful and sophisticated search capabilities to a website or application, quickly and easily tune search results, and construct rich and fine-tuned ranking models.

Yeniden deneme mekanizmasıRetry mechanism

Azure Search SDK’sında yeniden deneme davranışı SearchServiceClient ve SearchIndexClient sınıflarında SetRetryPolicy yöntemiyle denetlenir.Retry behavior in the Azure Search SDK is controlled by the SetRetryPolicy method on the SearchServiceClient and SearchIndexClient classes. Azure Search bir 5xx veya 408 (İstek Zaman Aşımı) yanıtı döndürdüğünde üstel geri alma ile yeniden dener.The default policy retries with exponential backoff when Azure Search returns a 5xx or 408 (Request Timeout) response.

TelemetriTelemetry

ETW ile veya bir özel izleme sağlayıcısı kaydederek izleyin.Trace with ETW or by registering a custom trace provider. Daha fazla bilgi için bkz. AutoRest belgeleri.For more information, see the AutoRest documentation.

Service BusService 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.Service Bus is a cloud messaging platform that provides loosely coupled message exchange with improved scale and resiliency for components of an application, whether hosted in the cloud or on-premises.

Yeniden deneme mekanizmasıRetry mechanism

Service Bus, RetryPolicy temel sınıfının uygulamalarını kullanarak yeniden denemeleri gerçekleştirir.Service Bus implements retries using implementations of the RetryPolicy base class. Tüm Service Bus istemcileri RetryPolicy temel sınıfının uygulamalarından birine ayarlanabilen bir RetryPolicy özelliğini kullanıma sunar.All of the Service Bus clients expose a RetryPolicy property that can be set to one of the implementations of the RetryPolicy base class. Yerleşik uygulamalar şunlardır:The built-in implementations are:

  • RetryExponential sınıfı.The RetryExponential class. Bu sınıf, geri alma aralığını, yeniden deneme sayısını ve işlemin tamamlanması için toplam süreyi sınırlamak üzere kullanılan TerminationTimeBuffer özelliğini denetleyen özellikleri kullanıma sunar.This exposes properties that control the back-off interval, the retry count, and the TerminationTimeBuffer property that is used to limit the total time for the operation to complete.

  • NoRetry sınıfı.The NoRetry class. Bu sınıf, yeniden denemeler bir toplu işin veya çok adımlı bir işlemin parçası olarak başka bir işlem tarafından yönetildiğinde olduğu gibi, Service Bus API düzeyinde yeniden denemeler gerekli olmadığında kullanılır.This is used when retries at the Service Bus API level are not required, such as when retries are managed by another process as part of a batch or multiple step operation.

Service Bus eylemleri, bir dizi özel durumu döndürebilir, listelenen Service Bus Mesajlaşma özel durumları.Service Bus actions can return a range of exceptions, as listed in Service Bus messaging exceptions. Bu liste, işlemi yeniden denemenin uygun olup olmadığı hakkında bilgiler sağlar.The list provides information about which if these indicate that retrying the operation is appropriate. Örneğin, bir ServerBusyException özel durumu istemcinin bir süre beklemesi ve sonra işlemi yeniden denemesi gerektiğini gösterir.For example, a ServerBusyException indicates that the client should wait for a period of time, then retry the operation. ServerBusyException özel durumunun oluşması ayrıca Service Bus’ın, hesaplanan yeniden deneme gecikmelerine 10 saniyelik bir gecikmenin eklendiği farklı bir moda geçmesine neden olur.The occurrence of a ServerBusyException also causes Service Bus to switch to a different mode, in which an extra 10-second delay is added to the computed retry delays. Bu mod, kısa bir süre sonra sıfırlanır.This mode is reset after a short period.

Service Bus’tan döndürülen özel durumlar, istemcinin işlemi yeniden denemesinin gerekli olup olmadığını belirten IsTransient özelliğini kullanıma sunar.The exceptions returned from Service Bus expose the IsTransient property that indicates if the client should retry the operation. Yerleşik RetryExponential ilkesi, tüm Service Bus özel durumları için temel sınıf olan MessagingException sınıfında IsTransient özelliğini kullanır.The built-in RetryExponential policy relies on the IsTransient property in the MessagingException class, which is the base class for all Service Bus exceptions. RetryPolicy temel sınıfının özel uygulamalarını oluşturursanız, yeniden deneme eylemleri üzerinde daha ayrıntılı bir denetim sağlamak için özel durum türü ile IsTransient özelliğinin bir birleşimini kullanabilirsiniz.If you create custom implementations of the RetryPolicy base class you could use a combination of the exception type and the IsTransient property to provide more fine-grained control over retry actions. Örneğin, bir QuotaExceededException algılayabilir ve ileti göndermeyi yeniden denemeden önce kuyruğu boşaltacak bir işlem yapabilirsiniz.For example, you could detect a QuotaExceededException and take action to drain the queue before retrying sending a message to it.

İlke yapılandırmasıPolicy configuration

Yeniden deneme ilkeleri program aracılığıyla ayarlanır ve bir NamespaceManager ile bir MessagingFactory için varsayılan ilke olarak ya da her mesajlaşma istemcisi için tek tek ayarlanabilir.Retry policies are set programmatically, and can be set as a default policy for a NamespaceManager and for a MessagingFactory, or individually for each messaging client. Bir mesajlaşma oturumunun varsayılan yeniden deneme ilkesini ayarlamak için NamespaceManager’ın RetryPolicy özelliğini ayarlayın.To set the default retry policy for a messaging session you set the RetryPolicy of the NamespaceManager.

namespaceManager.Settings.RetryPolicy = new RetryExponential(minBackoff: TimeSpan.FromSeconds(0.1),
                                                                maxBackoff: TimeSpan.FromSeconds(30),
                                                                maxRetryCount: 3);

Bir mesajlaşma fabrikasından oluşturulan tüm istemcilerin varsayılan yeniden deneme ilkesini ayarlamak için MessagingFactory’nin RetryPolicy özelliğini ayarlayın.To set the default retry policy for all clients created from a messaging factory, you set the RetryPolicy of the MessagingFactory.

messagingFactory.RetryPolicy = new RetryExponential(minBackoff: TimeSpan.FromSeconds(0.1),
                                                    maxBackoff: TimeSpan.FromSeconds(30),
                                                    maxRetryCount: 3);

Bir mesajlaşma istemcisinin yeniden deneme ilkesini ayarlamak veya varsayılan ilkesini geçersiz kılmak için, gerekli ilke sınıfının bir örneğini kullanarak RetryPolicy özelliğini ayarlayın:To set the retry policy for a messaging client, or to override its default policy, you set its RetryPolicy property using an instance of the required policy class:

client.RetryPolicy = new RetryExponential(minBackoff: TimeSpan.FromSeconds(0.1),
                                            maxBackoff: TimeSpan.FromSeconds(30),
                                            maxRetryCount: 3);

Yeniden deneme ilkesi tek işlem düzeyinde ayarlanamaz.The retry policy cannot be set at the individual operation level. Mesajlaşma istemcisinin tüm işlemleri için geçerlidir.It applies to all operations for the messaging client. Aşağıdaki tabloda yerleşik yeniden deneme ilkelerine ilişkin varsayılan ayarlar gösterilmektedir.The following table shows the default settings for the built-in retry policy.

AyarSetting Varsayılan değerDefault value AnlamıMeaning
İlkePolicy ÜstelExponential Üstel geri alma.Exponential back-off.
MinimalBackoffMinimalBackoff 00 En düşük geri alma aralığı.Minimum back-off interval. DeltaBackoff parametresinden hesaplanan yeniden deneme aralığına eklenir.This is added to the retry interval computed from deltaBackoff.
MaximumBackoffMaximumBackoff 30 saniye30 seconds En yüksek geri alma aralığı.Maximum back-off interval. Hesaplanan yeniden deneme aralığı MaxBackoff değerinden büyükse MaximumBackoff kullanılır.MaximumBackoff is used if the computed retry interval is greater than MaxBackoff.
DeltaBackoffDeltaBackoff 3 saniye3 seconds Yeniden denemeler arasındaki geri alma aralığı.Back-off interval between retries. Bu zaman aralığının katları, sonraki yeniden deneme girişimleri için kullanılır.Multiples of this timespan will be used for subsequent retry attempts.
TimeBufferTimeBuffer 5 saniye5 seconds Yeniden denemeyle ilişkili sonlandırma süresi arabelleği.The termination time buffer associated with the retry. Kalan süre TimeBuffer değerinden küçükse yeniden deneme girişimleri terk edilir.Retry attempts will be abandoned if the remaining time is less than TimeBuffer.
MaxRetryCountMaxRetryCount 1010 En fazla yeniden deneme sayısı.The maximum number of retries.
ServerBusyBaseSleepTimeServerBusyBaseSleepTime 10 saniye10 seconds Karşılaşılan son özel durum ServerBusyException ise bu değer hesaplanan yeniden deneme aralığına eklenir.If the last exception encountered was ServerBusyException, this value will be added to the computed retry interval. Bu değer değiştirilemez.This value cannot be changed.

Yeniden deneme kullanım kılavuzuRetry usage guidance

Service Bus kullanırken aşağıdaki yönergeleri göz önünde bulundurun:Consider the following guidelines when using Service Bus:

  • İ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.When using the built-in RetryExponential implementation, do not implement a fallback operation as the policy reacts to Server Busy exceptions and automatically switches to an appropriate retry mode.
  • Service Bus, birincil ad alanındaki kuyruk başarısız olursa ayrı bir ad alanındaki yedek bir kuyruğa otomatik yük devretme gerçekleştiren Eşleştirilmiş Ad Alanları adlı bir özelliği destekler.Service Bus supports a feature called Paired Namespaces, which implements automatic failover to a backup queue in a separate namespace if the queue in the primary namespace fails. İkincil kuyruktan alınan iletiler, kurtarıldığında birincil kuyruğa geri gönderilebilir.Messages from the secondary queue can be sent back to the primary queue when it recovers. Bu özellik, geçici hataları gidermeye yardımcı olur.This feature helps to address transient failures. Daha fazla bilgi için bkz. Zaman Uyumsuz Mesajlaşma Düzenleri ve Yüksek Kullanılabilirlik.For more information, see Asynchronous Messaging Patterns and High Availability.

Yeniden deneme işlemleri için aşağıdaki ayarlarla başlamayı düşünün.Consider starting with following settings for retrying operations. Bunlar genel amaçlı ayarlardır ve kendi senaryonuza uygun olması için işlemleri izlemeniz ve değerlere ince ayar yapmanız gerekir.These are general purpose settings, and you should monitor the operations and fine tune the values to suit your own scenario.

BağlamContext En büyük gecikme süresi örneğiExample maximum latency Yeniden deneme ilkesiRetry policy AyarlarSettings Nasıl çalışır?How it works
Etkileşimli, UI veya ön planInteractive, UI, or foreground 2 saniye*2 seconds* ÜstelExponential MinimumBackoff = 0MinimumBackoff = 0
MaximumBackoff = 30 sn.MaximumBackoff = 30 sec.
DeltaBackoff = 300 ms.DeltaBackoff = 300 msec.
TimeBuffer = 300 ms.TimeBuffer = 300 msec.
MaxRetryCount = 2MaxRetryCount = 2
Deneme 1: 0 sn gecikme.Attempt 1: Delay 0 sec.
Deneme 2: Yaklaşık 300 MS gecikme.Attempt 2: Delay ~300 msec.
Deneme 3: Yaklaşık 900 MS gecikme.Attempt 3: Delay ~900 msec.
Arka plan ya da toplu işBackground or batch 30 saniye30 seconds ÜstelExponential MinimumBackoff = 1MinimumBackoff = 1
MaximumBackoff = 30 sn.MaximumBackoff = 30 sec.
DeltaBackoff = 1,75 sn.DeltaBackoff = 1.75 sec.
TimeBuffer = 5 sn.TimeBuffer = 5 sec.
MaxRetryCount = 3MaxRetryCount = 3
Deneme 1: Yaklaşık 1 sn gecikme.Attempt 1: Delay ~1 sec.
Deneme 2: Yaklaşık 3 sn gecikme.Attempt 2: Delay ~3 sec.
Deneme 3: Yaklaşık 6 MS gecikme.Attempt 3: Delay ~6 msec.
Deneme 4: Yaklaşık 13 MS gecikme.Attempt 4: Delay ~13 msec.

* Sunucu Meşgul yanıtı alınırsa eklenen ilave gecikme dahil değildir.* Not including additional delay that is added if a Server Busy response is received.

TelemetriTelemetry

Service Bus, yeniden denemeleri bir EventSource kullanarak ETW olayı olarak kaydededer.Service Bus logs retries as ETW events using an EventSource. 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.You must attach an EventListener to the event source to capture the events and view them in Performance Viewer, or write them to a suitable destination log. Yeniden deneme olayları aşağıdaki biçimdedir:The retry events are of the following form:

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"

ÖrneklerExamples

Aşağıdaki kod örneği, şunun için yeniden deneme ilkesinin nasıl ayarlanacağını gösterir:The following code example shows how to set the retry policy for:

  • Bir ad alanı yöneticisi.A namespace manager. İlke bu yönetici üzerindeki tüm işlemler için geçerlidir ve tek işlemler için geçersiz kılınamaz.The policy applies to all operations on that manager, and cannot be overridden for individual operations.
  • Bir mesajlaşma fabrikası.A messaging factory. İlke bu fabrikadan oluşturulan tüm istemciler için geçerlidir ve tek istemci oluşturulurken geçersiz kılınamaz.The policy applies to all clients created from that factory, and cannot be overridden when creating individual clients.
  • Tek bir mesajlaşma istemcisi.An individual messaging client. Bir istemci oluşturulduktan sonra o istemci için yeniden deneme ilkesi ayarlayabilirsiniz.After a client has been created, you can set the retry policy for that client. İlke, o istemci üzerindeki tüm işlemler için geçerli olur.The policy applies to all operations on that client.
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 bilgiMore information

Service FabricService 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.Distributing reliable services in a Service Fabric cluster guards against most of the potential transient faults discussed in this article. Ancak yine de bazı geçici hatalar oluşabilir.Some transient faults are still possible, however. Örneğin, adlandırma hizmeti bir istek aldığında bir yönlendirme isteğinin ortasındaysa özel durum oluşturabilir.For example, the naming service might be in the middle of a routing change when it gets a request, causing it to throw an exception. Aynı istek 100 milisaniye sonra gelirse büyük olasılıkla başarılı olur.If the same request comes 100 milliseconds later, it will probably succeed.

Dahili olarak, Service Fabric bu tür bir geçici hatayı yönetir.Internally, Service Fabric manages this kind of transient fault. Hizmetlerinizi ayarlarken OperationRetrySettings sınıfını kullanarak bazı ayarları yapılandırabilirsiniz.You can configure some settings by using the OperationRetrySettings class while setting up your services. Aşağıdaki kodda bir örnek gösterilmektedir.The following code shows an example. Çoğu durumda bu gerekli olmaz ve varsayılan ayarlar yeterli olur.In most cases, this should not be necessary, and the default settings will be fine.

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 bilgiMore information

ADO.NET kullanarak SQL veritabanıSQL Database using 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.SQL Database is a hosted SQL database available in a range of sizes and as both a standard (shared) and premium (non-shared) service.

Yeniden deneme mekanizmasıRetry mechanism

SQL Veritabanı, ADO.NET kullanarak erişildiğinde yeniden denemeler için yerleşik bir destek sunmaz.SQL Database has no built-in support for retries when accessed using ADO.NET. Ancak, bir isteğin neden başarısız olduğunu belirlemek için isteklerden alınan dönüş kodları kullanılabilir.However, the return codes from requests can be used to determine why a request failed. SQL Veritabanı ağ kapasitesini azaltma hakkında daha fazla bilgi için bkz. Azure SQL Veritabanı kaynak limitleri.For more information about SQL Database throttling, see Azure SQL Database resource limits. İlgili hata kodlarının listesi için bkz. SQL Veritabanı istemci uygulamaları için SQL hata kodları.For a list of relevant error codes, see SQL error codes for SQL Database client applications.

SQL Veritabanı için yeniden denemeleri uygulamak üzere Polly kitaplığını kullanabilirsiniz.You can use the Polly library to implement retries for SQL Database. Bkz. Polly ile geçici hata işleme.See Transient fault handling with Polly.

Yeniden deneme kullanım kılavuzuRetry usage guidance

ADO.NET kullanarak SQL Veritabanına erişirken aşağıdaki yönergeleri göz önünde bulundurun:Consider the following guidelines when accessing SQL Database using ADO.NET:

  • Uygun hizmet seçeneğini belirleyin (paylaşılan veya premium).Choose the appropriate service option (shared or 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.A shared instance may suffer longer than usual connection delays and throttling due to the usage by other tenants of the shared server. 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.If more predictable performance and reliable low latency operations are required, consider choosing the premium option.
  • 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.Ensure that you perform retries at the appropriate level or scope to avoid non-idempotent operations causing inconsistency in the data. Tüm işlemlerin tutarsızlığa neden olmadan tekrarlanabilmesi için bir kez etkili olması idealdir.Ideally, all operations should be idempotent so that they can be repeated without causing inconsistency. 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.Where this is not the case, the retry should be performed at a level or scope that allows all related changes to be undone if one operation fails; for example, from within a transactional scope. Daha fazla bilgi için bkz. Bulut Hizmeti Temelleri Veri Erişim Katmanı – Geçici Hata İşleme.For more information, see Cloud Service Fundamentals Data Access Layer – Transient Fault Handling.
  • Ç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.A fixed interval strategy is not recommended for use with Azure SQL Database except for interactive scenarios where there are only a few retries at very short intervals. Bunun yerine, senaryoların büyük bölümü için bir üstel geri alma stratejisi kullanmayı düşünün.Instead, consider using an exponential back-off strategy for the majority of scenarios.
  • Bağlantıları tanımlarken bağlantı ve komut zaman aşımları için uygun bir değer seçin.Choose a suitable value for the connection and command timeouts when defining connections. 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.Too short a timeout may result in premature failures of connections when the database is busy. 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.Too long a timeout may prevent the retry logic working correctly by waiting too long before detecting a failed connection. 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.The value of the timeout is a component of the end-to-end latency; it is effectively added to the retry delay specified in the retry policy for every retry attempt.
  • Ü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.Close the connection after a certain number of retries, even when using an exponential back off retry logic, and retry the operation on a new connection. Aynı işlemin aynı bağlantı üzerinde birden çok kez yeniden denenmesi bağlantı sorunlarına katkıda bulunan bir etken olabilir.Retrying the same operation multiple times on the same connection can be a factor that contributes to connection problems. Bu tekniğin bir örneği için bkz. Bulut Hizmeti Temelleri Veri Erişim Katmanı – Geçici Hata İşleme.For an example of this technique, see Cloud Service Fundamentals Data Access Layer – Transient Fault Handling.
  • 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.When connection pooling is in use (the default) there is a chance that the same connection will be chosen from the pool, even after closing and reopening a connection. 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.If this is the case, a technique to resolve it is to call the ClearPool method of the SqlConnection class to mark the connection as not reusable. 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.However, you should do this only after several connection attempts have failed, and only when encountering the specific class of transient failures such as SQL timeouts (error code -2) related to faulty connections.
  • 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.If the data access code uses transactions initiated as TransactionScope instances, the retry logic should reopen the connection and initiate a new transaction scope. Bu nedenle, yeniden denenebilir kod bloğu tüm işlem kapsamını içine almalıdır.For this reason, the retryable code block should encompass the entire scope of the transaction.

Yeniden deneme işlemleri için aşağıdaki ayarlarla başlamayı düşünün.Consider starting with following settings for retrying operations. Bunlar genel amaçlı ayarlardır ve kendi senaryonuza uygun olması için işlemleri izlemeniz ve değerlere ince ayar yapmanız gerekir.These are general purpose settings, and you should monitor the operations and fine tune the values to suit your own scenario.

BağlamContext Örnek hedef E2E
en uzun gecikme süresi
Sample target E2E
max latency
Yeniden deneme stratejisiRetry strategy AyarlarSettings DeğerlerValues Nasıl çalışır?How it works
Etkileşimli, UI,Interactive, UI,
veya ön planor foreground
2 sn2 sec FixedIntervalFixedInterval Yeniden deneme sayısıRetry count
Yeniden deneme aralığıRetry interval
İlk hızlı yeniden denemeFirst fast retry
33
500 ms500 ms
truetrue
Deneme 1 - 0 sn gecikmeAttempt 1 - delay 0 sec
Deneme 2 - 500 ms gecikmeAttempt 2 - delay 500 ms
Deneme 3 - 500 ms gecikmeAttempt 3 - delay 500 ms
Arka planBackground
veya toplu işor batch
30 sn30 sec ExponentialBackoffExponentialBackoff Yeniden deneme sayısıRetry count
En düşük geri almaMin back-off
En yüksek geri almaMax back-off
Delta geri almaDelta back-off
İlk hızlı yeniden denemeFirst fast retry
55
0 sn0 sec
60 sn60 sec
2 sn2 sec
falsefalse
Deneme 1 - 0 sn gecikmeAttempt 1 - delay 0 sec
Deneme 2 - yaklaşık 2 sn gecikmeAttempt 2 - delay ~2 sec
Deneme 3 - yaklaşık 6 sn gecikmeAttempt 3 - delay ~6 sec
Deneme 4 - yaklaşık 14 sn gecikmeAttempt 4 - delay ~14 sec
Deneme 5 - yaklaşık 30 sn gecikmeAttempt 5 - delay ~30 sec

Not

Uçtan uca gecikme hedefleri, hizmetle kurulan bağlantılar için varsayılan zaman aşımını kabul eder.The end-to-end latency targets assume the default timeout for connections to the service. 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.If you specify longer connection timeouts, the end-to-end latency will be extended by this additional time for every retry attempt.

ÖrneklerExamples

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.This section shows how you can use Polly to access Azure SQL Database using a set of retry policies configured in the Policy class.

Aşağıdaki kod, üstel geri alma ile ExecuteAsync çağıran SqlCommand sınıfı üzerinde bir genişletme yöntemi göstermektedir.The following code shows an extension method on the SqlCommand class that calls ExecuteAsync with exponential backoff.

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 200ms delay.
        onRetry: (exception, attempt) =>
        {
            // Capture some info 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.This asynchronous extension method can be used as follows.

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

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

Daha fazla bilgiMore information

SQL veritabanı'ndan en alma ile ilgili genel yönergeler için bkz. Azure SQL veritabanı performansı ve esneklik Kılavuzu.For general guidance on getting the most from SQL Database, see Azure SQL Database performance and elasticity guide.

Entity Framework 6 kullanarak SQL veritabanıSQL Database using Entity Framework 6

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.SQL Database is a hosted SQL database available in a range of sizes and as both a standard (shared) and premium (non-shared) service. 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.Entity Framework is an object-relational mapper that enables .NET developers to work with relational data using domain-specific objects. Geliştiricilerin genellikle yazması gereken çoğu veri erişim kodu gereksinimini ortadan kaldırır.It eliminates the need for most of the data-access code that developers usually need to write.

Yeniden deneme mekanizmasıRetry mechanism

Entity Framework 6.0 kullanarak SQL veritabanına erişirken yeniden deneme desteği sağlanır ve daha yüksek bir mekanizma aracılığıyla adlı bağlantı dayanıklılığı / yeniden deneme mantığı.Retry support is provided when accessing SQL Database using Entity Framework 6.0 and higher through a mechanism called Connection resiliency / retry logic. Yeniden deneme mekanizmasının ana özellikleri şunlardır:The main features of the retry mechanism are:

  • Birincil soyutlama IDbExecutionStrategy arabirimidir.The primary abstraction is the IDbExecutionStrategy interface. Bu arabirim:This interface:
    • Zaman uyumlu ve zaman uyumsuz Execute* yöntemlerini tanımlar.Defines synchronous and asynchronous Execute* methods.
    • 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.Defines classes that can be used directly or can be configured on a database context as a default strategy, mapped to provider name, or mapped to a provider name and server name. 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.When configured on a context, retries occur at the level of individual database operations, of which there might be several for a given context operation.
    • Başarısız bir bağlantının ne zaman ve nasıl yeniden deneneceğini tanımlar.Defines when to retry a failed connection, and how.
  • IDbExecutionStrategy arabiriminin birkaç yerleşik uygulamasını içerir:It includes several built-in implementations of the IDbExecutionStrategy interface:
    • Varsayılan - yeniden deneme yok.Default - no retrying.
    • SQL Veritabanı için varsayılan (otomatik) - yeniden deneme yok, ancak özel durumları inceler ve SQL Veritabanı stratejisini kullanma önerisi ile sarmalar.Default for SQL Database (automatic) - no retrying, but inspects exceptions and wraps them with suggestion to use the SQL Database strategy.
    • SQL Veritabanı için varsayılan - üstel (teel sınıftan devralınan) ve SQL Veritabanı algılama mantığı.Default for SQL Database - exponential (inherited from base class) plus SQL Database detection logic.
  • Rastgele seçim içeren bir üstel geri alma stratejisi uygular.It implements an exponential back-off strategy that includes randomization.
  • Yerleşik yeniden deneme sınıfları durum bilgisi olan sınıflardır ve iş parçacığı bakımından güvenli değildir.The built-in retry classes are stateful and are not thread safe. Ancak, geçerli işlem tamamlandıktan sonra yeniden kullanılabilirler.However, they can be reused after the current operation is completed.
  • Belirtilen yeniden deneme sayısı aşılırsa sonuçlar yeni bir özel durumda sarmalanır.If the specified retry count is exceeded, the results are wrapped in a new exception. Geçerli özel durumu aniden ortaya çıkarmaz.It does not bubble up the current exception.

İlke yapılandırmasıPolicy configuration

Entity Framework kullanan SQL Veritabanı 6.0 ve üzerine erişirken yeniden deneme desteği sağlanır.Retry support is provided when accessing SQL Database using Entity Framework 6.0 and higher. Yeniden deneme ilkeleri programlı olarak yapılandırılır.Retry policies are configured programmatically. Yapılandırma, işlem başına temelinde değiştirilemez.The configuration cannot be changed on a per-operation basis.

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.When configuring a strategy on the context as the default, you specify a function that creates a new strategy on demand. 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.The following code shows how you can create a retry configuration class that extends the DbConfiguration base class.

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.You can then specify this as the default retry strategy for all operations using the SetConfiguration method of the DbConfiguration instance when the application starts. Varsayılan olarak EF, yapılandırma sınıfını otomatik olarak bulur ve kullanır.By default, EF will automatically discover and use the configuration class.

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.You can specify the retry configuration class for a context by annotating the context class with a DbConfigurationType attribute. 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.However, if you have only one configuration class, EF will use it without the need to annotate the context.

[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.If you need to use different retry strategies for specific operations, or disable retries for specific operations, you can create a configuration class that allows you to suspend or swap strategies by setting a flag in the CallContext. 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.The configuration class can use this flag to switch strategies, or disable the strategy you provide and use a default strategy. Daha fazla bilgi için yürütme stratejisini askıya alma (EF6 sonrası).For more information, see Suspend Execution Strategy (EF6 onwards).

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.Another technique for using specific retry strategies for individual operations is to create an instance of the required strategy class and supply the desired settings through parameters. Daha sonra ExecuteAsync yöntemini çağırın.You then invoke its ExecuteAsync method.

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.The simplest way to use a DbConfiguration class is to locate it in the same assembly as the DbContext class. Ancak, farklı etkileşimli ve arka plan yeniden deneme stratejileri gibi farklı senaryolarda aynı bağlam gerekli olduğunda bu yol uygun değildir.However, this is not appropriate when the same context is required in different scenarios, such as different interactive and background retry strategies. 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.If the different contexts execute in separate AppDomains, you can use the built-in support for specifying configuration classes in the configuration file or set it explicitly using code. Aynı AppDomain içinde farklı bağlamların yürütülmesi gerekiyorsa özel bir çözüm gerekli olur.If the different contexts must execute in the same AppDomain, a custom solution will be required.

Daha fazla bilgi için kod tabanlı yapılandırma (EF6 sonrası).For more information, see Code-Based Configuration (EF6 onwards).

Aşağıdaki tabloda EF6 kullanırken yerleşik yeniden deneme ilkelerine ilişkin varsayılan ayarlar gösterilmektedir.The following table shows the default settings for the built-in retry policy when using EF6.

AyarSetting Varsayılan değerDefault value AnlamıMeaning
İlkePolicy ÜstelExponential Üstel geri alma.Exponential back-off.
MaxRetryCountMaxRetryCount 55 En fazla yeniden deneme sayısı.The maximum number of retries.
MaxDelayMaxDelay 30 saniye30 seconds Yeniden denemeler arasındaki en büyük gecikme.The maximum delay between retries. Bu değer, gecikme dizisinin hesaplanma yöntemini etkilemez.This value does not affect how the series of delays are computed. Yalnızca bir üst sınır tanımlar.It only defines an upper bound.
DefaultCoefficientDefaultCoefficient 1 saniye1 second Üstel geri alma hesaplaması için katsayı.The coefficient for the exponential back-off computation. Bu değer değiştirilemez.This value cannot be changed.
DefaultRandomFactorDefaultRandomFactor 1.11.1 Her giriş için rastgele bir gecikme eklerken kullanılan çarpan.The multiplier used to add a random delay for each entry. Bu değer değiştirilemez.This value cannot be changed.
DefaultExponentialBaseDefaultExponentialBase 22 Sonraki gecikmeyi hesaplamak için kullanılan çarpan.The multiplier used to calculate the next delay. Bu değer değiştirilemez.This value cannot be changed.

Yeniden deneme kullanım kılavuzuRetry usage guidance

EF6 kullanarak SQL Veritabanına erişirken aşağıdaki yönergeleri göz önünde bulundurun:Consider the following guidelines when accessing SQL Database using EF6:

  • Uygun hizmet seçeneğini belirleyin (paylaşılan veya premium).Choose the appropriate service option (shared or 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.A shared instance may suffer longer than usual connection delays and throttling due to the usage by other tenants of the shared server. Tahmin edilebilir performansa ve güvenilir düşük gecikme sürelerine sahip işlemler gerekiyorsa premium seçeneğini tercih etmeyi düşünün.If predictable performance and reliable low latency operations are required, consider choosing the premium option.

  • Azure SQL Veritabanı ile sabit bir aralık stratejisinin kullanılması önerilmez.A fixed interval strategy is not recommended for use with Azure SQL Database. 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.Instead, use an exponential back-off strategy because the service may be overloaded, and longer delays allow more time for it to recover.

  • Bağlantıları tanımlarken bağlantı ve komut zaman aşımları için uygun bir değer seçin.Choose a suitable value for the connection and command timeouts when defining connections. Zaman aşımını hem iş mantığınıza hem de testlere göre belirleyin.Base the timeout on both your business logic design and through testing. Zaman içinde veri hacimleri ve iş süreçleri değiştikçe bu değeri değiştirmeniz gerekebilir.You may need to modify this value over time as the volumes of data or the business processes change. 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.Too short a timeout may result in premature failures of connections when the database is busy. 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.Too long a timeout may prevent the retry logic working correctly by waiting too long before detecting a failed connection. 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.The value of the timeout is a component of the end-to-end latency, although you cannot easily determine how many commands will execute when saving the context. DbContext örneğinin CommandTimeout özelliğini ayarlayarak varsayılan zaman aşımını değiştirebilirsiniz.You can change the default timeout by setting the CommandTimeout property of the DbContext instance.

  • Entity Framework, yapılandırma dosyalarında tanımlanan yeniden deneme yapılandırmalarını destekler.Entity Framework supports retry configurations defined in configuration files. 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.However, for maximum flexibility on Azure you should consider creating the configuration programmatically within the application. 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.The specific parameters for the retry policies, such as the number of retries and the retry intervals, can be stored in the service configuration file and used at runtime to create the appropriate policies. Böylece ayarlar uygulamanın yeniden başlatılmasına gerek olmadan değiştirilebilir.This allows the settings to be changed without requiring the application to be restarted.

Yeniden deneme işlemleri için aşağıdaki ayarlarla başlamayı düşünün.Consider starting with the following settings for retrying operations. Yeniden deneme girişimleri arasındaki gecikmeyi belirtemezsiniz (sabit bir değerdir ve üstel bir dizi olarak oluşturulur).You cannot specify the delay between retry attempts (it is fixed and generated as an exponential sequence). Ö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.You can specify only the maximum values, as shown here; unless you create a custom retry strategy. Bunlar genel amaçlı ayarlardır ve kendi senaryonuza uygun olması için işlemleri izlemeniz ve değerlere ince ayar yapmanız gerekir.These are general purpose settings, and you should monitor the operations and fine tune the values to suit your own scenario.

BağlamContext Örnek hedef E2E
en uzun gecikme süresi
Sample target E2E
max latency
Yeniden deneme ilkesiRetry policy AyarlarSettings DeğerlerValues Nasıl çalışır?How it works
Etkileşimli, UI,Interactive, UI,
veya ön planor foreground
2 saniye2 seconds ÜstelExponential MaxRetryCountMaxRetryCount
MaxDelayMaxDelay
33
750 ms750 ms
Deneme 1 - 0 sn gecikmeAttempt 1 - delay 0 sec
Deneme 2 - 750 ms gecikmeAttempt 2 - delay 750 ms
Deneme 3 - 750 ms gecikmeAttempt 3 – delay 750 ms
Arka planBackground
veya toplu işor batch
30 saniye30 seconds ÜstelExponential MaxRetryCountMaxRetryCount
MaxDelayMaxDelay
55
12 saniye12 seconds
Deneme 1 - 0 sn gecikmeAttempt 1 - delay 0 sec
Deneme 2 - yaklaşık 1 sn gecikmeAttempt 2 - delay ~1 sec
Deneme 3 - yaklaşık 3 sn gecikmeAttempt 3 - delay ~3 sec
Deneme 4 - yaklaşık 7 sn gecikmeAttempt 4 - delay ~7 sec
Deneme 5 - 12 sn gecikmeAttempt 5 - delay 12 sec

Not

Uçtan uca gecikme hedefleri, hizmetle kurulan bağlantılar için varsayılan zaman aşımını kabul eder.The end-to-end latency targets assume the default timeout for connections to the service. 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.If you specify longer connection timeouts, the end-to-end latency will be extended by this additional time for every retry attempt.

ÖrneklerExamples

Aşağıdaki kod örneğinde Entity Framework kullanan bir basit veri erişimi çözümü tanımlanmaktadır.The following code example defines a simple data access solution that uses Entity Framework. DbConfiguration özelliğini genişleten BlogConfiguration adlı bir sınıfın örneğini tanımlayarak belirli bir yeniden deneme stratejisi ayarlar.It sets a specific retry strategy by defining an instance of a class named BlogConfiguration that extends DbConfiguration.

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 daha fazla örnek Bağlantı Dayanıklılığı / Yeniden Deneme Mantığı içinde bulunabilir.More examples of using the Entity Framework retry mechanism can be found in Connection Resiliency / Retry Logic.

Daha fazla bilgiMore information

Entity Framework Core kullanan SQL veritabanıSQL Database using Entity Framework Core

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.Entity Framework Core is an object-relational mapper that enables .NET Core developers to work with data using domain-specific objects. Geliştiricilerin genellikle yazması gereken çoğu veri erişim kodu gereksinimini ortadan kaldırır.It eliminates the need for most of the data-access code that developers usually need to write. 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.This version of Entity Framework was written from the ground up, and doesn't automatically inherit all the features from EF6.x.

Yeniden deneme mekanizmasıRetry mechanism

Entity Framework Core ile bir mekanizma kullanarak SQL veritabanına erişim çağrıldığında, yeniden deneme desteği sağlanır bağlantı dayanıklılığı.Retry support is provided when accessing SQL Database using Entity Framework Core through a mechanism called connection resiliency. Bağlantı dayanıklılığı EF Core 1.1.0 sürümünde kullanıma sunulmuştur.Connection resiliency was introduced in EF Core 1.1.0.

Birincil soyutlama IExecutionStrategy arabirimidir.The primary abstraction is the IExecutionStrategy interface. 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.The execution strategy for SQL Server, including SQL Azure, is aware of the exception types that can be retried and has sensible defaults for maximum retries, delay between retries, and so on.

ÖrneklerExamples

Aşağıdaki kod, veritabanı ile bir oturumu temsil eden DbContext nesnesini yapılandırırken otomatik yeniden denemeleri etkinleştirir.The following code enables automatic retries when configuring the DbContext object, which represents a session with the database.

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder
        .UseSqlServer(
            @"Server=(localdb)\mssqllocaldb;Database=EFMiscellanous.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.The following code shows how to execute a transaction with automatic retries, by using an execution strategy. İşlem bir temsilcide tanımlanır.The transaction is defined in a delegate. Geçici bir hata oluşursa yürütme stratejisi temsilciyi yeniden çağırır.If a transient failure occurs, the execution strategy will invoke the delegate again.

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 StorageAzure Storage

Azure depolama hizmetleri tablo ve blob depolama, dosya ve depolama kuyrukları içerir.Azure Storage services include table and blob storage, files, and storage queues.

Yeniden deneme mekanizmasıRetry mechanism

Yeniden denemeler tek REST işlem düzeyinde gerçekleşir ve istemci API uygulamasının ayrılmaz bir parçasıdır.Retries occur at the individual REST operation level and are an integral part of the client API implementation. İstemci depolama SDK'sı, IExtendedRetryPolicy Arabirimi uygulayan sınıflar kullanır.The client storage SDK uses classes that implement the IExtendedRetryPolicy Interface.

Arabirimin farklı uygulamaları vardır.There are different implementations of the interface. Depolama istemcileri tablo, blob ve kuyruklara erişim için özel olarak tasarlanmış ilkeler arasından seçim yapabilir.Storage clients can choose from policies specifically designed for accessing tables, blobs, and queues. Her uygulama, temelde yeniden deneme aralığı ve diğer ayrıntıları tanımlayan farklı bir yeniden deneme stratejisi kullanır.Each implementation uses a different retry strategy that essentially defines the retry interval and other details.

Yerleşik sınıflar, rastgele yeniden deneme aralığı seçimi ile doğrusal (sabit gecikme) ve üstel desteği sağlar.The built-in classes provide support for linear (constant delay) and exponential with randomization retry intervals. 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.There is also a no retry policy for use when another process is handling retries at a higher level. Ancak, yerleşik sınıfları tarafından sağlanmayan özel gereksinimleriniz varsa kendi yeniden deneme sınıflarınızı uygulayabilirsiniz.However, you can implement your own retry classes if you have specific requirements not provided by the built-in classes.

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.Alternate retries switch between primary and secondary storage service location if you are using read access geo-redundant storage (RA-GRS) and the result of the request is a retryable error. Daha fazla bilgi için bkz. Azure Depolama Yedekliliği Seçenekleri.See Azure Storage Redundancy Options for more information.

İlke yapılandırmasıPolicy configuration

Yeniden deneme ilkeleri programlı olarak yapılandırılır.Retry policies are configured programmatically. Bir TableRequestOptions, BlobRequestOptions, FileRequestOptions ya da QueueRequestOptions örneğinin oluşturulup doldurulması tipik bir yordamdır.A typical procedure is to create and populate a TableRequestOptions, BlobRequestOptions, FileRequestOptions, or QueueRequestOptions instance.

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.The request options instance can then be set on the client, and all operations with the client will use the specified request options.

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.You can override the client request options by passing a populated instance of the request options class as a parameter to operation methods.

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.You use an OperationContext instance to specify the code to execute when a retry occurs and when an operation has completed. Bu kod, günlüklerde ve telemetride kullanıma yönelik işlemler hakkında bilgi toplayabilir.This code can collect information about the operation for use in logs and telemetry.

// 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).In addition to indicating whether a failure is suitable for retry, the extended retry policies return a RetryContext object that indicates the number of retries, the results of the last request, whether the next retry will happen in the primary or secondary location (see table below for details). RetryContext nesnesinin özellikleri bir yeniden deneme işleminin denenip denenmeyeceğine ve ne zaman deneneceğine karar vermek için kullanılabilir.The properties of the RetryContext object can be used to decide if and when to attempt a retry. Daha fazla bilgi için bkz. IExtendedRetryPolicy.Evaluate Yöntemi.For more details, see IExtendedRetryPolicy.Evaluate Method.

Aşağıdaki tablolarda, yerleşik yeniden deneme ilkelerine ilişkin varsayılan ayarlar gösterilmektedir.The following tables show the default settings for the built-in retry policies.

İstek seçenekleri:Request options:

AyarSetting Varsayılan değerDefault value AnlamıMeaning
MaximumExecutionTimeMaximumExecutionTime NoneNone Tüm olası yeniden deneme girişimleri dahil olmak üzere istek için en uzun yürütme süresi.Maximum execution time for the request, including all potential retry attempts. Belirtilmezse, bir istek yararlanmak için izin verilen süre miktarını sınırsızdır.If it is not specified, then the amount of time that a request is permitted to take is unlimited. Diğer bir deyişle, istek askıda.In other words, the request might hang.
ServerTimeoutServerTimeout NoneNone İstek için sunucu zaman aşımı aralığı (değer saniye cinsinden yuvarlanır).Server timeout interval for the request (value is rounded to seconds). Belirtilmezse, sunucuya gönderilen tüm istekler için varsayılan değeri kullanır.If not specified, it will use the default value for all requests to the server. Genellikle en iyi seçenek, bu ayarın atlanarak sunucu varsayılan ayarının kullanılmasıdır.Usually, the best option is to omit this setting so that the server default is used.
LocationModeLocationMode NoneNone Depolama hesabı Okuma erişimli coğrafi olarak yedekli depolama (RA-GRS) çoğaltma seçeneği ile oluşturulduysa, isteği hangi konumun alması gerektiğini belirtmek üzere konum modunu kullanabilirsiniz.If the storage account is created with the Read access geo-redundant storage (RA-GRS) replication option, you can use the location mode to indicate which location should receive the request. Örneğin, PrimaryThenSecondary seçeneği belirtilmişse istekler her zaman öncelikle birincil konuma gönderilir.For example, if PrimaryThenSecondary is specified, requests are always sent to the primary location first. Bir istek başarısız olursa ikincil konuma gönderilir.If a request fails, it is sent to the secondary location.
RetryPolicyRetryPolicy ExponentialPolicyExponentialPolicy Her seçeneğin ayrıntıları için aşağıya bakın.See below for details of each option.

Üstel İlkesi:Exponential policy:

AyarSetting Varsayılan değerDefault value AnlamıMeaning
maxAttemptmaxAttempt 33 Yeniden deneme girişimlerinin sayısı.Number of retry attempts.
deltaBackoffdeltaBackoff 4 saniye4 seconds Yeniden denemeler arasındaki geri alma aralığı.Back-off interval between retries. Rastgele bir öğe de dahil olmak üzere bu zaman aralığının katları, sonraki yeniden deneme girişimleri için kullanılır.Multiples of this timespan, including a random element, will be used for subsequent retry attempts.
MinBackoffMinBackoff 3 saniye3 seconds DeltaBackoff parametresinden hesaplanan tüm yeniden deneme aralıklarına eklenir.Added to all retry intervals computed from deltaBackoff. Bu değer değiştirilemez.This value cannot be changed.
MaxBackoffMaxBackoff 120 saniye120 seconds Hesaplanan yeniden deneme aralığı MaxBackoff değerinden büyükse MaxBackoff kullanılır.MaxBackoff is used if the computed retry interval is greater than MaxBackoff. Bu değer değiştirilemez.This value cannot be changed.

Doğrusal İlkesi:Linear policy:

AyarSetting Varsayılan değerDefault value AnlamıMeaning
maxAttemptmaxAttempt 33 Yeniden deneme girişimlerinin sayısı.Number of retry attempts.
deltaBackoffdeltaBackoff 30 saniye30 seconds Yeniden denemeler arasındaki geri alma aralığı.Back-off interval between retries.

Yeniden deneme kullanım kılavuzuRetry usage guidance

Depolama istemcisi API’sini kullanarak Azure depolama hizmetlerine erişirken aşağıdaki yönergeleri göz önünde bulundurun:Consider the following guidelines when accessing Azure storage services using the storage client API:

  • Gereksinimlerinize uygun oldukları durumlarda Microsoft.WindowsAzure.Storage.RetryPolicies ad alanından yerleşik yeniden deneme ilkelerini kullanın.Use the built-in retry policies from the Microsoft.WindowsAzure.Storage.RetryPolicies namespace where they are appropriate for your requirements. Çoğu durumda bu ilkeler yeterli olacaktır.In most cases, these policies will be sufficient.

  • ExponentialRetry ilkesini toplu işlemlerde, arka plan görevlerinde veya etkileşimli olmayan senaryolarda kullanın.Use the ExponentialRetry policy in batch operations, background tasks, or non-interactive scenarios. Bu senaryolarda genellikle hizmetin kurtarılması için daha fazla zaman verebilirsiniz ve işlemin zamanla başarılı olma olasılığı artar.In these scenarios, you can typically allow more time for the service to recover—with a consequently increased chance of the operation eventually succeeding.

  • 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.Consider specifying the MaximumExecutionTime property of the RequestOptions parameter to limit the total execution time, but take into account the type and size of the operation when choosing a timeout value.

  • Özel bir yeniden deneme uygulamanız gerekirse, depolama istemcisi sınıflarının çevresinde sarmalayıcılar oluşturmaktan kaçının.If you need to implement a custom retry, avoid creating wrappers around the storage client classes. Bunun yerine, IExtendedRetryPolicy arabirimi ile var olan ilkeleri genişletme özelliklerini kullanın.Instead, use the capabilities to extend the existing policies through the IExtendedRetryPolicy interface.

  • 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.If you are using read access geo-redundant storage (RA-GRS) you can use the LocationMode to specify that retry attempts will access the secondary read-only copy of the store should the primary access fail. 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.However, when using this option you must ensure that your application can work successfully with data that may be stale if the replication from the primary store has not yet completed.

Yeniden deneme işlemleri için aşağıdaki ayarlarla başlamayı düşünün.Consider starting with following settings for retrying operations. Bunlar genel amaçlı ayarlardır ve kendi senaryonuza uygun olması için işlemleri izlemeniz ve değerlere ince ayar yapmanız gerekir.These are general purpose settings, and you should monitor the operations and fine tune the values to suit your own scenario.

BağlamContext Örnek hedef E2E
en uzun gecikme süresi
Sample target E2E
max latency
Yeniden deneme ilkesiRetry policy AyarlarSettings DeğerlerValues Nasıl çalışır?How it works
Etkileşimli, UI,Interactive, UI,
veya ön planor foreground
2 saniye2 seconds DoğrusalLinear maxAttemptmaxAttempt
deltaBackoffdeltaBackoff
33
500 ms500 ms
Deneme 1 - 500 ms gecikmeAttempt 1 - delay 500 ms
Deneme 2 - 500 ms gecikmeAttempt 2 - delay 500 ms
Deneme 3 - 500 ms gecikmeAttempt 3 - delay 500 ms
Arka planBackground
veya toplu işor batch
30 saniye30 seconds ÜstelExponential maxAttemptmaxAttempt
deltaBackoffdeltaBackoff
55
4 saniye4 seconds
Deneme 1 - yaklaşık 3 sn gecikmeAttempt 1 - delay ~3 sec
Deneme 2 - yaklaşık 7 sn gecikmeAttempt 2 - delay ~7 sec
Deneme 3 - yaklaşık 15 sn gecikmeAttempt 3 - delay ~15 sec

TelemetriTelemetry

Yeniden deneme girişimleri bir TraceSource günlüğüne kaydedilir.Retry attempts are logged to a TraceSource. Olayları yakalamak ve uygun bir hedef günlüğüne yazmak için bir TraceListener yapılandırmanız gerekir.You must configure a TraceListener to capture the events and write them to a suitable destination log. 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.You can use the TextWriterTraceListener or XmlWriterTraceListener to write the data to a log file, the EventLogTraceListener to write to the Windows Event Log, or the EventProviderTraceListener to write trace data to the ETW subsystem. Ayrıca, arabelleğin otomatik boşaltılmasını ve günlüğe kaydedilecek olayların ayrıntı düzeyini (Örneğin, Hata, Uyarı, Bilgilendirici ve Ayrıntılı) yapılandırabilirsiniz.You can also configure auto-flushing of the buffer, and the verbosity of events that will be logged (for example, Error, Warning, Informational, and Verbose). Daha fazla bilgi için bkz. .NET Depolama İstemci Kitaplığı ile İstemci Tarafı Günlük Kaydı.For more information, see Client-side Logging with the .NET Storage Client Library.

İşlemler, özel telemetri mantığı eklemek için kullanılabilen bir Retrying olayını kullanıma sunan OperationContext örneğini alabilir.Operations can receive an OperationContext instance, which exposes a Retrying event that can be used to attach custom telemetry logic. Daha fazla bilgi için bkz. OperationContext.Retrying Olayı.For more information, see OperationContext.Retrying Event.

ÖrneklerExamples

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.The following code example shows how to create two TableRequestOptions instances with different retry settings; one for interactive requests and one for background requests. Ö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.The example then sets these two retry policies on the client so that they apply for all requests, and also sets the interactive strategy on a specific request so that it overrides the default settings applied to the client.

using System;
using System.Threading.Tasks;
using Microsoft.WindowsAzure.Storage;
using Microsoft.WindowsAzure.Storage.RetryPolicies;
using Microsoft.WindowsAzure.Storage.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 bilgiMore information

Genel REST ve yeniden deneme yönergeleriGeneral REST and retry guidelines

Azure veya üçüncü taraf hizmetlere erişirken aşağıdaki noktaları göz önünde bulundurun:Consider the following when accessing Azure or third party services:

  • 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.Use a systematic approach to managing retries, perhaps as reusable code, so that you can apply a consistent methodology across all clients and all solutions.

  • Gibi bir yeniden deneme çerçevesi kullanmayı Polly polly yönetmek için hedef hizmet veya istemcinin yerleşik yoktur olması durumunda yeniden deneme mekanizması yeniden deneyin.Consider using a retry framework such as Polly to manage retries if the target service or client has no built-in retry mechanism. 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.This will help you implement a consistent retry behavior, and it may provide a suitable default retry strategy for the target service. Ancak, geçici hataları belirtirken özel durumları kullanmayan standart dışı davranışa sahip hizmetler için veya yeniden deneme davranışını Retry-Response yanıtı ile yönetmek istiyorsanız, özel bir yeniden deneme kodu oluşturmanız gerekebilir.However, you may need to create custom retry code for services that have non-standard behavior, that do not rely on exceptions to indicate transient failures, or if you want to use a Retry-Response reply to manage retry behavior.

  • 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.The transient detection logic will depend on the actual client API you use to invoke the REST calls. Yeni HttpClient sınıfı gibi bazı istemciler, başarılı olmayan HTTP durum kodu ile tamamlanmış istekler için özel durumlar oluşturmaz.Some clients, such as the newer HttpClient class, will not throw exceptions for completed requests with a non-success HTTP status code.

  • Hizmetten döndürülen HTTP durum kodu, hatanın geçici olup olmadığını belirtmeye yardımcı olabilir.The HTTP status code returned from the service can help to indicate whether the failure is transient. 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.You may need to examine the exceptions generated by a client or the retry framework to access the status code or to determine the equivalent exception type. Aşağıdaki HTTP kodları genellikle bir yeniden denemenin uygun olduğunu gösterir:The following HTTP codes typically indicate that a retry is appropriate:

    • 408 İstek Zaman Aşımı408 Request Timeout
    • 429 çok fazla istek429 Too Many Requests
    • 500 İç Sunucu Hatası500 Internal Server Error
    • 502 Hatalı Ağ Geçidi502 Bad Gateway
    • 503 Hizmet Kullanılamıyor503 Service Unavailable
    • 504 Ağ Geçidi Zaman Aşımı504 Gateway Timeout
  • Yeniden deneme mantığınız özel durumları temel alıyorsa, aşağıdakiler genellikle bağlantı kurulamayan geçici bir hatayı gösterir:If you base your retry logic on exceptions, the following typically indicate a transient failure where no connection could be established:

    • WebExceptionStatus.ConnectionClosedWebExceptionStatus.ConnectionClosed
    • WebExceptionStatus.ConnectFailureWebExceptionStatus.ConnectFailure
    • WebExceptionStatus.TimeoutWebExceptionStatus.Timeout
    • WebExceptionStatus.RequestCanceledWebExceptionStatus.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.In the case of a service unavailable status, the service might indicate the appropriate delay before retrying in the Retry-After response header or a different custom header. Hizmetler ayrıca özel üst bilgi olarak ya da yanıtın içeriğine eklenmiş halde ek bilgi gönderebilir.Services might also send additional information as custom headers, or embedded in the content of the response.

  • 408 İstek Zaman Aşımı dışındaki istemci hatalarını (4xx aralığındaki hatalar) temsil eden durum kodları için yeniden denemeyin.Do not retry for status codes representing client errors (errors in the 4xx range) except for a 408 Request Timeout.

  • 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.Thoroughly test your retry strategies and mechanisms under a range of conditions, such as different network states and varying system loadings.

Yeniden deneme stratejileriRetry strategies

Yeniden deneme stratejisi aralıklarının tipik türleri şunlardır:The following are the typical types of retry strategy intervals:

  • Üstel.Exponential. Belirtilen sayıda yeniden denemeler arasındaki aralığı belirlemek üzere rastgele üstel geri alma yaklaşımı kullanarak yeniden deneme gerçekleştiren bir yeniden deneme ilkesi.A retry policy that performs a specified number of retries, using a randomized exponential back off approach to determine the interval between retries. Örneğin:For example:

    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ı.Incremental. Belirtilen sayıda yeniden deneme girişimi ve yeniden denemeler arasında bir artımlı bir zaman aralığı içeren yeniden deneme stratejisi.A retry strategy with a specified number of retry attempts and an incremental time interval between retries. Örneğin:For example:

    retryInterval = TimeSpan.FromMilliseconds(this.initialInterval.TotalMilliseconds +
                    (this.increment.TotalMilliseconds * currentRetryCount));
    
  • LinearRetry.LinearRetry. Belirtilen sayıda yeniden denemeler arasında belirtilen sabit zaman aralığına kullanarak yeniden deneme gerçekleştiren bir yeniden deneme ilkesi.A retry policy that performs a specified number of retries, using a specified fixed time interval between retries. Örneğin:For example:

    retryInterval = this.deltaBackoff;
    

Polly ile geçici hata işlemeTransient fault handling with Polly

Polly polly programlı şekilde yeniden deneme işlemlerini bir kitaplıktır ve devre kesici stratejiler.Polly is a library to programatically handle retries and circuit breaker strategies. Polly projesi .NET Foundation’ın bir üyesidir.The Polly project is a member of the .NET Foundation. İ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.For services where the client does not natively support retries, Polly is a valid alternative and avoids the need to write custom retry code, which can be hard to implement correctly. Polly ayrıca yeniden denemeleri günlüğe kaydetmeniz için oluşan hataları izlemenin bir yolunu sağlar.Polly also provides a way to trace errors when they occur, so that you can log retries.

Daha fazla bilgiMore information