Återförsöksvägledning för Azure-tjänster

  • Artikel

De flesta Azure-tjänster och klient-SDK:er har en återförsöksmekanism. Med dessa skiljer sig eftersom varje tjänst har olika egenskaper, så varje återförsöksmekanism justeras efter en specifik tjänst. Den här guiden sammanfattar funktionerna för återförsöksmekanismer för de flesta Azure-tjänster och innehåller information som hjälper dig att använda, anpassa eller utöka mekanismen för återförsök för den tjänsten.

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.

I följande tabell sammanfattas återförsöksfunktionerna för de Azure-tjänster som beskriva i den här vägledningen.

Tjänst Återförsöksfunktioner Principkonfiguration Definitionsområde Telemetrifunktioner
Microsoft Entra ID Inbyggt i MSAL-biblioteket Inbäddat i MSAL-biblioteket Internt Ingen
Azure Cosmos DB Inbyggd i tjänsten Inte konfigurerbar Global TraceSource
Data Lake Store Inbyggd i klienten Inte konfigurerbar Enskilda åtgärder Ingen
Event Hubs Inbyggd i klienten Programmässig Klient Ingen
IoT Hub Inbyggt i klient-SDK Programmässig Klient Ingen
Azure Cache for Redis Inbyggd i klienten Programmässig Klient TextWriter
Sök Inbyggd i klienten Programmässig Klient Händelsespårning för Windows (ETW) eller anpassad
Service Bus Inbyggd i klienten Programmässig Namespace Manager, Messaging Factory och Client ETW
Service Fabric Inbyggd i klienten Programmässig Klient Ingen
SQL Database med ADO.NET Polly Deklarativ och programmässig Enskilda instruktioner eller kodblock Anpassat
SQL Database med Entity Framework Inbyggd i klienten Programmässig Global per AppDomain Ingen
SQL Database med Entity Framework Core Inbyggd i klienten Programmässig Global per AppDomain Ingen
Storage Inbyggd i klienten Programmässig Klientåtgärder och enskilda åtgärder TraceSource

Kommentar

För de flesta inbyggda Mekanismer för återförsök i Azure finns det för närvarande inget sätt att tillämpa en annan återförsöksprincip för olika typer av fel eller undantag. Du bör konfigurera en princip som ger optimal genomsnittlig prestanda och tillgänglighet. Ett sätt att finjustera principen är att analysera loggfiler för att fastställa den typ av tillfälliga fel som inträffar.

Microsoft Entra ID

Microsoft Entra ID är en omfattande molnlösning för identitets- och åtkomsthantering som kombinerar kärnkatalogtjänster, avancerad identitetsstyrning, säkerhet och åtkomsthantering för program. Microsoft Entra ID erbjuder också utvecklare en identitetshanteringsplattform för att leverera åtkomstkontroll till sina program, baserat på centraliserade principer och regler.

Kommentar

Mer information om slutpunkter för hanterad tjänstidentitet finns i Så här använder du en hanterad tjänstidentitet för virtuella Azure-datorer (MSI) för tokenförvärv.

Återförsöksmekanism

Det finns en inbyggd mekanism för återförsök för Microsoft Entra-ID i Microsoft Authentication Library (MSAL). För att undvika oväntade utelåsningar rekommenderar vi att bibliotek från tredje part och programkod inte försöker igen misslyckade anslutningar, men tillåter MSAL att hantera återförsök.

Vägledning för återförsöksanvändning

Tänk på följande riktlinjer när du använder Microsoft Entra-ID:

  • När det är möjligt använder du MSAL-biblioteket och det inbyggda stödet för återförsök.
  • Om du använder REST-API:et för Microsoft Entra-ID försöker du igen om resultatkoden är 429 (för många begäranden) eller ett fel i 5xx-intervallet. Försök inte igen för andra fel.
  • För 429-fel försöker du bara igen efter den tid som anges i återförsökshuvudet .
  • För 5xx-fel använder du exponentiell säkerhetskopiering, med det första återförsöket minst 5 sekunder efter svaret.
  • Försök inte igen vid andra fel än 429 och 5xx.

Nästa steg

Azure Cosmos DB

Azure Cosmos DB är en fullständigt hanterad databas med flera modeller som stöder schemalösa 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.

Återförsöksmekanism

Azure Cosmos DB SDK:er försöker automatiskt igen under vissa felvillkor, och användarprogram uppmanas att ha egna återförsöksprinciper. Se guiden för att utforma elastiska program med Azure Cosmos DB SDK:er för en fullständig lista över feltillstånd och när du ska försöka igen.

