Opnieuw proberen

VAN TOEPASSING OP: Alle API Management-lagen

Het retry beleid voert het onderliggende beleid eenmaal uit en voert vervolgens de uitvoering opnieuw uit totdat het opnieuw condition wordt false geprobeerd of opnieuw count wordt geprobeerd.

Het retry beleid kan andere beleidsregels bevatten als onderliggende elementen, met uitzondering van wait beleid.

Beleidsinstructie

<retry
    condition="Boolean expression or literal"
    count="number of retry attempts"
    interval="retry interval in seconds"
    max-interval="maximum retry interval in seconds"
    delta="retry interval delta in seconds"
    first-fast-retry="boolean expression or literal">
        <!-- One or more child policies. No restrictions. -->
</retry>

Kenmerken

Wachttijden voor opnieuw proberen

• Wanneer alleen de interval opgegeven is, worden nieuwe pogingen met een vast interval uitgevoerd.

• Wanneer alleen de interval en delta zijn opgegeven, wordt een algoritme voor het opnieuw proberen van een lineair interval gebruikt. De wachttijd tussen nieuwe pogingen neemt toe volgens de volgende formule: interval + (count - 1)*delta.

• Wanneer de intervalen max-intervaldelta zijn opgegeven, wordt een algoritme voor exponentieel interval opnieuw proberen toegepast. De wachttijd tussen de nieuwe pogingen neemt exponentieel toe volgens de volgende formule: interval + (2^(count - 1)) * random(delta * 0.8, delta * 1.2), tot een maximuminterval dat is ingesteld door max-interval.

  Wanneer interval en delta beide zijn ingesteld op 10 seconden en max-interval 100 seconden is, neemt de geschatte wachttijd tussen nieuwe pogingen als volgt toe: 10 seconden, 20 seconden, 40 seconden, 80 seconden, met 100 seconden wachttijd voor resterende pogingen.

Elementen

Het retry beleid kan andere beleidsregels bevatten als onderliggende elementen, met uitzondering van wait beleid.

Gebruik

• Beleidssecties: inkomende, uitgaande, back-end, on-error
• Beleidsbereik: globaal, werkruimte, product, API, bewerking
• Gateways: klassiek, v2, verbruik, zelf-hostend, werkruimte

Gebruiksnotities

• Het beleid voert het onderliggende beleid in het retry blok uit voordat het wordt condition geëvalueerd voor het uitvoeren van de eerste nieuwe poging.

Voorbeelden

Doorsturen aanvragen met exponentieel opnieuw proberen

In het volgende voorbeeld wordt het doorsturen van aanvragen maximaal tien keer opnieuw geprobeerd met behulp van een algoritme voor exponentieel opnieuw proberen. Aangezien first-fast-retry dit is ingesteld false, zijn alle nieuwe pogingen onderhevig aan exponentieel toenemende wachttijden voor opnieuw proberen (in dit voorbeeld ongeveer 10 seconden, 20 seconden, 40 seconden, ...), tot een maximale wachttijd van max-interval.

<retry
    condition="@(context.Response.StatusCode == 500)"
    count="10"
    interval="10"
    max-interval="100"
    delta="10"
    first-fast-retry="false">
        <forward-request buffer-request-body="true" />
</retry>

Aanvraag verzenden na mislukte eerste aanvraag

In het volgende voorbeeld wordt het verzenden van een aanvraag naar een andere URL dan de gedefinieerde back-end maximaal drie keer geprobeerd als de verbinding is verbroken/een time-out opgetreden, of de aanvraag resulteert in een fout aan de serverzijde. Omdat first-fast-retry deze is ingesteld op true, wordt de eerste nieuwe poging direct na de eerste aanvraagfout uitgevoerd. Houd er rekening mee dat send-request deze moet worden ingesteld ignore-error op true om response-variable-name null te kunnen zijn in het geval van een fout.

<retry
    condition="@(context.Variables["response"] == null || ((IResponse)context.Variables["response"]).StatusCode >= 500)"
    count="3"
    interval="1"
    first-fast-retry="true">
        <send-request 
            mode="new" 
            response-variable-name="response" 
            timeout="3" 
            ignore-error="true">
		        <set-url>https://api.contoso.com/products/5</set-url>
		        <set-method>GET</set-method>
		</send-request>
</retry>

Back-end wisselen wanneer er een fout is ontvangen

In het volgende voorbeeld wordt de eerste aanvraag verzonden naar de primaire back-end. Als er een 429 Too Many Requests antwoordstatuscode wordt geretourneerd, wordt de aanvraag onmiddellijk opnieuw geprobeerd en doorgestuurd naar de secundaire back-end.

<backend>
    <retry
        condition="@(context.Response != null && context.Response.StatusCode == 429)"
        count="1"
        interval="1"
        first-fast-retry="true">
           <set-variable name="attempt-count" value="@(context.Variables.GetValueOrDefault<int>("attempt-count", 0)+1)" />
           <set-backend-service backend-id="@(context.Variables.GetValueOrDefault<int>("attempt-count") < 2 ? "primary-backend" : "secondary-backend" )" />
           <forward-request />
    </retry>
</backend>

Gerelateerd beleid

• Beleidsbeheer en -stroom

Gerelateerde inhoud

Zie voor meer informatie over het werken met beleid:

• Zelfstudie: Uw API transformeren en beveiligen
• Beleidsreferentie voor een volledige lijst met beleidsinstructies en hun instellingen
• Beleidsexpressies
• Beleid instellen of bewerken
• Beleidsconfiguraties opnieuw gebruiken
• Beleidsfragmentenopslagplaats
• Beleidsspeelplaats
• Azure API Management-beleidstoolkit
• Krijg hulp van Copilot bij het maken, uitleggen en oplossen van problemen met beleid.