Vägledning för nytt försök för Azure-tjänsterRetry guidance for Azure services

De flesta Azure-tjänster och klient-SDK:er har en återförsöksmekanism.Most Azure services and client SDKs include a retry mechanism. Med dessa skiljer sig eftersom varje tjänst har olika egenskaper, så varje återförsöksmekanism justeras efter en specifik tjänst.However, these differ because each service has different characteristics and requirements, and so each retry mechanism is tuned to a specific service. I den här guiden sammanfattas återförsöksmekanismerna för majoriteten av Azure-tjänsterna och innehåller information som hjälper dig att använda, anpassa eller utöka återförsöksmekanismen för den tjänsten.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.

För allmänna råd om hanteringen av tillfälliga fel, och om återförsök av anslutningar och åtgärder mot tjänster och resurser, finns i Vägledning för återförsök.For general guidance on handling transient faults, and retrying connections and operations against services and resources, see Retry guidance.

I följande tabell sammanfattas återförsöksfunktionerna för de Azure-tjänster som beskriva i den här vägledningen.The following table summarizes the retry features for the Azure services described in this guidance.

TjänstService ÅterförsöksfunktionerRetry capabilities PrincipkonfigurationPolicy configuration OmfångScope TelemetrifunktionerTelemetry features
Azure Active DirectoryAzure Active Directory Inbyggd i ADAL-biblioteketNative in ADAL library Inbäddat i ADAL-biblioteketEmbedded into ADAL library InternInternal IngetNone
Cosmos DBCosmos DB Inbyggd i tjänstenNative in service Inte konfigurerbarNon-configurable GlobalGlobal TraceSourceTraceSource
Data Lake StoreData Lake Store Inbyggd i klientenNative in client Inte konfigurerbarNon-configurable Enskilda åtgärderIndividual operations IngetNone
Event HubsEvent Hubs Inbyggd i klientenNative in client ProgrammässigProgrammatic KlientClient IngetNone
IoT HubIoT Hub Inbyggd i klient-SDKNative in client SDK ProgrammässigProgrammatic KlientClient IngetNone
Azure Cache for RedisAzure Cache for Redis Inbyggd i klientenNative in client ProgrammässigProgrammatic KlientClient TextWriterTextWriter
SökSearch Inbyggd i klientenNative in client ProgrammässigProgrammatic KlientClient ETW eller anpassadETW or Custom
Service BusService Bus Inbyggd i klientenNative in client ProgrammässigProgrammatic Namespace Manager, Messaging Factory och ClientNamespace Manager, Messaging Factory, and Client ETWETW
Service FabricService Fabric Inbyggd i klientenNative in client ProgrammässigProgrammatic KlientClient IngetNone
SQL Database med ADO.NETSQL Database with ADO.NET PollyPolly Deklarativ och programmässigDeclarative and programmatic Enskilda instruktioner eller kodblockSingle statements or blocks of code AnpassatCustom
SQL Database med Entity FrameworkSQL Database with Entity Framework Inbyggd i klientenNative in client ProgrammässigProgrammatic Global per AppDomainGlobal per AppDomain IngetNone
SQL Database med Entity Framework CoreSQL Database with Entity Framework Core Inbyggd i klientenNative in client ProgrammässigProgrammatic Global per AppDomainGlobal per AppDomain IngetNone
StorageStorage Inbyggd i klientenNative in client ProgrammässigProgrammatic Klientåtgärder och enskilda åtgärderClient and individual operations TraceSourceTraceSource

Anteckning

För de flesta av de inbyggda Azure-metoderna för nya försök finns det för närvarande inget sätt att tillämpa en annan princip för återförsök för olika typer av fel eller undantag.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. Du bör konfigurera en princip som ger optimal genomsnittlig prestanda och tillgänglighet.You should configure a policy that provides the optimum average performance and availability. Ett sätt att finjustera principen är att analysera loggfiler för att fastställa den typ av tillfälliga fel som inträffar.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 är en omfattande molnlösning för identitets- och åtkomsthantering som kombinerar kärnkatalogstjänster, avancerad identitetsstyrning, säkerhet och programåtkomsthantering.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. Azure AD erbjuder dessutom utvecklare en plattform för identitetshantering som ger åtkomstkontroll till deras program, baserat på centraliserade principer och regler.Azure AD also offers developers an identity management platform to deliver access control to their applications, based on centralized policy and rules.

Anteckning

Information om hur du gör om Hanterad tjänstidentitet slut punkter finns i så här använder du en Azure VM-hanterad tjänstidentitet (MSI) för hämtning av token.For retry guidance on Managed Service Identity endpoints, see How to use an Azure VM Managed Service Identity (MSI) for token acquisition.

ÅterförsöksmekanismRetry mechanism

Det finns en inbyggd återförsöksmekanism för Azure Active Directory i ADAL (Active Directory Authentication Library).There is a built-in retry mechanism for Azure Active Directory in the Active Directory Authentication Library (ADAL). För att undvika oväntade utelåsningar rekommenderar vi att bibliotek från tredje part och program kod inte försöker att försöka igen , men tillåter att ADAL hanterar nya försök.To avoid unexpected lockouts, we recommend that third-party libraries and application code do not retry failed connections, but allow ADAL to handle retries.

Vägledning för återförsöksanvändningRetry usage guidance

Tänk på följande när du använder Azure Active Directory:Consider the following guidelines when using Azure Active Directory:

  • När det är möjligt använder du ADAL-biblioteket och det inbyggda stödet för återförsök.When possible, use the ADAL library and the built-in support for retries.
  • Om du använder REST API för Azure Active Directory kan du försöka igen om resultat koden är 429 (för många begär Anden) eller ett fel i 5xx-intervallet.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. Gör inga nya försök för andra fel.Do not retry for any other errors.
  • För 429-fel är det bara att försöka igen efter den tid som anges i huvudet för nytt försök-efter .For 429 errors, only retry after the time indicated in the Retry-After header.
  • För 5xx-fel använder du exponentiella säkerhets kopieringar, med första försök minst 5 sekunder efter svaret.For 5xx errors, use exponential back-off, with the first retry at least 5 seconds after the response.
  • Försök inte igen om andra fel än 429 och 5xx.Do not retry on errors other than 429 and 5xx.

Mer informationMore information

Cosmos DBCosmos DB

Cosmos DB är en fullständigt hanterad databas för flera modeller som stöder schemabaserade JSON-data.Cosmos DB is a fully managed multi-model database that supports schemaless JSON data. Det erbjuder konfigurerbar och pålitlig drift, den har inbyggd transaktionsbehandling med JavaScript och den är byggd för molnet med elastisk skala.It offers configurable and reliable performance, native JavaScript transactional processing, and is built for the cloud with elastic scale.

ÅterförsöksmekanismRetry mechanism

Klassen CosmosClient gör automatiskt om misslyckade försök.The CosmosClient class automatically retries failed attempts. Konfigurera CosmosClientOptionsför att ange antalet återförsök och maximal vänte tid.To set the number of retries and the maximum wait time, configure CosmosClientOptions. Undantag som klienten aktiverar ligger utanför återförsöksprincipen eller är inte tillfälliga fel.Exceptions that the client raises are either beyond the retry policy or are not transient errors. Om Cosmos DB begränsar klienten returneras ett HTTP 429-fel.If Cosmos DB throttles the client, it returns an HTTP 429 error. Kontrol lera status koden i CosmosException klassen.Check the status code in the CosmosException class.

PrincipkonfigurationPolicy configuration

I följande tabell visas standardinställningarna för klassen CosmosClientOptions.The following table shows the default settings for the CosmosClientOptions class.

InställningSetting StandardvärdeDefault value BeskrivningDescription
MaxRetryAttemptsOnRateLimitedRequestsMaxRetryAttemptsOnRateLimitedRequests 99 Det maximala antalet försök om begäran misslyckas för att Cosmos DB tillämpar hastighetsbegränsning på klienten.The maximum number of retries if the request fails because Cosmos DB applied rate limiting on the client.
MaxRetryWaitTimeOnRateLimitedRequestsMaxRetryWaitTimeOnRateLimitedRequests 3030 Den maximala återförsöks tiden i sekunder för Azure Cosmos DB tjänsten.The maximum retry time in seconds for the Azure Cosmos DB service.

ExempelExample

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

TelemetriTelemetry

Försöken loggas som ostrukturerade spårningsmeddelanden genom en .NET TraceSource.Retry attempts are logged as unstructured trace messages through a .NET TraceSource. Du måste konfigurera en TraceListener för att registrera händelserna och skriva dem till en lämplig mållogg.You must configure a TraceListener to capture the events and write them to a suitable destination log.

Om du till exempel lägger till följande i App.config-filen genereras spårningar i en textfil på samma plats som den körbara filen: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 är en inmatnings tjänst för storskalig telemetri som samlar in, transformerar och lagrar miljon tals händelser.Azure Event Hubs is a hyperscale telemetry ingestion service that collects, transforms, and stores millions of events.

ÅterförsöksmekanismRetry mechanism