Telemetri

Beroende på programmets språk exponeras diagnostik och telemetri som loggar eller framhävda egenskaper för åtgärdssvaren. Mer information finns i avsnittet "Avbilda diagnostiken" i Azure Cosmos DB C# SDK och Azure Cosmos DB Java SDK.

Data Lake Store

Data Lake Storage Gen2 gör Azure Storage till grunden för att skapa företagsdatasjöar i Azure. Med Data Lake Storage Gen2 kan du enkelt hantera enorma mängder data.

Azure Storage Files Data Lake-klientbiblioteket innehåller alla funktioner som krävs för att göra det enkelt för utvecklare, dataforskare och analytiker att lagra data av valfri storlek, form och hastighet och utföra alla typer av bearbetning och analys på plattformar och språk.

Återförsöksmekanism

Med DataLakeServiceClient kan du manipulera Azure Data Lake-tjänstresurser och filsystem. Lagringskontot tillhandahåller namnområdet på den översta nivån för Data Lake-tjänsten. När du skapar klienten kan du ange klientkonfigurationsalternativen för att ansluta till Azure Data Lake-tjänsten (DataLakeClientOptions). DataLakeClientOptions innehåller en återförsöksegenskap (ärvd från Azure.Core.ClientOptions) som kan konfigureras (klassen RetryOptions).

Telemetri

Att övervaka användning och prestanda för Azure Storage är en viktig del i driftsättningen av tjänsten. Exempel är frekventa åtgärder, åtgärder med hög svarstid eller åtgärder som orsakar begränsning på tjänstsidan.

All telemetri för ditt lagringskonto är tillgänglig via Azure Storage-loggar i Azure Monitor. Den här funktionen integrerar ditt lagringskonto med Log Analytics och Event Hubs, samtidigt som du kan arkivera loggar till ett annat lagringskonto. En fullständig lista över mått och resursloggar och deras associerade schema finns i Referens för Azure Storage-övervakningsdata.

Event Hubs

Azure Event Hubs är en telemetriinmatningstjänst för hyperskala som samlar in, transformerar och lagrar miljontals händelser.

Återförsöksmekanism

Återförsöksbeteende i Azure Event Hubs-klientbiblioteket styrs av egenskapen RetryPolicy i klassen EventHubClient. Standardprincipen återförsök med exponentiell backoff när Azure Event Hubs returnerar en tillfällig EventHubsException eller en OperationCanceledException. Standardprincipen för återförsök för Event Hubs är att försöka igen upp till 9 gånger med en exponentiell säkerhetskopieringstid på upp till 30 sekunder.

Exempel

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

Nästa steg

Azure Event Hubs-klientbibliotek för .NET

IoT Hub

Azure IoT Hub är en tjänst för att ansluta, övervaka och hantera enheter för att utveckla IoT-program (Internet of Things).

Återförsöksmekanism

Azure IoT-enhetens SDK kan identifiera fel i nätverket, protokollet eller programmet. Baserat på feltypen kontrollerar SDK:et om ett nytt försök måste utföras. Om felet kan återställas börjar SDK:et försöka igen med hjälp av den konfigurerade återförsöksprincipen.

Standardprincipen för återförsök är exponentiell säkerhetskopiering med slumpmässig jitter, men den kan konfigureras.

Konfiguration av princip

Principkonfigurationen skiljer sig åt beroende på språk. Mer information finns i Principkonfiguration för återförsök av IoT Hub.

Nästa steg

Azure Cache for Redis

Azure Cache for Redis är en snabb dataåtkomst och cachetjänst med låg svarstid baserat på den populära Redis-cachen med öppen källkod. Den är säker, hanteras av Microsoft och är tillgänglig från alla program i Azure.

Vägledningen i det här avsnittet baseras på att StackExchange.Redis-klienten används för åtkomst till cachen. En lista över passande klienter finns på Redis-webbplatsen och de kan ha olika återförsöksmekanismer.

StackExchange.Redis-klienten använder multiplexering via en enda anslutning. 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. Av den anledningen görs anslutningen till cachen bara en gång, så alla råd i det här avsnittet är relaterade till återförsöksprincipen för denna första anslutningen – och inte för varje åtgärd som använder cachen.

Återförsöksmekanism

