Implementera en återförsöksprincip med .NET

Alla program som körs i molnet eller kommunicerar med fjärrtjänster och resurser måste kunna hantera tillfälliga fel. Det är vanligt att dessa program upplever fel på grund av en tillfällig förlust av nätverksanslutning, en tidsgräns för begäranden när en tjänst eller resurs är upptagen eller andra faktorer. Utvecklare bör skapa program för att hantera tillfälliga fel transparent för att förbättra stabilitet och återhämtning.

I den här artikeln får du lära dig hur du använder Azure Storage-klientbiblioteket för .NET för att konfigurera en återförsöksprincip för ett program som ansluter till Azure Blob Storage. Återförsöksprinciper definierar hur programmet hanterar misslyckade begäranden och bör alltid justeras för att matcha programmets affärskrav och typen av fel.

Konfigurera alternativ för återförsök

Återförsöksprinciper för Blob Storage konfigureras programmatiskt, vilket ger kontroll över hur återförsöksalternativ tillämpas på olika tjänstbegäranden och scenarier. Till exempel kan en webbapp som utfärdar begäranden baserat på användarinteraktion implementera en princip med färre återförsök och kortare fördröjningar för att öka svarstiden och meddela användaren när ett fel inträffar. Alternativt kan en app eller komponent som kör batchbegäranden i bakgrunden öka antalet återförsök och använda en exponentiell backoff-strategi för att tillåta att begärandetiden slutförs.

I följande tabell visas egenskaperna för klassen RetryOptions , tillsammans med typen, en kort beskrivning och standardvärdet om du inte gör några ändringar. Du bör vara proaktiv när du justerar värdena för dessa egenskaper för att uppfylla appens behov.

Property	Type	Beskrivning	Standardvärde
Försening	Tidsintervall	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 rubrikvärdet.	0,8 sekunder
MaxDelay	Tidsintervall	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 rubrikvärdet.	1 minut
MaxRetries	heltal	Det maximala antalet återförsök innan du ger upp.	5
Läge	RetryMode	Den metod som ska användas för att beräkna fördröjningar av återförsök.	Exponentiellt
NetworkTimeout	Tidsintervall	Tidsgränsen som tillämpas på en enskild nätverksåtgärd.	100 sekunder

I det här kodexemplet för Blob Storage konfigurerar vi återförsöksalternativen Retry i egenskapen för klassen BlobClientOptions . Sedan skapar vi ett klientobjekt för blobtjänsten med hjälp av återförsöksalternativen.

// Provide the client configuration options for connecting to Azure Blob Storage
BlobClientOptions blobOptions = new BlobClientOptions()
{
    Retry = {
        Delay = TimeSpan.FromSeconds(2),
        MaxRetries = 5,
        Mode = RetryMode.Exponential,
        MaxDelay = TimeSpan.FromSeconds(10),
        NetworkTimeout = TimeSpan.FromSeconds(100)
    },
};

BlobServiceClient blobServiceClient = new BlobServiceClient(
    accountUri,
    new DefaultAzureCredential(),
    blobOptions);

I det här exemplet använder varje tjänstbegäran som utfärdas från BlobServiceClient objektet återförsöksalternativen BlobClientOptions enligt definitionen i objektet. Du kan konfigurera olika återförsöksstrategier för tjänstklienter baserat på appens behov.

Använda geo-redundans för att förbättra appens återhämtning

Om din app kräver hög tillgänglighet och större återhämtning mot fel kan du använda geo-redundansalternativ för Azure Storage som en del av din återförsöksprincip. Lagringskonton som konfigurerats för geo-redundant replikering replikeras synkront i den primära regionen och replikeras asynkront till en sekundär region som ligger hundratals mil bort.

Azure Storage erbjuder två alternativ för geo-redundant replikering: Geo-redundant lagring (GRS) och geo-zonredundant lagring (GZRS). Förutom att aktivera geo-redundans för ditt lagringskonto måste du även konfigurera läsåtkomst till data i den sekundära regionen. Information om hur du ändrar replikeringsalternativ för ditt lagringskonto finns i Ändra hur ett lagringskonto replikeras.

I det här exemplet anger vi egenskapen GeoRedundantSecondaryUri i BlobClientOptions. Om den här egenskapen anges används den sekundära URI:n för GET eller HEAD begäranden under återförsök. Om statusen för svaret från den sekundära URI:n är en 404 använder efterföljande återförsök för begäran inte den sekundära URI:n igen, eftersom den här statuskoden anger att resursen kanske inte har spridits där ännu. I annat fall växlar efterföljande återförsök fram och tillbaka mellan primär och sekundär URI.

Uri secondaryAccountUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/");

// Provide the client configuration options for connecting to Azure Blob Storage
BlobClientOptions blobOptionsGRS = new BlobClientOptions()
{
    Retry = {
        Delay = TimeSpan.FromSeconds(2),
        MaxRetries = 5,
        Mode = RetryMode.Exponential,
        MaxDelay = TimeSpan.FromSeconds(10),
        NetworkTimeout = TimeSpan.FromSeconds(100)
    },

    // Set the secondary storage URI
    GeoRedundantSecondaryUri = secondaryAccountUri
};

BlobServiceClient blobServiceClient = new BlobServiceClient(
    accountUri,
    new DefaultAzureCredential(),
    blobOptionsGRS);

Appar som använder geo-redundans måste tänka på några specifika designöverväganden. Mer information finns i Använda geo-redundans för att utforma program med hög tillgänglighet.

Nästa steg

• Den här artikeln är en del av utvecklarguiden för Blob Storage för .NET. Se den fullständiga listan över utvecklarguideartiklar i Skapa din app.
• Arkitekturvägledning och allmänna metodtips för återförsöksprinciper finns i Tillfälliga felhantering.
• Vägledning om hur du implementerar ett återförsöksmönster för tillfälliga fel finns i Återförsöksmönster.