Återförsöksbeteende i Azure Event Hubs-klientbiblioteket styrs av egenskapen RetryPolicy i klassen EventHubClient.Retry behavior in the Azure Event Hubs Client Library is controlled by the RetryPolicy property on the EventHubClient class. Standardprincipen gör nya försök med exponentiell backoff när Azure Event Hub returnerar ett tillfälligt EventHubsException eller OperationCanceledException.The default policy retries with exponential backoff when Azure Event Hub returns a transient EventHubsException or an OperationCanceledException. Standard principen för återförsök för Event Hubs är att försöka igen med upp till 9 gånger med en exponentiell säkerhets kopierings tid på upp till 30 sekunder.Default retry policy for Event Hubs is to retry up to 9 times with an exponential back-off time of up to 30 seconds .

ExempelExample

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

Mer informationMore information

.NET standard-klient bibliotek för Azure Event Hubs.NET Standard client library for Azure Event Hubs

IoT HubIoT Hub

Azure IoT Hub är en tjänst för att ansluta, övervaka och hantera enheter för att utveckla Sakernas Internet-program (IoT).Azure IoT Hub is a service for connecting, monitoring, and managing devices to develop Internet of Things (IoT) applications.

ÅterförsöksmekanismRetry mechanism

Azure IoT-enhetens SDK kan identifiera fel i nätverket, protokollet eller programmet.The Azure IoT device SDK can detect errors in the network, protocol, or application. Baserat på feltypen kontrollerar SDK om ett återförsök måste utföras.Based on the error type, the SDK checks whether a retry needs to be performed. Om felet kan återställas börjar SDK: n att försöka igen med den konfigurerade principen för återförsök.If the error is recoverable, the SDK begins to retry using the configured retry policy.

Standard principen för återförsök är exponentiella säkerhets kopieringar med slumpmässiga Darr, men den kan konfigureras.The default retry policy is exponential back-off with random jitter, but it can be configured.

PrincipkonfigurationPolicy configuration

Princip konfigurationen skiljer sig från språk.Policy configuration differs by language. Mer information finns i IoT Hub princip konfiguration för återförsök.For more details, see IoT Hub retry policy configuration.

Mer informationMore information

Azure Cache for RedisAzure Cache for Redis

Azure cache för Redis är en snabb data åtkomst och cache-tjänst med låg latens, baserat på den populära Redis-cachen med öppen källkod.Azure Cache for Redis is a fast data access and low latency cache service based on the popular open-source Redis cache. Den är säker, hanteras av Microsoft och går att nå från alla program i Azure.It is secure, managed by Microsoft, and is accessible from any application in Azure.

Vägledningen i det här avsnittet baseras på att StackExchange.Redis-klienten används för åtkomst till cachen.The guidance in this section is based on using the StackExchange.Redis client to access the cache. En lista över passande klienter finns på Redis-webbplatsen och de kan ha olika återförsöksmekanismer.A list of other suitable clients can be found on the Redis website, and these may have different retry mechanisms.

Obs! StackExchange.Redis-klienten använder multiplexering genom en enda anslutning.Note that the StackExchange.Redis client uses multiplexing through a single connection. Den rekommenderade användningen är att skapa en instans av klienten vid programstart och använda denna instans för alla åtgärder mot cachen.The recommended usage is to create an instance of the client at application startup and use this instance for all operations against the cache. Därför görs anslutningen till cachen bara en gång, så alla vägledningar i det här avsnittet är relaterade till principen för återförsök för den här första anslutningen — och inte för varje åtgärd som har åtkomst till cacheminnet.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.

ÅterförsöksmekanismRetry mechanism

StackExchange. Redis-klienten använder en anslutnings hanterare-klass som är konfigurerad via en uppsättning alternativ, inklusive:The StackExchange.Redis client uses a connection manager class that is configured through a set of options, including:

  • ConnectRetry.ConnectRetry. Antalet gånger som nya försök görs att upprätta en anslutning som misslyckats.The number of times a failed connection to the cache will be retried.
  • ReconnectRetryPolicy.ReconnectRetryPolicy. Återförsöksstrategin som ska användas.The retry strategy to use.
  • ConnectTimeout.ConnectTimeout. Maximal väntetid i millisekunder.The maximum waiting time in milliseconds.

PrincipkonfigurationPolicy configuration

Återförsöksprinciper konfigureras programmässigt genom att ange alternativen för klienten innan du ansluter till cachen.Retry policies are configured programmatically by setting the options for the client before connecting to the cache. Detta kan göras genom att skapa en instans av klassen ConfigurationOptions, fylla i dess egenskaper och skicka den till metoden Connect.This can be done by creating an instance of the ConfigurationOptions class, populating its properties, and passing it to the Connect method.

Den inbyggda klasserna stöder linjär (konstant) fördröjning och exponentiell backoff med slumpmässiga återförsöksintervall.The built-in classes support linear (constant) delay and exponential backoff with randomized retry intervals. Du kan också skapa en egen återförsöksprincip genom att implementera gränssnittet IReconnectRetryPolicy.You can also create a custom retry policy by implementing the IReconnectRetryPolicy interface.

I följande exempel konfigureras en återförsöksstrategi med exponentiell backoff.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);

Alternativt kan du ange alternativen som en sträng och skicka den till metoden Connect.Alternatively, you can specify the options as a string, and pass this to the Connect method. Egenskapen ReconnectRetryPolicy kan inte anges på det här sättet, bara via kod.The ReconnectRetryPolicy property cannot be set this way, only through code.

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

Du kan också ange alternativ direkt när du ansluter till cachen.You can also specify options directly when you connect to the cache.

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

Med information finns i Stack Exchange Redis Configuration i StackExchange.Redis-dokumentationen.For more information, see Stack Exchange Redis Configuration in the StackExchange.Redis documentation.

Följande tabell visar standardinställningarna för den inbyggda återförsöksprincipen.The following table shows the default settings for the built-in retry policy.

KontextContext InställningSetting StandardvärdeDefault value
(v 1.2.2)(v 1.2.2)
InnebördMeaning
ConfigurationOptionsConfigurationOptions ConnectRetryConnectRetry

ConnectTimeoutConnectTimeout

SyncTimeoutSyncTimeout

ReconnectRetryPolicyReconnectRetryPolicy
33

Max. 5 000 ms plus SyncTimeoutMaximum 5000 ms plus SyncTimeout
10001000

LinearRetry 5 000 msLinearRetry 5000 ms
Antalet gånger som anslutningsförsöken upprepas under den första anslutningen.The number of times to repeat connect attempts during the initial connection operation.
Timeout (ms) för anslutningsåtgärder.Timeout (ms) for connect operations. Ingen fördröjning mellan försöken.Not a delay between retry attempts.
Tid (ms) som tillåts för synkrona åtgärder.Time (ms) to allow for synchronous operations.

Nytt försök var 5 000 ms.Retry every 5000 ms.

Anteckning

För synkrona åtgärder kan SyncTimeout lägga till svarstiden för slutpunkt till slutpunkt, men ett för lågt värde kan orsaka långa timeouter.For synchronous operations, SyncTimeout can add to the end-to-end latency, but setting the value too low can cause excessive timeouts. Se fel sökning av Azure cache för Redis.See How to troubleshoot Azure Cache for Redis. Allmänt sett bör du undvika synkrona åtgärder och istället använda asynkrona åtgärder.In general, avoid using synchronous operations, and use asynchronous operations instead. Mer information finns i pipelines och multiplexor.For more information, see Pipelines and Multiplexers.

Vägledning för återförsöksanvändningRetry usage guidance

Tänk på följande rikt linjer när du använder Azure cache för Redis:Consider the following guidelines when using Azure Cache for Redis:

  • StackExchange Redis-klienten hanterar sina egna återförsök men bara när en anslutning upprättas till cachen när programmet först startar.The StackExchange Redis client manages its own retries, but only when establishing a connection to the cache when the application first starts. Du kan konfigurera anslutningstimeouten, antalet återförsök och tiden mellan försöken för att upprätta anslutningen men återförsöksprincipen gäller inte för åtgärder mot cachen.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.
  • Istället för att använda ett stort antal försök kan du återgå genom att komma åt den ursprungliga datakällan istället.Instead of using a large number of retry attempts, consider falling back by accessing the original data source instead.

TelemetriTelemetry

Du kan samla in information om anslutningar (men inga andra åtgärder) med en TextWriter.You can collect information about connections (but not other operations) using a TextWriter.

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

Ett exempel på vilka utdata detta genererar visas nedan.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...
...

ExempelExamples

Följande kodexempel konfigurerar en konstant (linjär) fördröjning mellan försök vid initiering av StackExchange.Redis-klienten.The following code example configures a constant (linear) delay between retries when initializing the StackExchange.Redis client. I det här exemplet visas hur du anger konfigurationen med en ConfigurationOptions-instans.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;
                }
            }
        }
    }
}

Nästa exempel anger konfigurationen genom att ange alternativen som en sträng.The next example sets the configuration by specifying the options as a string. Anslutningstimeouten är den maximala väntetiden för en anslutning till cachen, inte fördröjningen mellan försök.The connection timeout is the maximum period of time to wait for a connection to the cache, not the delay between retry attempts. Obs! egenskapen ReconnectRetryPolicy kan bara anges med kod.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;
                }
            }
        }
    }
}

