Delen via

Beleid voor opnieuw proberen implementeren met .NET

  • Artikel

Elke toepassing die in de cloud wordt uitgevoerd of communiceert met externe services en resources, moet tijdelijke fouten kunnen afhandelen. Het is gebruikelijk dat deze toepassingen fouten ondervinden vanwege een tijdelijk verlies van netwerkconnectiviteit, een time-out van aanvragen wanneer een service of resource bezet is of andere factoren. Ontwikkelaars moeten toepassingen bouwen om tijdelijke fouten transparant af te handelen om de stabiliteit en tolerantie te verbeteren.

In dit artikel leert u hoe u de Azure Storage-clientbibliotheek voor .NET gebruikt om een beleid voor opnieuw proberen in te stellen voor een toepassing die verbinding maakt met Azure Blob Storage. Beleid voor opnieuw proberen definieert hoe de toepassing mislukte aanvragen verwerkt en moet altijd worden afgestemd op de bedrijfsvereisten van de toepassing en de aard van de fout.

Opties voor opnieuw proberen configureren

Beleid voor opnieuw proberen voor Blob Storage wordt programmatisch geconfigureerd en biedt controle over hoe opties voor opnieuw proberen worden toegepast op verschillende serviceaanvragen en scenario's. Een web-app die aanvragen uitgeeft op basis van gebruikersinteractie kan bijvoorbeeld een beleid implementeren met minder nieuwe pogingen en kortere vertragingen om de reactiesnelheid te verhogen en de gebruiker op de hoogte te stellen wanneer er een fout optreedt. Een app of onderdeel waarop batchaanvragen op de achtergrond worden uitgevoerd, kan ook het aantal nieuwe pogingen verhogen en een exponentiële uitstelstrategie gebruiken om de aanvraagtijd te laten voltooien.

De volgende tabel bevat de eigenschappen van de klasse RetryOptions , samen met het type, een korte beschrijving en de standaardwaarde als u geen wijzigingen aanbrengt. U moet proactief zijn bij het afstemmen van de waarden van deze eigenschappen om te voldoen aan de behoeften van uw app.

Eigenschap Type Description Default value
Uitstellen Periode De vertraging tussen nieuwe pogingen voor een vaste benadering of de vertraging waarop berekeningen voor een back-off-gebaseerde benadering moeten worden gebaseerd. Als de service een header Voor opnieuw proberen na antwoord biedt, wordt de volgende nieuwe poging vertraagd door de duur die is opgegeven door de headerwaarde. 0,8 seconde
MaxDelay Periode De maximaal toegestane vertraging tussen nieuwe pogingen wanneer de service geen antwoordheader opnieuw probeert te leveren. Als de service een header Voor opnieuw proberen na antwoord biedt, wordt de volgende nieuwe poging vertraagd door de duur die is opgegeven door de headerwaarde. 1 minuut
MaxRetries int Het maximum aantal nieuwe pogingen voordat u het opgeeft. 5 (zie opmerking)
Wijze RetryMode De methode die moet worden gebruikt voor het berekenen van vertragingen voor opnieuw proberen. Exponentieel
NetworkTimeout Periode De time-out die is toegepast op een afzonderlijke netwerkbewerking. 100 seconden

Notitie

StorageClientOptions verhoogt de standaardwaarde voor MaxRetries 3 tot 5. Alle andere eigenschappen hebben dezelfde standaardwaarden als RetryOptions.

In dit codevoorbeeld voor Blob Storage configureren we de opties voor opnieuw proberen in de Retry eigenschap van de klasse BlobClientOptions . Vervolgens maken we een clientobject voor de blobservice met behulp van de opties voor opnieuw proberen.

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

In dit voorbeeld gebruikt elke serviceaanvraag die is uitgegeven vanuit het BlobServiceClient object de opties voor opnieuw proberen zoals gedefinieerd in het BlobClientOptions object. U kunt verschillende strategieën voor opnieuw proberen configureren voor serviceclients op basis van de behoeften van uw app.

Georedundantie gebruiken om de tolerantie van apps te verbeteren

Als uw app hoge beschikbaarheid en meer flexibiliteit tegen fouten vereist, kunt u gebruikmaken van azure Storage-opties voor georedundantie als onderdeel van uw beleid voor opnieuw proberen. Opslagaccounts die zijn geconfigureerd voor geografisch redundante replicatie, worden synchroon gerepliceerd in de primaire regio en asynchroon gerepliceerd naar een secundaire regio die honderden kilometers verderop ligt.

Azure Storage biedt twee opties voor geografisch redundante replicatie: Geografisch redundante opslag (GRS) en geografisch zone-redundante opslag (GZRS). Naast het inschakelen van georedundantie voor uw opslagaccount, moet u ook leestoegang tot de gegevens in de secundaire regio configureren. Zie Wijzigen hoe een opslagaccount wordt gerepliceerd voor meer informatie over het wijzigen van replicatieopties voor uw opslagaccount.

In dit voorbeeld stellen we de eigenschap GeoRedundantSecondaryUri in BlobClientOptions. Als deze eigenschap is ingesteld, wordt de secundaire URI gebruikt voor GET of HEAD aanvragen tijdens nieuwe pogingen. Als de status van het antwoord van de secundaire URI een 404 is, gebruiken volgende nieuwe pogingen voor de aanvraag de secundaire URI niet opnieuw, omdat deze statuscode aangeeft dat de resource daar mogelijk nog niet is doorgegeven. Anders wisselen volgende nieuwe pogingen heen en weer tussen de primaire en secundaire 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);

Apps die gebruikmaken van georedundantie moeten rekening houden met enkele specifieke ontwerpoverwegingen. Zie Georedundantie gebruiken om maximaal beschikbare toepassingen te ontwerpen voor meer informatie.

Volgende stappen