StackExchange.Redis-klienten använder en anslutningshanterare-klass som konfigureras via en uppsättning alternativ, inklusive:

  • ConnectRetry. Antalet gånger som nya försök görs att upprätta en anslutning som misslyckats.
  • ReconnectRetryPolicy. Återförsöksstrategin som ska användas.
  • ConnectTimeout. Maximal väntetid i millisekunder.

Konfiguration av princip

Återförsöksprinciper konfigureras programmässigt genom att ange alternativen för klienten innan du ansluter till cachen. Detta kan göras genom att skapa en instans av klassen ConfigurationOptions, fylla i dess egenskaper och skicka den till metoden Connect.

Den inbyggda klasserna stöder linjär (konstant) fördröjning och exponentiell backoff med slumpmässiga återförsöksintervall. Du kan också skapa en egen återförsöksprincip genom att implementera gränssnittet IReconnectRetryPolicy.

I följande exempel konfigureras en återförsöksstrategi med exponentiell backoff.

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

Alternativt kan du ange alternativen som en sträng och skicka den till metoden Connect. Egenskapen ReconnectRetryPolicy kan inte anges på det här sättet, bara via kod.

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.

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

Med information finns i Stack Exchange Redis Configuration i StackExchange.Redis-dokumentationen.

Följande tabell visar standardinställningarna för den inbyggda återförsöksprincipen.

Kontext Inställning Standardvärde
(v 1.2.2)		 Betydelse
ConfigurationOptions ConnectRetry

ConnectTimeout

SyncTimeout

ReconnectRetryPolicy		 3

Max. 5 000 ms plus SyncTimeout
1000

LinearRetry 5 000 ms		 Antalet gånger som anslutningsförsöken upprepas under den första anslutningen.
Timeout (ms) för anslutningsåtgärder. Ingen fördröjning mellan försöken.
Tid (ms) som tillåts för synkrona åtgärder.

Nytt försök var 5 000 ms.

Kommentar

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. Mer information finns i Felsöka Azure Cache for Redis. Allmänt sett bör du undvika synkrona åtgärder och istället använda asynkrona åtgärder. Mer information finns i Pipelines och Multiplexers.

Vägledning för återförsöksanvändning

Tänk på följande riktlinjer när du använder 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. Du kan konfigurera tidsgränsen för anslutningen, antalet återförsök och tiden mellan återförsök för att upprätta anslutningen, men återförsöksprincipen gäller inte för åtgärder mot cacheminnet.
  • 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.

Telemetri

Du kan samla in information om anslutningar (men inga andra åtgärder) med en TextWriter.

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

Ett exempel på vilka utdata detta genererar visas nedan.

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

Exempel

Följande kodexempel konfigurerar en konstant (linjär) fördröjning mellan försök vid initiering av StackExchange.Redis-klienten. I det här exemplet visas hur du anger konfigurationen med en ConfigurationOptions-instans.

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

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

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

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

Nästa exempel anger konfigurationen genom att ange alternativen som en sträng. Anslutningstimeouten är den maximala väntetiden för en anslutning till cachen, inte fördröjningen mellan försök. Egenskapen ReconnectRetryPolicy kan bara anges med kod.

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.

Nästa steg

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.

Återförsöksmekanism

Azure SDK för .NET innehåller ett Azure.Search.Documents-klientbibliotek från Azure SDK-teamet som är funktionellt likvärdigt med det tidigare klientbiblioteket, Microsoft.Azure.Search.

Återförsöksbeteendet i Microsoft.Azure.Search styrs av metoden SetRetryPolicy i klasserna SearchServiceClient och SearchIndexClient. Standardprincipen gör försök med exponentiell backoff när Azure Search returnerar svaret 5xx eller 408 (timeout för begäran).

Beteende för återförsök i Azure.Search.Documents styrs av SearchClientOptions (det är en del av SearchClient-konstruktorn) i egenskapen Försök igen, som tillhör klassen Azure.Core.RetryOptions (där alla konfigurationer är tillgängliga).

Telemetri

Spåra med ETW eller genom att registrera en anpassad spårningsprovider. Mer information finns i AutoRest-dokumentationen.

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

Återförsöksmekanism

Namnområdet och några av konfigurationsinformationen beror på vilket Service Bus-klient-SDK-paket som används:

Paket beskrivning Namnområde
Azure.Messaging.ServiceBus Azure Service Bus-klientbibliotek för .NET Azure.Messaging.ServiceBus
WindowsAzure.ServiceBus Det här paketet är det äldre Service Bus-klientbiblioteket. Det kräver .NET Framework 4.5.2. Microsoft.Azure.ServiceBus