Fler exempel finns i Konfiguration på projektwebbplatsen.For more examples, see Configuration on the project website.

Mer informationMore information

Azure Search kan användas till att lägga till kraftfulla och avancerade sökfunktioner på en webbplats eller i ett program, snabbt och enkelt justera sökresultat och skapa omfattande och finjusterade rankningsmodeller.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.

ÅterförsöksmekanismRetry mechanism

Återförsöksbeteendet i Azure Search SDK styrs av metoden SetRetryPolicy för klasserna SearchServiceClient och SearchIndexClient.Retry behavior in the Azure Search SDK is controlled by the SetRetryPolicy method on the SearchServiceClient and SearchIndexClient classes. Standardprincipen gör försök med exponentiell backoff när Azure Search returnerar svaret 5xx eller 408 (timeout för begäran).The default policy retries with exponential backoff when Azure Search returns a 5xx or 408 (Request Timeout) response.

TelemetriTelemetry

Spåra med ETW eller genom att registrera en anpassad spårningsprovider.Trace with ETW or by registering a custom trace provider. Mer information finns i AutoRest-dokumentationen.For more information, see the AutoRest documentation.

Service BusService Bus

Service Bus är en molnmeddelandeplattform som ger ett löst sammankopplat meddelandeutbyte med förbättrad skala och återhämtning för komponenter för ett program, oavsett om den finns i molnet eller lokalt.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.

ÅterförsöksmekanismRetry mechanism

Service Bus implementerar återförsök med implementeringar av abstrakt RetryPolicy -klassen.Service Bus implements retries using implementations of the abstract RetryPolicy class. Namn området och viss konfigurations information beror på vilket Service Bus klient-SDK-paketet används:The namespace and some of the configuration details depend on which Service Bus client SDK package is used:

PaketPackage BeskrivningDescription NamnområdeNamespace
Microsoft. Azure. Service BusMicrosoft.Azure.ServiceBus Azure Service Bus klient bibliotek för .NET standard.Azure Service Bus client library for .NET Standard. Microsoft.ServiceBus
WindowsAzure. Service BusWindowsAzure.ServiceBus Det här paketet är det äldre Service Bus klient biblioteket.This package is the older Service Bus client library. Den kräver .NET Framework 4.5.2.It requires .Net Framework 4.5.2. Microsoft.Azure.ServiceBus

Båda versionerna av klient biblioteket innehåller följande inbyggda implementeringar av RetryPolicy :Both versions of the client library provide the following built-in implementations of RetryPolicy:

  • RetryExponential.RetryExponential. Implementerar exponentiell backoff.Implements exponential backoff.

  • Noförsök igen.NoRetry. Utför inte återförsök.Does not perform retries. Använd den här klassen när du inte behöver återförsök på Service Bus API-nivå, till exempel när en annan process hanterar återförsök som en del av en grupp eller flera steg-åtgärder.Use this class when you don't need retries at the Service Bus API level, for example when another process manages retries as part of a batch or multistep operation.

RetryPolicy.DefaultEgenskapen returnerar en standard princip av typen RetryExponential .The RetryPolicy.Default property returns a default policy of type RetryExponential. Detta princip objekt har följande inställningar:This policy object has the following settings:

InställningSetting StandardvärdeDefault value InnebördMeaning
MinimalBackoffMinimalBackoff 00 Minsta backoffintervall.Minimum back-off interval. Har lagts till i återförsöksintervall som beräknats från deltaBackoff .Added to the retry interval computed from deltaBackoff.
MaximumBackoffMaximumBackoff 30 sekunder30 seconds Högsta backoffintervall.Maximum back-off interval.
DeltaBackoffDeltaBackoff 3 sekunder3 seconds Backoffintervall mellan återförsök.Back-off interval between retries. Multiplar av detta TimeSpan används för efterföljande återförsök.Multiples of this timespan are used for subsequent retry attempts.
MaxRetryCountMaxRetryCount 55 Max. antal återförsök.The maximum number of retries. (Standardvärdet är 10 i WindowsAzure.ServiceBus paketet.)(Default value is 10 in the WindowsAzure.ServiceBus package.)

Dessutom definieras följande egenskap i det äldre WindowsAzure.ServiceBus paketet:In addition, the following property is defined in the older WindowsAzure.ServiceBus package:

InställningSetting StandardvärdeDefault value InnebördMeaning
TerminationTimeBufferTerminationTimeBuffer 5 sekunder5 seconds Nya försök kommer att överges om den återstående tiden är mindre än det här värdet.Retry attempts will be abandoned if the remaining time is less than this value.

Service Bus åtgärder kan returnera ett intervall med undantag som anges i Service Bus meddelande undantag.Service Bus actions can return a range of exceptions, listed in Service Bus messaging exceptions. Undantag som returneras från Service Bus visar egenskapen IsTransient som anger om klienten ska försöka utföra åtgärden igen.Exceptions returned from Service Bus expose the IsTransient property that indicates whether the client should retry the operation. Den inbyggda RetryExponential -principen kontrollerar den här egenskapen innan den försöker igen.The built-in RetryExponential policy checks this property before retrying.

Om det sista undantaget som påträffades var ServerBusyException, lägger RetryExponential -principen till 10 sekunder till det beräknade intervallet för återförsök.If the last exception encountered was ServerBusyException, the RetryExponential policy adds 10 seconds to the computed retry interval. Värdet kan inte ändras.This value cannot be changed.

Anpassade implementeringar kan använda en kombination av undantags typen och egenskapen IsTransient för att ge mer detaljerad kontroll över återförsöks åtgärder.Custom implementations could use a combination of the exception type and the IsTransient property to provide more fine-grained control over retry actions. Du kan till exempel identifiera ett QuotaExceededException och vidta åtgärd för att tömma kön innan du försöker skicka ett meddelande till den igen.For example, you could detect a QuotaExceededException and take action to drain the queue before retrying sending a message to it.

I följande kod anges principen för återförsök för en Service Bus-klient med hjälp av Microsoft.Azure.ServiceBus biblioteket:The following code sets the retry policy on a Service Bus client using the Microsoft.Azure.ServiceBus library:

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

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

Återförsöksprincipen kan inte anges för enskilda åtgärder.The retry policy cannot be set at the individual operation level. Den gäller för alla åtgärder för-klienten.It applies to all operations for the client.

Vägledning för återförsöksanvändningRetry usage guidance

Tänk på följande när du använder Service Bus:Consider the following guidelines when using Service Bus:

  • När du använder den inbyggda RetryExponential-implementeringen ska du inte implementera en återställningsåtgärd eftersom principen reagerar på undantag för upptagen server och automatiskt byter till ett lämpligt återförsöksläge.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 stöder en funktion som kallas kopplade namn rymder som implementerar automatisk redundans till en säkerhets kopierings kön i ett separat namn område om kön i det primära namn området inte fungerar.Service Bus supports a feature called Paired Namespaces that implements automatic failover to a backup queue in a separate namespace if the queue in the primary namespace fails. Meddelanden från den sekundära kön kan skickas tillbaka till den primära kön när den återställs.Messages from the secondary queue can be sent back to the primary queue when it recovers. Funktionen hjälper till att hantera tillfälliga fel.This feature helps to address transient failures. Mer information finns i Asynkrona meddelandemönster och hög tillgänglighet.For more information, see Asynchronous Messaging Patterns and High Availability.

Överväg att börja med följande inställningar för återförsöksåtgärderna.Consider starting with the following settings for retrying operations. Dessa inställningar är generella och du bör övervaka åtgärderna och finjustera värdena så att de passar ditt eget scenario.These settings are general purpose, and you should monitor the operations and fine-tune the values to suit your own scenario.

KontextContext Exempel på maximal fördröjningExample maximum latency ÅterförsöksprincipRetry policy InställningarSettings Så här fungerar detHow it works
Interaktiv, gränssnitt eller förgrundInteractive, UI, or foreground 2 sekunder*2 seconds* ExponentielltExponential MinimumBackoff = 0MinimumBackoff = 0
MaximumBackoff = 30 sek.MaximumBackoff = 30 sec.
DeltaBackoff = 300 ms.DeltaBackoff = 300 msec.
TimeBuffer = 300 ms.TimeBuffer = 300 msec.
MaxRetryCount = 2MaxRetryCount = 2
Försök 1: 0 sek. fördröjningAttempt 1: Delay 0 sec.
Försök 2: ~300 ms. fördröjningAttempt 2: Delay ~300 msec.
Försök 3: ~900 ms. fördröjningAttempt 3: Delay ~900 msec.
Bakgrund eller batchBackground or batch 30 sekunder30 seconds ExponentielltExponential MinimumBackoff = 1MinimumBackoff = 1
MaximumBackoff = 30 sek.MaximumBackoff = 30 sec.
DeltaBackoff = 1,75 sek.DeltaBackoff = 1.75 sec.
TimeBuffer = 5 sek.TimeBuffer = 5 sec.
MaxRetryCount = 3MaxRetryCount = 3
Försök 1: ~1 sek. fördröjningAttempt 1: Delay ~1 sec.
Försök 2: ~3 sek. fördröjningAttempt 2: Delay ~3 sec.
Försök 3: ~6 ms. fördröjningAttempt 3: Delay ~6 msec.
Försök 4: ~13 ms. fördröjningAttempt 4: Delay ~13 msec.

* Inkluderar inte ytterligare fördröjning som läggs till om ett upptagen server-svar tas emot.* Not including additional delay that is added if a Server Busy response is received.

TelemetriTelemetry

Service Bus loggar återförsök som ETW-händelser med EventSource.Service Bus logs retries as ETW events using an EventSource. Du måste koppla en EventListener till händelsekällan för att registrera händelserna och visa dem i prestandavisningen eller skriva dem till lämplig mållogg.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. Återförsökshändelserna har följande format: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"

ExempelExamples

I följande exempelkod visar hur du anger återförsöksprincipen för:The following code example shows how to set the retry policy for:

  • en namnrymdshanterare.A namespace manager. Principen gäller för alla åtgärder för den hanteraren och kan inte åsidosättas för enskilda åtgärder.The policy applies to all operations on that manager, and cannot be overridden for individual operations.
  • en meddelandefabrik.A messaging factory. Principen gäller för alla klienter som skapats från den fabriken och kan inte åsidosättas när du skapar enskilda klienter.The policy applies to all clients created from that factory, and cannot be overridden when creating individual clients.
  • en enskild meddelandeklient.An individual messaging client. När en klient har skapats kan du ange återförsöksprincipen för den klienten.After a client has been created, you can set the retry policy for that client. Principen gäller för alla åtgärder på den klienten.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();
            }
        }
    }
}

Mer informationMore information

Service FabricService Fabric

Distribution av pålitliga tjänster i ett Service Fabric-kluster skyddar mot de flesta potentiella tillfälliga fel som diskuteras i den här artikeln.Distributing reliable services in a Service Fabric cluster guards against most of the potential transient faults discussed in this article. Men vissa tillfälliga fel är fortfarande möjliga.Some transient faults are still possible, however. Till exempel kan namngivningstjänsten vara mitt i en routningsändring när den får en begäran, vilket gör att den utlöser ett undantag.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. Om samma begäran kommer 100 millisekunder senare lyckas den troligen.If the same request comes 100 milliseconds later, it will probably succeed.

Internt hanterar Service Fabric denna typ av tillfälligt fel.Internally, Service Fabric manages this kind of transient fault. Du kan konfigurera vissa inställningar genom att använda klassen OperationRetrySettings när du konfigurerar dina tjänster.You can configure some settings by using the OperationRetrySettings class while setting up your services. Följande kod visar ett exempel.The following code shows an example. I de flesta fall bör detta inte vara nödvändigt och standardinställningarna räcker.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));

Mer informationMore information

SQL Database med ADO.NETSQL Database using ADO.NET

SQL Database är en värdbaserad SQL-databas som finns i flera olika storlekar och som både standardtjänst (delad) och premiumtjänst (inte delad).SQL Database is a hosted SQL database available in a range of sizes and as both a standard (shared) and premium (non-shared) service.

ÅterförsöksmekanismRetry mechanism

SQL Database har inget inbyggt stöd för återförsök vid åtkomst med ADO.NET.SQL Database has no built-in support for retries when accessed using ADO.NET. Men returkoderna från begäranden kan användas till att fastställa varför en begäran har misslyckats.However, the return codes from requests can be used to determine why a request failed. Mer information om SQL Database-begränsning finns i Resursbegränsningar för Azure SQL Database.For more information about SQL Database throttling, see Azure SQL Database resource limits. En lista med relevanta felkoder finns i SQL-felkoder för SQL Database-klientprogram.For a list of relevant error codes, see SQL error codes for SQL Database client applications.

Du kan använda Polly-biblioteket till att implementera återförsök för SQL Database.You can use the Polly library to implement retries for SQL Database. Se Hantering av tillfälliga fel med Polly.See Transient fault handling with Polly.

Vägledning för återförsöksanvändningRetry usage guidance

Tänk på följande när du använder SQL Database med ADO.NET:Consider the following guidelines when accessing SQL Database using ADO.NET:

  • Välj lämplig tjänst (delad eller premium).Choose the appropriate service option (shared or premium). En delad instans kan drabbas av längre anslutningsfördröjningar än normalt och nätverksbegränsningar på grund av andra klientorganisationers användning av den delade servern.A shared instance may suffer longer than usual connection delays and throttling due to the usage by other tenants of the shared server. Om fler förutsägbara prestanda och tillförlitliga åtgärder med låg latens krävs kan du överväga att använda premiumalternativet.If more predictable performance and reliable low latency operations are required, consider choosing the premium option.
  • Se till att du utför återförsök på rätt nivå eller med rätt omfattning för att undvika icke-idempotenta åtgärder som orsakar inkonsekvenser i data.Ensure that you perform retries at the appropriate level or scope to avoid non-idempotent operations causing inconsistency in the data. I idealfallet ska alla åtgärder vara idempotenta, så att de kan upprepas utan att orsaka inkonsekvens.Ideally, all operations should be idempotent so that they can be repeated without causing inconsistency. Där detta inte är fallet ska återförsöket köras på en nivå eller med en omfattning som tillåter att alla relaterade ändringar kan ångras om en åtgärd misslyckas, till exempel från en transaktionsomfattning.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. Mer information finns i Cloud Service Fundamentals Data Access Layer – Transient Fault Handling (Dataåtkomslager i Cloud Service Fundamentals – hantering av tillfälliga fel).For more information, see Cloud Service Fundamentals Data Access Layer – Transient Fault Handling.
  • En fast intervallstrategi rekommenderas inte för användning med Azure SQL Database, utom för interaktiva scenarier där det bara finns några få återförsök med mycket korta intervall.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. Överväg istället att använda en exponentiell backoff-strategi för majoriteten av scenarierna.Instead, consider using an exponential back-off strategy for the majority of scenarios.
  • Välj ett lämpligt värde för anslutningen och kommandotimeouter när du definierar anslutningar.Choose a suitable value for the connection and command timeouts when defining connections. För kort timeout kan resultera i för tidiga fel i anslutningar när databasen är upptagen.Too short a timeout may result in premature failures of connections when the database is busy. För lång timeout kan förhindra att omprövningslogiken fungerar som den ska genom att vänta för länge innan en felaktig anslutning identifieras.Too long a timeout may prevent the retry logic working correctly by waiting too long before detecting a failed connection. Värdet för timeouten är en komponent i svarstiden slutpunkt till slutpunkt. Den läggs till effektivt till återförsöksfördröjningen sm anges i återförsöksprincipen för varje återförsök.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.
  • Stäng anslutningen efter ett visst antal återförsök, även när du använder en omprövningslogik för exponentiell backoff och försöker med åtgärden igen på en ny anslutning.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. Om du försöker med samma åtgärd flera gånger på samma anslutning kan det vara en faktor som bidrar till anslutningsproblem.Retrying the same operation multiple times on the same connection can be a factor that contributes to connection problems. Ett exempel på den här metoden finns i Cloud Service Fundamentals Data Access Layer – Transient Fault Handling (Dataåtkomslager i Cloud Service Fundamentals – hantering av tillfälliga fel).For an example of this technique, see Cloud Service Fundamentals Data Access Layer – Transient Fault Handling.
  • När anslutningspooler används (standard) finns det en risk att samma anslutning väljs i poolen, även efter att en anslutning har stängts och öppnats på nytt.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. Om så är fallet är en metod att lösa detta att anropa ClearPool-metoden i SqlConnection-klassen för att markera anslutningen som ej återanvändbar.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. Men du bör bara göra detta efter att flera anslutningsförsök har misslyckats och bara när du träffar på den specifika klassen av tillfälliga fel som SQL-timeouter (felkod -2) relaterade till felaktiga anslutningar.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.
  • Om dataåtkomstkoden använder transaktioner som initierats som TransactionScope-instanser bör omprövningslogiken öppna anslutningen igen och initiera en ny transaktionsomfattning.If the data access code uses transactions initiated as TransactionScope instances, the retry logic should reopen the connection and initiate a new transaction scope. Av den anledningen ska det återförsökbara kodblocket inbegripa hela omfattningen för transaktionen.For this reason, the retryable code block should encompass the entire scope of the transaction.

Överväg att börja med följande inställningar för återförsöksåtgärderna.Consider starting with the following settings for retrying operations. Dessa inställningar är generella och du bör övervaka åtgärderna och finjustera värdena så att de passar ditt eget scenario.These settings are general purpose, and you should monitor the operations and fine-tune the values to suit your own scenario.