Vägledning för återförsöksanvändning

Egenskapen ServiceBusRetryOptions anger återförsöksalternativen ServiceBusClient för objektet:

Inställning Standardvärde Innebörd
CustomRetryPolicy En anpassad återförsöksprincip som ska användas i stället för de enskilda alternativvärdena.
Försening 0,8 sekunder Fördröjningen mellan återförsöksförsök för en fast metod eller den fördröjning som en backoff-baserad metod ska basera beräkningar på.
MaxDelay 60 sekunder Den maximala tillåtna fördröjningen mellan återförsök.
MaxRetries 3 Det maximala antalet återförsök innan du överväger att den associerade åtgärden ska ha misslyckats.
Läge Exponentiellt Den metod som ska användas för att beräkna fördröjningar av återförsök.
TryTimeout 60 sekunder Den maximala varaktigheten för att vänta tills ett enda försök har slutförts, oavsett om det första försöket eller ett nytt försök görs.

Ange egenskapen Mode för att konfigurera ServiceBusRetryMode med något av följande värden:

Property Värde beskrivning
Exponentiellt 1 Återförsök fördröjs baserat på en backoff-strategi, där varje försök ökar den varaktighet som väntar innan ett nytt försök görs.
Åtgärdat 0 Försök igen sker med fasta intervall. varje fördröjning är en konsekvent varaktighet.

Exempel:

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

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

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

Telemetri

Service Bus samlar in samma typer av övervakningsdata som andra Azure-resurser. Du kan övervaka Azure Service Bus med hjälp av Azure Monitor.

Du har också olika alternativ för att skicka telemetri med Service Bus .NET-klientbiblioteken.

Exempel

Följande kodexempel visar hur du Azure.Messaging.ServiceBus använder paketet för att:

  • Ange återförsöksprincipen för en ServiceBusClient med hjälp av en ny ServiceBusClientOptions.
  • Skapa ett nytt meddelande med en ny instans av en ServiceBusMessage.
  • Skicka ett meddelande till Service Bus med hjälp av ServiceBusSender.SendMessageAsync(message) metoden .
  • Ta emot med hjälp av ServiceBusReceiver, som representeras som ServiceBusReceivedMessage objekt.
using Azure.Identity;
using Azure.Messaging.ServiceBus;

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

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

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

await sender.SendMessageAsync(message);

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

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

Nästa steg

Service 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. Men vissa tillfälliga fel är fortfarande möjliga. 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. Om samma begäran kommer 100 millisekunder senare lyckas den troligen.

Internt hanterar Service Fabric denna typ av tillfälligt fel. Du kan konfigurera vissa inställningar genom att använda klassen OperationRetrySettings när du konfigurerar dina tjänster. Följande kod visar ett exempel. I de flesta fall bör detta inte vara nödvändigt, och standardinställningarna kommer att vara bra.

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

Nästa steg

SQL Database med ADO.NET

SQL Database är en värdbaserad SQL Database som är tillgänglig i olika storlekar och som både en standardtjänst (delad) och premiumtjänst (ej delad).

Återförsöksmekanism

SQL Database har inget inbyggt stöd för återförsök vid åtkomst med ADO.NET. Men returkoderna från begäranden kan användas till att fastställa varför en begäran har misslyckats. Mer information om SQL Database-begränsning finns i Resursbegränsningar för Azure SQL Database. En lista med relevanta felkoder finns i SQL-felkoder för SQL Database-klientprogram.

Du kan använda Polly-biblioteket till att implementera återförsök för SQL Database. Mer information finns i Tillfälliga felhantering med Polly.

Vägledning för återförsöksanvändning

Tänk på följande när du använder SQL Database med ADO.NET:

  • Välj lämplig tjänst (delad eller 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. 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.
  • 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. I idealfallet ska alla åtgärder vara idempotenta, så att de kan upprepas utan att orsaka inkonsekvens. Om så inte är fallet bör återförsöket utföras på en nivå eller ett omfång som gör att alla relaterade ändringar kan ångras om en åtgärd misslyckas. till exempel inifrån ett transaktionsomfång. Mer information finns i Cloud Service Fundamentals Data Access Layer – Transient Fault Handling (Dataåtkomslager i Cloud Service Fundamentals – hantering av tillfälliga fel).
  • En strategi för fast intervall rekommenderas inte för användning med Azure SQL Database, förutom för interaktiva scenarier där det bara finns några återförsök med korta intervall. Överväg i stället att använda en exponentiell back-off-strategi för de flesta scenarier.
  • Välj ett lämpligt värde för anslutningen och kommandotimeouter när du definierar anslutningar. För kort timeout kan resultera i för tidiga fel i anslutningar när databasen är upptagen. 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. Värdet för tidsgränsen är en komponent i svarstiden från slutpunkt till slutpunkt. Den läggs effektivt till i den fördröjning av återförsök som anges i återförsöksprincipen för varje återförsök.
  • Stäng anslutningen efter några återförsök, även när du använder en exponentiell säkerhetskopiera logik och försök igen på en ny anslutning. Om du försöker med samma åtgärd flera gånger på samma anslutning kan det vara en faktor som bidrar till anslutningsproblem. 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).
  • När anslutningspoolen används (standardinställningen) finns det en risk att samma anslutning väljs från poolen, även efter att en anslutning har stängts och öppnats igen. I så fall är en teknik för att lösa det att anropa ClearPool-metoden för klassen SqlConnection för att markera anslutningen som inte återanvändbar. 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.
  • Om dataåtkomstkoden använder transaktioner som initierats som TransactionScope-instanser bör omprövningslogiken öppna anslutningen igen och initiera en ny transaktionsomfattning. Av den anledningen ska det återförsökbara kodblocket inbegripa hela omfattningen för transaktionen.

Överväg att börja med följande inställningar för återförsöksåtgärderna. De här inställningarna är allmänna och du bör övervaka åtgärderna och finjustera värdena så att de passar ditt eget scenario.

Kontext Exempelmål E2E
maximal svarstid		 Återförsöksstrategi Inställningar Värden Hur det fungerar
Interaktiv, gränssnitt
eller förgrund		 2 sek. FixedInterval Antal nya försök
Återförsöksintervall
Första snabba återförsöket		 3
500 ms
true		 Försök 1 – 0 sek. fördröjning
Försök 2 – 500 ms fördröjning
Försök 3 – 500 ms fördröjning
Bakgrund
eller batch		 30 sek ExponentialBackoff Antal nya försök
Min. backoff
Max. backoff
Deltabackoff
Första snabba återförsöket		 5
0 sek.
60 sek.
2 sek.
falskt		 Försök 1 – 0 sek. fördröjning
Försök 2 – ~2 sek. fördröjning
Försök 3 – ~6 sek. fördröjning
Försök 4 – ~14 sek. fördröjning
Försök 5 – ~30 sek. fördröjning

Kommentar

Målen för svarstid slutpunkt till slutpunkt förutsätter standardtimeout för anslutningar till tjänsten. Om du anger längre anslutningstimeouter utökas svarstiden slutpunkt till slutpunkt med denna extra tid för varje återförsök.

Exempel

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.

Följande kod visar en tilläggsmetod i SqlCommand-klassen som anropar ExecuteAsync med exponentiell 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.

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

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

Nästa steg

SQL Database med Entity Framework 6

SQL Database är en värdbaserad SQL Database som är tillgänglig i olika storlekar och som både en standardtjänst (delad) och premiumtjänst (ej delad). 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. Den eliminerar behovet av det mesta av den dataåtkomstkod som utvecklare normalt måste skriva.

Återförsöksmekanism

Återförsöksstöd ges vid åtkomst till SQL Database med Entity Framework 6.0 och senare via en mekanism som kallas anslutningsåterhämtning/återförsökslogik. Återförsöksmekanismens huvudfunktioner är:

  • Den primära abstraktionen är IDbExecutionStrategy-gränssnittet. Det här gränssnittet:
    • Definierar synkrona och asynkrona Kör-metoder .
    • 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. 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.
    • Definierar när och hur återförsök ska göras för en misslyckad anslutning.
  • Den innehåller flera inbyggda implementeringar av gränssnittet IDbExecutionStrategy :
    • Standard: försök inte igen.
    • Standard för SQL Database (automatisk): Inget nytt försök, men inspekterar undantag och omsluter dem med förslag på att använda SQL Database-strategin.
    • Standard för SQL Database: exponentiell (ärvd från basklass) plus SQL Database-identifieringslogik.
  • Den implementerar en exponentiell backoff-strategi som inkluderar slumpmässighet.
  • De inbyggda återförsöksklasserna är tillståndskänsliga och är inte trådsäkra. Men de kan återanvändas när den aktuella åtgärden har slutförts.
  • Om det angivna antalet återförsök överskrids omsluts resultatet i ett nytt undantag. Det bubblar inte upp det aktuella undantaget.