KontextContext Exempelmål E2E
max. svarstid
Sample target E2E
max latency
ÅterförsöksstrategiRetry strategy InställningarSettings VärdenValues Så här fungerar detHow it works
Interaktiv, gränssnittInteractive, UI,
eller förgrundor foreground
2 sek.2 sec FixedIntervalFixedInterval Antal återförsökRetry count
ÅterförsöksintervallRetry interval
Första snabba återförsöketFirst fast retry
33
500 ms500 ms
truetrue
Försök 1 – 0 sek. fördröjningAttempt 1 - delay 0 sec
Försök 2 – 500 ms fördröjningAttempt 2 - delay 500 ms
Försök 3 – 500 ms fördröjningAttempt 3 - delay 500 ms
BakgrundBackground
eller batchor batch
30 sek.30 sec ExponentialBackoffExponentialBackoff Antal återförsökRetry count
Min. backoffMin back-off
Max. backoffMax back-off
DeltabackoffDelta back-off
Första snabba återförsöketFirst fast retry
55
0 sek.0 sec
60 sek.60 sec
2 sek.2 sec
falsktfalse
Försök 1 – 0 sek. fördröjningAttempt 1 - delay 0 sec
Försök 2 – ~2 sek. fördröjningAttempt 2 - delay ~2 sec
Försök 3 – ~6 sek. fördröjningAttempt 3 - delay ~6 sec
Försök 4 – ~14 sek. fördröjningAttempt 4 - delay ~14 sec
Försök 5 – ~30 sek. fördröjningAttempt 5 - delay ~30 sec

Anteckning

Målen för svarstid slutpunkt till slutpunkt förutsätter standardtimeout för anslutningar till tjänsten.The end-to-end latency targets assume the default timeout for connections to the service. Om du anger längre anslutningstimeouter utökas svarstiden slutpunkt till slutpunkt med denna extra tid för varje återförsök.If you specify longer connection timeouts, the end-to-end latency will be extended by this additional time for every retry attempt.

ExempelExamples

Det här avsnittet visar hur du kan använda Polly för åtkomst till Azure SQL Database med hjälp av en uppsättning återförsöksprinciper som konfigureras i Policy-klassen.This section shows how you can use Polly to access Azure SQL Database using a set of retry policies configured in the Policy class.

Följande kod visar en tilläggsmetod i SqlCommand-klassen som anropar ExecuteAsync med exponentiell backoff.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 200 ms delay.
        onRetry: (exception, attempt) =>
        {
            // Capture some information for logging/telemetry.
            logger.LogWarn($"ExecuteReaderWithRetryAsync: Retry {attempt} due to {exception}.");
        });

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

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

    }, cancellationToken);
}

Den här asynkrona tilläggsmetoden kan användas på följande sätt.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
}

Mer informationMore information

Allmän vägledning om hur du får ut mesta möjliga av SQL Database finns i Översikt över Azure SQL Database prestanda och elastiskhet.For general guidance on getting the most from SQL Database, see Azure SQL Database performance and elasticity guide.

SQL Database att använda Entity Framework 6SQL Database using Entity Framework 6

SQL Database är en värdbaserad SQL-databas som finns i flera olika storlekar och som både standardtjänst (delad) och premiumtjänst (inte delad).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 är en objektrelationell mappningskomponent som gör det möjligt för .NET-utvecklare att arbeta med relationsdata som använder domänspecifika objekt.Entity Framework is an object-relational mapper that enables .NET developers to work with relational data using domain-specific objects. Den eliminerar behovet av det mesta av den dataåtkomstkod som utvecklare normalt måste skriva.It eliminates the need for most of the data-access code that developers usually need to write.

ÅterförsöksmekanismRetry mechanism

Stöd för återförsök ges vid åtkomst till SQL Database med hjälp av Entity Framework 6,0 och högre genom en mekanism som kallas anslutnings återhämtning/omprövnings logik.Retry support is provided when accessing SQL Database using Entity Framework 6.0 and higher through a mechanism called Connection resiliency / retry logic. Återförsöksmekanismens huvudfunktioner är:The main features of the retry mechanism are:

  • Den primära abstraktionen är IDbExecutionStrategy-gränssnittet.The primary abstraction is the IDbExecutionStrategy interface. Gränssnittet gör följande:This interface:
    • Definierar synkrona och asynkrona körnings metoder.Defines synchronous and asynchronous Execute methods.
    • Definierar klasser som kan användas direkt eller kan konfigureras för en databaskontext som en standardstrategi, mappad till ett providernamn eller mappad till ett providernamn och servernamn.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. När återförsök konfigureras för en kontext sker de på nivån för enskilda databasåtgärder, som det kan finnas flera av för en given kontextåtgärd.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.
    • Definierar när och hur återförsök ska göras för en misslyckad anslutning.Defines when to retry a failed connection, and how.
  • Den innehåller flera inbyggda implementeringar av IDbExecutionStrategy-gränssnittet:It includes several built-in implementations of the IDbExecutionStrategy interface:
    • Standard: inget nytt försök.Default: no retrying.
    • Standard för SQL Database (automatisk): inget försök igen, men inspecar av undantag och omsluter dem med förslag att använda SQL Database strategin.Default for SQL Database (automatic): no retrying, but inspects exceptions and wraps them with suggestion to use the SQL Database strategy.
    • Standard för SQL Database: exponentiell (ärvd från Bask Lassen) plus logik för SQL Database identifiering.Default for SQL Database: exponential (inherited from base class) plus SQL Database detection logic.
  • Den implementerar en exponentiell backoff-strategi som inkluderar slumpmässighet.It implements an exponential back-off strategy that includes randomization.
  • De inbyggda återförsöks klasserna är tillstånds känsliga och är inte tråd säkra.The built-in retry classes are stateful and are not thread-safe. Men de kan återanvändas när den aktuella åtgärden har slutförts.However, they can be reused after the current operation is completed.
  • Om det angivna antalet återförsök överskrids omsluts resultatet i ett nytt undantag.If the specified retry count is exceeded, the results are wrapped in a new exception. Den bubblar inte upp det aktuella undantaget.It does not bubble up the current exception.

PrincipkonfigurationPolicy configuration

Funktioner för återförsök ges när SQL Database med Entity Framework 6.0 och senare används.Retry support is provided when accessing SQL Database using Entity Framework 6.0 and higher. Återförsöksprinciper konfigureras programmässigt.Retry policies are configured programmatically. Konfigurationen kan inte ändras på per åtgärd-grund.The configuration cannot be changed on a per-operation basis.

När du konfigurerar en strategi för kontexten som standard anger du en funktion som skapar en ny strategi på begäran.When configuring a strategy on the context as the default, you specify a function that creates a new strategy on demand. Följande kod visar hur du kan skapa en konfigurationsklass för återförsök som utökar DbConfiguration-basklassen.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)));
  }
}

Du kan sedan ange detta som standardstrategin för återförsök för alla åtgärder som använder SetConfiguration-metoden för DbConfiguration-instansen när programmet startas.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. Som standard identifierar EF konfigurationsklassen automatiskt och använder den.By default, EF will automatically discover and use the configuration class.

DbConfiguration.SetConfiguration(new BloggingContextConfiguration());

Du kan ange konfigurationsklassen för återförsök för en kontext genom att kommentera kontextklassen med ett DbConfigurationType-attribut.You can specify the retry configuration class for a context by annotating the context class with a DbConfigurationType attribute. Men om du bara har en konfigurationsklass använder EF den utan att behöva kommentera kontexten.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

Om du behöver använda olika återförsöksstrategier för specifika åtgärder, eller inaktivera återförsök för specifika åtgärder, kan du skapa en konfigurationsklass som gör att du kan inaktivera eller byta strategi genom att ange en flagga i CallContext.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. Konfigurationsklassen kan använda denna flagga till att byta strategi eller inaktivera strategin du anger och använda en standardstrategi.The configuration class can use this flag to switch strategies, or disable the strategy you provide and use a default strategy. Mer information finns i pausa körnings strategi (EF6 och senare).For more information, see Suspend Execution Strategy (EF6 onwards).

En annan metod för användning av specifika återförsöksstrategier för enskilda åtgärder är att skapa en instans av den strategiklass som krävs och ange önskade inställningar genom parametrar.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. Du kan anropa dess ExecuteAsync-metod.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()
);

Det enklaste sättet att använda en DbConfiguration-klass är att hitta den i samma sammansättning som DbContext-klassen.The simplest way to use a DbConfiguration class is to locate it in the same assembly as the DbContext class. Men detta är inte lämpligt när samma kontext krävs i olika scenarier, till exempel olika interaktiva och bakgrundsbaserade återförsöksstrategier.However, this is not appropriate when the same context is required in different scenarios, such as different interactive and background retry strategies. Om olika kontexter körs i separata AppDomains kan du använda det inbyggda stödet för att ange konfigurationsklasser i konfigurationsfilen eller ange den uttryckligen med hjälp av kod.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. Om de olika kontexterna måste köras i samma AppDomain krävs det en anpassad lösning.If the different contexts must execute in the same AppDomain, a custom solution will be required.

Mer information finns i kod baserad konfiguration (EF6 och senare).For more information, see Code-Based Configuration (EF6 onwards).