Konfiguration av princip

Funktioner för återförsök ges när SQL Database med Entity Framework 6.0 och senare används. Återförsöksprinciper konfigureras programmässigt. Konfigurationen kan inte ändras per åtgärd.

När du konfigurerar en strategi för kontexten som standard anger du en funktion som skapar en ny strategi på begäran. Följande kod visar hur du kan skapa en konfigurationsklass för återförsök som utökar DbConfiguration-basklassen.

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. Som standard identifierar EF konfigurationsklassen automatiskt och använder den.

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. Men om du bara har en konfigurationsklass använder EF den utan att behöva kommentera kontexten.

[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. Konfigurationsklassen kan använda denna flagga till att byta strategi eller inaktivera strategin du anger och använda en standardstrategi. Mer information finns i Suspend Execution Strategy (EF6 onward).

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. Du kan anropa dess ExecuteAsync-metod.

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. Detta är dock inte lämpligt när samma kontext krävs i olika scenarier, till exempel olika strategier för interaktiva försök och omprövning i bakgrunden. 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. Om de olika kontexterna måste köras i samma AppDomain krävs det en anpassad lösning.

Mer information finns i Kodbaserad konfiguration (EF6 och senare).

Följande tabell visar standardinställningarna för den inbyggda återförsöksprincipen vid användning av EF6.

Inställning Standardvärde Innebörd
Policy Exponentiellt Exponentiell backoff.
MaxRetryCount 5 Max. antal återförsök.
MaxDelay 30 sekunder Max. fördröjning mellan återförsök. Det här värdet påverkar inte hur serien med fördröjningar beräknas. Det definierar bara en övre gräns.
DefaultCoefficient 1 sekund Koefficienten för beräkningen av exponentiell backoff. Detta värde kan inte ändras.
DefaultRandomFactor 1,1 Multiplikatorn som används för att lägga till en slumpmässig fördröjning för varje post. Detta värde kan inte ändras.
DefaultExponentialBase 2 Multiplikatorn som används för att beräkna nästa fördröjning. Detta värde kan inte ändras.

Vägledning för återförsöksanvändning

Tänk på följande när du använder SQL Database med EF6:

  • Välj lämplig tjänst (delad eller 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. Om förutsägbara prestanda och tillförlitliga åtgärder med låg latens krävs kan du överväga att använda premiumalternativet.

  • En strategi för fast intervall rekommenderas inte för användning med 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.

  • Välj ett lämpligt värde för anslutningen och kommandotimeouter när du definierar anslutningar. Basera timeouten på din affärslogik och genom testning. Du kanske måste ändra värdet med tiden då datamängden eller affärsprocesserna ändras. För kort timeout kan resultera i för tidiga fel i anslutningar när databasen är upptagen. 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. Värdet för tidsgränsen är en komponent i svarstiden från slutpunkt till slutpunkt, men du kan inte enkelt avgöra hur många kommandon som ska köras när kontexten sparas. Du kan ändra standardtimeouten genom att ange egenskapen CommandTimeout i DbContext-instansen.

  • Entity Framework stödjer återförsökskonfigurationer som definieras i konfigurationsfiler. Men för maximal flexibilitet i Azure bör du skapa konfigurationen programmässigt i programmet. 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. Det gör att inställningarna kan ändras utan att programmet behöver startas om.

Överväg att börja med följande inställningar för återförsöksåtgärderna. Du kan inte ange fördröjningen mellan återförsök (den är fast och genererad som en exponentiell sekvens). Du kan bara ange de maxvärden som visas här, om du inte skapar en anpassad återförsöksstrategi. De här inställningarna är allmänna och du bör övervaka åtgärderna och finjustera värdena så att de passar ditt eget scenario.

Kontext Exempelmål E2E
maximal svarstid		 Återförsöksprincip Inställningar Värden Hur det fungerar
Interaktiv, gränssnitt
eller förgrund		 2 sekunder Exponentiellt MaxRetryCount
MaxDelay		 3
750 ms		 Försök 1 – 0 sek. fördröjning
Försök 2 – 750 ms fördröjning
Försök 3 – 750 ms fördröjning
Bakgrund
eller batch		 30 sekunder Exponentiellt MaxRetryCount
MaxDelay		 5
12 sekunder		 Försök 1 – 0 sek. fördröjning
Försök 2 – ~1 sek. fördröjning
Försök 3 – ~3 sek. fördröjning
Försök 4 – ~7 sek. fördröjning
Försök 5 – 12 sek. fördröjning

Kommentar

Målen för svarstid slutpunkt till slutpunkt förutsätter standardtimeout för anslutningar till tjänsten. Om du anger längre anslutningstimeouter utökas svarstiden slutpunkt till slutpunkt med denna extra tid för varje återförsök.

Exempel

I följande kodexempel definieras en enkel dataåtkomstlösning som använder Entity Framework. Den anger en specifik återförsöksstrategi genom att definiera en instans av klassen BlogConfiguration som utökar 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 använder Entity Framework-mekanismen för återförsök finns i logiken för anslutningsåterhämtning/återförsök.

SQL Database med 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. Den eliminerar behovet av det mesta av den dataåtkomstkod som utvecklare normalt måste skriva. Den här versionen av Entity Framework har skrivits från grunden och ärver inte automatiskt alla funktioner från EF6.x.

Återförsöksmekanism

Återförsöksstöd ges vid åtkomst till SQL Database med Entity Framework Core via en mekanism som kallas anslutningsåterhämtning. Anslutningsåterhämtning introducerades i EF Core 1.1.0.

Den primära abstraktionen är IExecutionStrategy-gränssnittet. Körningsstrategin för SQL Server, inklusive Azure SQL, är medveten om de undantagstyper som kan göras på nytt och har lämpliga standardvärden för maximala återförsök, fördröjning mellan återförsök och så vidare.

Exempel

Följande kod möjliggör automatiska återförsök när DbContext-objektet konfigureras, vilket representerar en session med databasen.

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. Transaktionen definieras i en delegate. Om det inträffar ett tillfälligt fel anropar körningsstrategin delegate igen.

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

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

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

            transaction.Commit();
        }
    });
}