Följande tabell visar standardinställningarna för den inbyggda återförsöksprincipen vid användning av EF6.The following table shows the default settings for the built-in retry policy when using EF6.

InställningSetting StandardvärdeDefault value InnebördMeaning
PolicyPolicy ExponentielltExponential Exponentiell backoff.Exponential back-off.
MaxRetryCountMaxRetryCount 55 Max. antal återförsök.The maximum number of retries.
MaxDelayMaxDelay 30 sekunder30 seconds Max. fördröjning mellan återförsök.The maximum delay between retries. Värdet påverkar inte hur serien med fördröjningar beräknas.This value does not affect how the series of delays are computed. Det definierar bara en övre gräns.It only defines an upper bound.
DefaultCoefficientDefaultCoefficient 1 sekund1 second Koefficienten för beräkningen av exponentiell backoff.The coefficient for the exponential back-off computation. Värdet kan inte ändras.This value cannot be changed.
DefaultRandomFactorDefaultRandomFactor 1.11.1 Multiplikatorn som används för att lägga till en slumpmässig fördröjning för varje post.The multiplier used to add a random delay for each entry. Värdet kan inte ändras.This value cannot be changed.
DefaultExponentialBaseDefaultExponentialBase 22 Multiplikatorn som används för att beräkna nästa fördröjning.The multiplier used to calculate the next delay. Värdet kan inte ändras.This value cannot be changed.

Vägledning för återförsöksanvändningRetry usage guidance

Tänk på följande när du använder SQL Database med EF6:Consider the following guidelines when accessing SQL Database using EF6:

  • Välj lämplig tjänst (delad eller premium).Choose the appropriate service option (shared or premium). En delad instans kan drabbas av längre anslutningsfördröjningar än normalt och nätverksbegränsningar på grund av andra klientorganisationers användning av den delade servern.A shared instance may suffer longer than usual connection delays and throttling due to the usage by other tenants of the shared server. Om förutsägbara prestanda och tillförlitliga åtgärder med låg latens krävs kan du överväga att använda premiumalternativet.If predictable performance and reliable low latency operations are required, consider choosing the premium option.

  • En fast intervallstrategi rekommenderas inte för användning med Azure SQL Database.A fixed interval strategy is not recommended for use with Azure SQL Database. Använd istället en exponentiell backoff-strategi eftersom tjänsten kan vara överbelastad och längre fördröjningar tillåter mer tid för att den ska återställas.Instead, use an exponential back-off strategy because the service may be overloaded, and longer delays allow more time for it to recover.

  • Välj ett lämpligt värde för anslutningen och kommandotimeouter när du definierar anslutningar.Choose a suitable value for the connection and command timeouts when defining connections. Basera timeouten på din affärslogik och genom testning.Base the timeout on both your business logic design and through testing. Du kanske måste ändra värdet med tiden då datamängden eller affärsprocesserna ändras.You may need to modify this value over time as the volumes of data or the business processes change. För kort timeout kan resultera i för tidiga fel i anslutningar när databasen är upptagen.Too short a timeout may result in premature failures of connections when the database is busy. För lång timeout kan förhindra att omprövningslogiken fungerar som den ska genom att vänta för länge innan en felaktig anslutning identifieras.Too long a timeout may prevent the retry logic working correctly by waiting too long before detecting a failed connection. Värdet av timeouten är en komponent i svarstiden slutpunkt till slutpunkt, men du kan inte på ett enkelt sätt fastställa hur många kommandon som körs när du sparar kontexten.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. Du kan ändra standardtimeouten genom att ange egenskapen CommandTimeout i DbContext-instansen.You can change the default timeout by setting the CommandTimeout property of the DbContext instance.

  • Entity Framework stödjer återförsökskonfigurationer som definieras i konfigurationsfiler.Entity Framework supports retry configurations defined in configuration files. Men för maximal flexibilitet i Azure bör du skapa konfigurationen programmässigt i programmet.However, for maximum flexibility on Azure you should consider creating the configuration programmatically within the application. De specifika parametrarna för återförsöksprinciperna, till exempel antalet återförsök och återförsöksintervall, kan lagras i tjänstekonfigurationsfilen och användas vid körning för att skapa rätt principer.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. Det gör att inställningarna kan ändras utan att programmet behöver startas om.This allows the settings to be changed without requiring the application to be restarted.

Överväg att börja med följande inställningar för återförsöksåtgärderna.Consider starting with the following settings for retrying operations. Du kan inte ange fördröjningen mellan återförsök (den är fast och genereras som en exponentiell sekvens).You cannot specify the delay between retry attempts (it is fixed and generated as an exponential sequence). Du kan bara ange de maxvärden som visas här, om du inte skapar en anpassad återförsöksstrategi.You can specify only the maximum values, as shown here; unless you create a custom retry strategy. Dessa inställningar är generella och du bör övervaka åtgärderna och finjustera värdena så att de passar ditt eget scenario.These settings are general purpose, and you should monitor the operations and fine-tune the values to suit your own scenario.

KontextContext Exempelmål E2E
max. svarstid
Sample target E2E
max latency
ÅterförsöksprincipRetry policy InställningarSettings VärdenValues Så här fungerar detHow it works
Interaktiv, gränssnittInteractive, UI,
eller förgrundor foreground
2 sekunder2 seconds ExponentielltExponential MaxRetryCountMaxRetryCount
MaxDelayMaxDelay
33
750 ms750 ms
Försök 1 – 0 sek. fördröjningAttempt 1 - delay 0 sec
Försök 2 – 750 ms fördröjningAttempt 2 - delay 750 ms
Försök 3 – 750 ms fördröjningAttempt 3 – delay 750 ms
BakgrundBackground
eller batchor batch
30 sekunder30 seconds ExponentielltExponential MaxRetryCountMaxRetryCount
MaxDelayMaxDelay
55
12 sekunder12 seconds
Försök 1 – 0 sek. fördröjningAttempt 1 - delay 0 sec
Försök 2 – ~1 sek. fördröjningAttempt 2 - delay ~1 sec
Försök 3 – ~3 sek. fördröjningAttempt 3 - delay ~3 sec
Försök 4 – ~7 sek. fördröjningAttempt 4 - delay ~7 sec
Försök 5 – 12 sek. fördröjningAttempt 5 - delay 12 sec

Anteckning

Målen för svarstid slutpunkt till slutpunkt förutsätter standardtimeout för anslutningar till tjänsten.The end-to-end latency targets assume the default timeout for connections to the service. Om du anger längre anslutningstimeouter utökas svarstiden slutpunkt till slutpunkt med denna extra tid för varje återförsök.If you specify longer connection timeouts, the end-to-end latency will be extended by this additional time for every retry attempt.

ExempelExamples

I följande kodexempel definieras en enkel dataåtkomstlösning som använder Entity Framework.The following code example defines a simple data access solution that uses Entity Framework. Den anger en specifik återförsöksstrategi genom att definiera en instans av klassen BlogConfiguration som utökar DbConfiguration.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();
            }
        }
    }
}

Fler exempel på hur du kan använda mekanismen för Entity Framework återförsök finns i logik för anslutnings återhämtning/omprövning.More examples of using the Entity Framework retry mechanism can be found in Connection resiliency / retry logic.

Mer informationMore information

SQL Database att använda Entity Framework kärnaSQL Database using Entity Framework Core

Entity Framework Core är en objektrelationell mappningskomponent som gör det möjligt för .NET Core-utvecklare att arbeta med data som använder domänspecifika objekt.Entity Framework Core is an object-relational mapper that enables .NET Core developers to work with data using domain-specific objects. Den eliminerar behovet av det mesta av den dataåtkomstkod som utvecklare normalt måste skriva.It eliminates the need for most of the data-access code that developers usually need to write. Den här versionen av Entity Framework har skrivits från grunden och ärver inte automatiskt alla funktioner från EF6.x.This version of Entity Framework was written from the ground up, and doesn't automatically inherit all the features from EF6.x.

ÅterförsöksmekanismRetry mechanism

Stöd för återförsök ges vid åtkomst till SQL Database med hjälp av Entity Framework Core genom en mekanism som kallas anslutnings återhämtning.Retry support is provided when accessing SQL Database using Entity Framework Core through a mechanism called connection resiliency. Anslutningsåterhämtning introducerades i EF Core 1.1.0.Connection resiliency was introduced in EF Core 1.1.0.

Den primära abstraktionen är IExecutionStrategy-gränssnittet.The primary abstraction is the IExecutionStrategy interface. Körningsstrategin för SQL Server, inklusive SQL Azure, är medveten om undantagstyperna som kan omprövas och har rimliga standardvärden för max. antal återförsök, fördröjning mellan återförsök och så vidare.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.

ExempelExamples

Följande kod möjliggör automatiska återförsök när DbContext-objektet konfigureras, vilket representerar en session med databasen.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=EFMiscellaneous.ConnectionResiliency;Trusted_Connection=True;",
            options => options.EnableRetryOnFailure());
}