Azure Storage

Azure Storage-tjänster omfattar bloblagring, filer och lagringsköer.

Blobbar, köer och filer

Klassen ClientOptions är bastypen för alla klientalternativtyper och visar olika vanliga klientalternativ som Diagnostik, Försök igen, Transport. Om du vill ange klientkonfigurationsalternativen för att ansluta till Azure Queue, Blob och File Storage måste du använda motsvarande härledda typ. I nästa exempel använder du klassen QueueClientOptions (härledd från ClientOptions) för att konfigurera en klient för att ansluta till Azure Queue Service. Egenskapen Försök igen är en uppsättning alternativ som kan anges för att påverka hur återförsök görs och hur ett fel kan göras igen.

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

Tabellstöd

Kommentar

WindowsAzure.Storage Nuget Package och Microsoft.Azure.Cosmos.Table Nuget Package har blivit inaktuella. Stöd för Azure-tabeller finns i Azure.Data.Tables Nuget Package

Återförsöksmekanism

Klientbiblioteket baseras på Azure Core-biblioteket, som är ett bibliotek som tillhandahåller övergripande tjänster till andra klientbibliotek.

Det finns många orsaker till varför ett fel kan inträffa när ett klientprogram försöker skicka en nätverksbegäran till en tjänst. Några exempel är timeout, fel i nätverksinfrastrukturen, tjänsten avvisar begäran på grund av begränsning/upptagen, tjänstinstansen avslutas på grund av nedskalning av tjänsten, tjänstinstansen ersätts med en annan version, tjänsten kraschar på grund av ett ohanterat undantag och så vidare. Genom att erbjuda en inbyggd mekanism för återförsök (med en standardkonfiguration som konsumenten kan åsidosätta) blir våra SDK:er och konsumentens program motståndskraftiga mot den här typen av fel. Observera att vissa tjänster debiterar riktiga pengar för varje begäran och därför bör konsumenterna kunna inaktivera återförsök helt om de föredrar att spara pengar framför återhämtning.

Konfiguration av princip

Återförsöksprinciper konfigureras programmässigt. Konfigurationen baseras på klassen RetryOption. Det finns ett attribut för TableClientOptions som ärvts från ClientOptions

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

Följande tabeller visar möjligheterna för de inbyggda återförsöksprinciperna.

RetryOption

Inställning Betydelse
Försening Fördröjningen mellan återförsöksförsök för en fast metod eller den fördröjning som en backoff-baserad metod ska basera beräkningar på. Om tjänsten tillhandahåller ett svarshuvud för återförsök efter fördröjs nästa återförsök av den varaktighet som anges av huvudvärdet.
MaxDelay Den maximala tillåtna fördröjningen mellan återförsök när tjänsten inte tillhandahåller ett återförsök efter svarshuvud. Om tjänsten tillhandahåller ett svarshuvud för återförsök efter fördröjs nästa återförsök av den varaktighet som anges av huvudvärdet.
Läge Den metod som ska användas för att beräkna fördröjningar av återförsök.
NetworkTimeout Tidsgränsen som tillämpas på en enskild nätverksåtgärd.

RetryMode

Inställning Betydelse
Exponentiellt Återförsök fördröjs baserat på en backoff-strategi, där varje försök ökar den varaktighet som väntar innan ett nytt försök görs.
MaxDelay Försök igen sker med fasta intervall. varje fördröjning är en konsekvent varaktighet.

Telemetri

Det enklaste sättet att se loggarna är att aktivera konsolloggning. Om du vill skapa en Azure SDK-logglyssnare som matar ut meddelanden till konsolen använder du metoden AzureEventSourceListener.CreateConsoleLogger.

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

Exempel

Om du kör följande kodexempel med lagringsemulatorn avstängd kan vi se information om återförsök i konsolen.

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

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

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

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

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

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

Allmänna riktlinjer för REST och återförsök

Tänk på följande när du använder Azure eller tjänster från tredje part:

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

  • Överväg att använda ett återförsöksramverk som Polly för att hantera återförsök om måltjänsten eller klienten inte har någon inbyggd återförsöksmekanism. 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. Du kan dock behöva skapa anpassad återförsökskod för tjänster som inte har ett standardbeteende som inte förlitar sig på undantag för att indikera tillfälliga fel eller om du vill använda ett svar om återförsökssvar för att hantera återförsöksbeteende.

  • Den tillfälliga identifieringslogiken är beroende av det faktiska klient-API:et som du kan anropa REST-anropen med. Vissa klienter, till exempel den nyare HttpClient-klassen , utlöser inte undantag för slutförda begäranden med en HTTP-statuskod som inte lyckas.

  • HTTP-statuskoden som returneras från tjänsten kan hjälpa till att ange om felet är tillfälligt. 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. Följande HTTP-koder anger vanligtivs att ett nytt försök är lämpligt:

    • 408 Timeout för begäran
    • 429 För många förfrågningar
    • 500 – Internt serverfel
    • 502 Felaktig gateway
    • 503 Tjänsten är inte tillgänglig
    • 504 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:

    • WebExceptionStatus.ConnectionClosed
    • WebExceptionStatus.ConnectFailure
    • WebExceptionStatus.Timeout
    • WebExceptionStatus.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. Tjänster kan även skicka ytterligare information som anpassade huvuden eller inbäddad i svarets innehåll.

  • Försök inte igen för statuskoder som representerar klientfel (fel i 4xx-intervallet) förutom en tidsgräns för 408-begäranden och 429 för många begäranden.

  • Testa dina återförsöksstrategier och -mekanismer noga i olika förhållanden, till exempel olika nätverkstillstånd och systembelastningar.

Återförsöksstrategier

Följande är vanliga typer av intervall för återförsstrategier:

  • Exponentiell. En återförsöksprincip som utför ett angivet antal återförsök med hjälp av en slumpmässig exponentiell back off-metod för att fastställa intervallet mellan återförsök. Till exempel:

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

  • Inkrementell. En strategi för återförsök med ett angivet antal återförsök och ett inkrementellt tidsintervall mellan återförsök. Till exempel:

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

  • LinearRetry. En återförsöksprincip som utför ett angivet antal återförsök med ett angivet fast tidsintervall mellan återförsök. Till exempel:

    retryInterval = this.deltaBackoff;

Hantering av tillfälliga fel med Polly

Polly är ett bibliotek för programmässig hantering av återförsök och kretsbrytare . Polly-projektet är en medlem i .NET Foundation. För tjänster där klienten inte har inbyggt stöd för återförsök är Polly ett giltigt alternativ och undviker behovet av att skriva anpassad återförsökskod, vilket kan vara svårt att implementera korrekt. Med Polly kan du också spåra fel när de inträffar, så att du kan logga återförsök.

Nästa steg

  • Återhämtning av Entity Framework-anslutningar