Följande kod visar hur du kör en transaktion med automatiska återförsök, genom att använda en körningsstrategi.The following code shows how to execute a transaction with automatic retries, by using an execution strategy. Transaktionen definieras i en delegate.The transaction is defined in a delegate. Om det inträffar ett tillfälligt fel anropar körningsstrategin delegate igen.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 Storage Services inkluderar Blob Storage, filer och lagrings köer.Azure Storage services include blob storage, files, and storage queues.

Blobbar, köer och filerBlobs, Queues and Files

ClientOptions-klassen är bastypen för alla klient alternativ typer och visar olika vanliga klient alternativ som diagnostik, försök igen, transport.The ClientOptions Class is the base type for all client option types and exposes various common client options like Diagnostics, Retry, Transport. För att tillhandahålla klient konfigurations alternativ för att ansluta till Azure Queue, blob och File Storage måste du använda motsvarande härledda typ.To provide the client configuration options for connecting to Azure Queue, Blob, and File Storage you must use the corresponding derived type. I nästa exempel använder du klassen QueueClientOptions (härledd från ClientOptions) för att konfigurera en klient att ansluta till Azure Queue Service.In the next example, you use the QueueClientOptions class (derived from ClientOptions) to configure a client to connect to Azure Queue Service. Egenskapen Retry är den uppsättning alternativ som kan anges för att påverka hur nya försök görs och hur ett fel kan göras.The Retry property is the set of options that can be specified to influence how retry attempts are made, and how a failure is eligible to be retried.

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

namespace RetryCodeSamples
{
    class AzureStorageCodeSamples {

        public async static Task Samples() {

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

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


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

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

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

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

Tabell stödTable Support

Anteckning

WindowsAzure. Storage NuGet-paketet är inaktuellt.WindowsAzure.Storage Nuget Package has been deprecated. Information om stöd för Azure-tabeller finns i Microsoft. Azure. Cosmos. table NuGet-paketFor Azure table support, see Microsoft.Azure.Cosmos.Table Nuget Package

ÅterförsöksmekanismRetry mechanism

Nya försök sker på enskild REST-åtgärdsnivå och är en integrerad del av implementeringen av klient-API.Retries occur at the individual REST operation level and are an integral part of the client API implementation. Klientlagrings-SDK använder klassar som implementerar IExtendedRetryPolicy-gränssnittet.The client storage SDK uses classes that implement the IExtendedRetryPolicy Interface.

De inbyggda klasserna ger stöd för linjär (konstant fördröjning) och exponentiell med slumpmässiga återförsöksintervall.The built-in classes provide support for linear (constant delay) and exponential with randomization retry intervals. Det finns inte heller någon återförsöksprincip när en annan process hanterar återförsök på en högre nivå.There is also a no retry policy for use when another process is handling retries at a higher level. Men du kan implementera dina egna återförsöksklasser om du har specifika krav som inte ges av de inbyggda klasserna.However, you can implement your own retry classes if you have specific requirements not provided by the built-in classes.

Alternativa återförsök växlar mellan primär och sekunder lagringstjänsteplats om du använder geo-redundant lagring med läsåtkomst (RA-GRS) och resultatet av begäran är ett fel där det går att göra ett återförsök.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. Mer information finns i Redundansalternativ för Azure Storage.See Azure Storage Redundancy Options for more information.

PrincipkonfigurationPolicy configuration

Återförsöksprinciper konfigureras programmässigt.Retry policies are configured programmatically. En vanlig metod är att skapa och fylla i en TableRequestOptions-, BlobRequestOptions-, FileRequestOptions- eller QueueRequestOptions-instans.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)
};

Instansen för begäranalternativ kan anges på klienten och alla åtgärder med klienten använder de angivna begäran alternativen.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();

Du kan åsidosätta klientbegäranalternativen genom att överföra en ifylld instans med klassen för begäranalternativ som en parameter till åtgärdsmetoder.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);

Du kan använda en OperationContext-instans till att ange koden som körs när ett återförsök inträffar och när en åtgärd har slutförts.You use an OperationContext instance to specify the code to execute when a retry occurs and when an operation has completed. Denna kod kan samla in information om åtgärden för användning i loggar och telemetri.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);

Utöver att ange om det är lämpligt att försöka igen vid ett fel returnerar de utökade återförsksprinciperna ett RetryContext-objekt som indikerar antalet återförsök, resultatet av den senaste begäran, om nästa återförsök sker på den primära eller sekundära platsen (se tabellen nedan för information).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). Egenskaperna för RetryContext-objektet kan användas för att fastställa om och när det ska göras ett nytt försök.The properties of the RetryContext object can be used to decide if and when to attempt a retry. Mer information finns i metoden IExtendedRetryPolicy. evaluate.For more information, see IExtendedRetryPolicy.Evaluate Method.

I följande tabell visas standardinställningarna för de inbyggda återförsöksprinciperna.The following tables show the default settings for the built-in retry policies.

Alternativ för begäran:Request options:

InställningSetting StandardvärdeDefault value InnebördMeaning
MaximumExecutionTimeMaximumExecutionTime IngetNone Maximal körningstid för begäran, inklusive alla potentiella återförsök.Maximum execution time for the request, including all potential retry attempts. Om den inte anges är den tid som en begäran tillåts att ta, obegränsad.If it is not specified, then the amount of time that a request is permitted to take is unlimited. Med andra ord kan begäran sluta svara.In other words, the request might stop responding.
ServerTimeoutServerTimeout IngetNone Servertimeoutintervall för begäran (värdet avrundas till sekunder).Server timeout interval for the request (value is rounded to seconds). Om det inte anges används standardvärdet för alla begäranden till servern.If not specified, it will use the default value for all requests to the server. Normalt är det bästa alternativet att utelämna den här inställningen så att serverstandardvärdet används.Usually, the best option is to omit this setting so that the server default is used.
LocationModeLocationMode IngetNone Om lagringskontot används med RA-GRS-replikeringsalternativet kan du används platsläget för att ange vilken plats som ska ta emot begäran.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. Om till exempel PrimaryThenSecondary anges skickas begäranden alltid till den primära platsen först.For example, if PrimaryThenSecondary is specified, requests are always sent to the primary location first. Om en begäran misslyckas skickas den till den sekundära platsen.If a request fails, it is sent to the secondary location.
RetryPolicyRetryPolicy ExponentialPolicyExponentialPolicy Se nedan för information om varje alternativ.See below for details of each option.

Exponentiell princip:Exponential policy:

InställningSetting StandardvärdeDefault value InnebördMeaning
maxAttemptmaxAttempt 33 Antal återförsök.Number of retry attempts.
deltaBackoffdeltaBackoff 4 sekunder4 seconds Backoffintervall mellan återförsök.Back-off interval between retries. Multiplar för den här tiden, inklusive ett slumpmässigt element, används för efterföljande återförsök.Multiples of this timespan, including a random element, will be used for subsequent retry attempts.
MinBackoffMinBackoff 3 sekunder3 seconds Läggs till i alla återförsöksinterval som beräknas från deltaBackoff.Added to all retry intervals computed from deltaBackoff. Värdet kan inte ändras.This value cannot be changed.
MaxBackoffMaxBackoff 120 sekunder120 seconds MaxBackoff används om det beräknade återförsöksintervallet är större än MaxBackoff.MaxBackoff is used if the computed retry interval is greater than MaxBackoff. Värdet kan inte ändras.This value cannot be changed.

Linjär princip:Linear policy:

InställningSetting StandardvärdeDefault value InnebördMeaning
maxAttemptmaxAttempt 33 Antal återförsök.Number of retry attempts.
deltaBackoffdeltaBackoff 30 sekunder30 seconds Backoffintervall mellan återförsök.Back-off interval between retries.

Vägledning för återförsöksanvändningRetry usage guidance

Tänk på följande rekommendationer vid användning av Azure Storage-tjänster med lagringsklient-API:Consider the following guidelines when accessing Azure storage services using the storage client API:

  • Använd de inbyggda principerna för återförsök från Microsoft. Azure. Storage. RetryPolicies-namnrymden där de passar dina behov.Use the built-in retry policies from the Microsoft.Azure.Storage.RetryPolicies namespace where they are appropriate for your requirements. I de flesta fall är dessa principer tillräckliga.In most cases, these policies will be sufficient.

  • Använd ExponentialRetry-principen i batchåtgärder, bakgrundsuppgifter eller icke-interaktiva scenarier.Use the ExponentialRetry policy in batch operations, background tasks, or non-interactive scenarios. I dessa scenarier kan du vanligt vis få mer tid för tjänsten att återställa — med en ökad chans att åtgärden lyckas.In these scenarios, you can typically allow more time for the service to recover—with a consequently increased chance of the operation eventually succeeding.

  • Överväg att ange egenskapen MaximumExecutionTime för parametern RequestOptions för att begränsa den totala körningstiden men ta hänsyn till åtgärdens typ och storlek när du väljer ett timeoutvärde.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.

  • Om du behöver implementera ett anpassat återförsök ska du undvika att skapa omslutningar kring lagringsklientklasserna.If you need to implement a custom retry, avoid creating wrappers around the storage client classes. Använd istället funktionerna för att utöka de befintliga principerna genom IExtendedRetryPolicy-gränssnittet.Instead, use the capabilities to extend the existing policies through the IExtendedRetryPolicy interface.

  • Om du använder RA-GRS kan du använda LocationMode till att ange att återförsöken kommer åt den sekundära skrivskyddade kopian av lagret om den primära åtkomsten misslyckas.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. Men när du använder det här alternativet måste du se till att programmet kan fungerar med data som kan vara inaktuella om replikeringen från det primära lagret inte har slutförts än.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.

Överväg att börja med följande inställningar för återförsöksåtgärderna.Consider starting with the following settings for retrying operations. Dessa inställningar är generella och du bör övervaka åtgärderna och finjustera värdena så att de passar ditt eget scenario.These settings are general purpose, and you should monitor the operations and fine-tune the values to suit your own scenario.

KontextContext Exempelmål E2E
max. svarstid
Sample target E2E
max latency
ÅterförsöksprincipRetry policy InställningarSettings VärdenValues Så här fungerar detHow it works
Interaktiv, gränssnittInteractive, UI,
eller förgrundor foreground
2 sekunder2 seconds LinjärLinear maxAttemptmaxAttempt
deltaBackoffdeltaBackoff
33
500 ms500 ms
Försök 1 – 500 ms fördröjningAttempt 1 - delay 500 ms
Försök 2 – 500 ms fördröjningAttempt 2 - delay 500 ms
Försök 3 – 500 ms fördröjningAttempt 3 - delay 500 ms
BakgrundBackground
eller batchor batch
30 sekunder30 seconds ExponentielltExponential maxAttemptmaxAttempt
deltaBackoffdeltaBackoff
55
4 sekunder4 seconds
Försök 1 – ~3 sek. fördröjningAttempt 1 - delay ~3 sec
Försök 2 – ~7 sek. fördröjningAttempt 2 - delay ~7 sec
Försök 3 – ~15 sek. fördröjningAttempt 3 - delay ~15 sec

TelemetriTelemetry

Återförsök loggas i ett TraceSource.Retry attempts are logged to a TraceSource. Du måste konfigurera en TraceListener för att registrera händelserna och skriva dem till en lämplig mållogg.You must configure a TraceListener to capture the events and write them to a suitable destination log. Du kan använda TextWriterTraceListener eller XmlWriterTraceListener för att skriva data till en loggfil, EventLogTraceListener för att skriva till händelseloggen för Windows eller EventProviderTraceListener för att skriva spårningsdata till ETW-undersystemet.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. Du kan också konfigurera autorensning av bufferten och utförligheten för händelser som ska loggas (till exempel fel, varning, information och utförligt).You can also configure autoflushing of the buffer, and the verbosity of events that will be logged (for example, Error, Warning, Informational, and Verbose). Mer information finns i artikeln om klientloggning med .NET Storage Client Library.For more information, see Client-side Logging with the .NET Storage Client Library.

Åtgärder kan ta emot en OperationContext-instans, som visar en Retrying-händelse som kan användas till att koppla anpassad telemetrilogik.Operations can receive an OperationContext instance, which exposes a Retrying event that can be used to attach custom telemetry logic. Mer information finns i OperationContext.Retrying Event.For more information, see OperationContext.Retrying Event.

ExempelExamples

Följande kodexempel visar hur du skapar två TableRequestOptions-instanser med olika återförsöksinställningar, en för interaktiva begäranden och en för bakgrundsbegäranden.The following code example shows how to create two TableRequestOptions instances with different retry settings; one for interactive requests and one for background requests. Exemplet anger sedan dessa två återförsöksprinciper så att de gäller för alla begäranden, och anger även den interaktiva strategin för en specifik begäran så att den åsidosätter standardinställningen som tillämpas på klienten.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.Azure.Cosmos.Table;

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

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

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

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

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

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

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

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

Mer informationMore information

Allmänna riktlinjer för REST och återförsökGeneral REST and retry guidelines

Tänk på följande när du använder Azure eller tjänster från tredje part:Consider the following when accessing Azure or third-party services:

  • Hantera återförsök systematiskt, kanske som återanvändbar kod, så att du kan tillämpa konsekventa metoder för alla klienter och lösningar.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.

  • Överväg att använda ett ramverk för återförsök, till exempel Polly , för att hantera återförsök om mål tjänsten eller klienten inte har någon inbyggd försöks funktion.Consider using a retry framework such as Polly to manage retries if the target service or client has no built-in retry mechanism. Det hjälper dig att implementera en konsekvent återförsöksbeteende och det kan ge en lämplig standardstrategi för återförsök för måltjänsten.This will help you implement a consistent retry behavior, and it may provide a suitable default retry strategy for the target service. Du kan dock behöva skapa en anpassad kod för återförsök för tjänster som har icke-standarduppföranden, som inte förlitar sig på undantag för att indikera tillfälliga fel eller om du vill använda ett svars svar för att hantera återförsök.However, you may need to create custom retry code for services that have nonstandard 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.

  • Den tillfälliga identifieringslogiken är beroende av det faktiska klient-API:et som du kan anropa REST-anropen med.The transient detection logic will depend on the actual client API you use to invoke the REST calls. Vissa klienter, till exempel den nyare HttpClient-klassen utlöser inte undantag för slutförda begäranden med en HTTP-statuskod för misslyckad åtgärd.Some clients, such as the newer HttpClient class, will not throw exceptions for completed requests with a non-success HTTP status code.

  • HTTP-statuskoden som returneras från tjänsten kan hjälpa till att ange om felet är tillfälligt.The HTTP status code returned from the service can help to indicate whether the failure is transient. Du kan behöva undersöka undantagen som genereras av en klient eller återförsöksramverket för att komma åt statuskoden eller för att fastställa motsvarande undantagstyp.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. Följande HTTP-koder anger vanligtivs att ett nytt försök är lämpligt:The following HTTP codes typically indicate that a retry is appropriate:

    • 408 Timeout för begäran408 Request Timeout
    • 429 För många förfrågningar429 Too Many Requests
    • 500 internt serverfel500 Internal Server Error
    • 502 Felaktig gateway502 Bad Gateway
    • 503 Tjänsten är inte tillgänglig503 Service Unavailable
    • 504 Gateway-timeout504 Gateway Timeout
  • Om du baserar omprövningslogiken på undantag anger följande vanligtvis ett tillfälligt fel när det inte har gått att upprätta en anslutning: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
  • När det gäller statusen för otillgänglig tjänst kan tjänsten ange lämplig fördröjning innan nytt försök görs i svarshuvudet Retry-After eller ett annat anpassat huvud.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. Tjänster kan även skicka ytterligare information som anpassade huvuden eller inbäddad i svarets innehåll.Services might also send additional information as custom headers, or embedded in the content of the response.

  • Försök inte igen för status koder som representerar klient fel (fel i 4xx-intervallet), förutom en tids gräns för 408-begäran och 429 för många begär Anden.Do not retry for status codes representing client errors (errors in the 4xx range) except for a 408 Request Timeout and 429 Too Many Requests.

  • Testa dina återförsöksstrategier och -mekanismer noga i olika förhållanden, till exempel olika nätverkstillstånd och systembelastningar.Thoroughly test your retry strategies and mechanisms under a range of conditions, such as different network states and varying system loadings.

ÅterförsöksstrategierRetry strategies

Följande är vanliga typer av intervall för återförsstrategier:The following are the typical types of retry strategy intervals:

  • Exponentiellt.Exponential. En princip för återförsök som utför ett visst antal återförsök, med en slumpmässig exponentiell metod för att fastställa intervallet mellan återförsök.A retry policy that performs a specified number of retries, using a randomized exponential back off approach to determine the interval between retries. Exempel: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);
    
  • Stegvis.Incremental. En strategi för återförsök med ett angivet antal återförsök och ett stegvis tidsintervall mellan återförsök.A retry strategy with a specified number of retry attempts and an incremental time interval between retries. Exempel:For example:

    retryInterval = TimeSpan.FromMilliseconds(this.initialInterval.TotalMilliseconds +
                    (this.increment.TotalMilliseconds * currentRetryCount));
    
  • LinearRetry.LinearRetry. En princip för återförsök som utför ett angivet antal återförsök med ett angivet fast tidsintervall mellan återförsök.A retry policy that performs a specified number of retries, using a specified fixed time interval between retries. Exempel:For example:

    retryInterval = this.deltaBackoff;
    

Hantering av tillfälliga fel med PollyTransient fault handling with Polly

Polly är ett bibliotek för program mässig hantering av försök och krets brytar strategier.Polly is a library to programmatically handle retries and circuit breaker strategies. Polly-projektet är en medlem i .NET Foundation.The Polly project is a member of the .NET Foundation. För tjänster där klienten inte stöder återförsök internt är Polly ett bra alternativ där du kan undvika att skriva anpassad återförsökskod, vilket kan vara svårt att implementera på rätt sätt.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. Med Polly kan du också spåra fel när de inträffar, så att du kan logga återförsök.Polly also provides a way to trace errors when they occur, so that you can log retries.

Mer informationMore information