Réessayer

S’APPLIQUE À : Tous les niveaux de Gestion des API

La stratégie retry exécute ses stratégies enfants une fois, puis retente leur exécution jusqu’à ce que la condition de la nouvelle tentative devienne false ou que le count de nouvelles tentatives soit épuisé.

La retry stratégie peut contenir d’autres stratégies en tant qu’éléments enfants, à l’exception de la wait stratégie.

Instruction de la stratégie

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

Attributs

Temps d’attente des nouvelles tentatives

• Lorsque seul interval est spécifié, les nouvelles tentatives sont effectuées à intervalles interval.

• Lorsque seuls interval et delta sont spécifiés, un algorithme de relance par intervalle linéaire est utilisé. Le temps d’attente entre les nouvelles tentatives augmente selon la formule suivante : interval + (count - 1)*delta

• Lorsque interval, max-interval et delta sont spécifiés, un algorithme de nouvelle tentative par intervalle exponentiel est appliqué. Le temps d’attente entre les nouvelles tentatives augmente de façon exponentielle en fonction de la formule suivante : interval + (2^(count - 1)) * random(delta * 0.8, delta * 1.2), jusqu’à un intervalle maximal défini par max-interval.

  Par exemple, quand interval et delta sont tous les deux définis sur 10 secondes et max-interval est de 100 secondes, le temps d’attente approximatif entre les nouvelles tentatives augmente comme suit : 10 secondes, 20 secondes, 40 secondes, 80 secondes, avec 100 secondes d’attente utilisée pour les nouvelles tentatives restantes.

Éléments

La retry stratégie peut contenir d’autres stratégies en tant qu’éléments enfants, à l’exception de la wait stratégie.

Utilisation

• Sections de la stratégie : inbound, outbound, backend, on-error
• Étendues de la stratégie : global, espace de travail, produit, API, opération
• Passerelles : classiques, v2, consommation, auto-hébergées, espace de travail

Notes d’utilisation

• La stratégie exécute les stratégies enfants dans le retry bloc avant d’évaluer l’exécution condition de la première tentative de nouvelle tentative.

Exemples

Transfert de demande avec nouvelle tentative exponentielle

Dans l’exemple suivant, le transfert de la demande est retenté jusqu’à dix fois suivant un algorithme de nouvelles tentatives exponentiel. Étant donné que first-fast-retry est false, toutes les tentatives de nouvelle tentative sont soumises à une augmentation exponentielle des temps d’attente des nouvelles tentatives (dans cet exemple, environ 10 secondes, 20 secondes, 40 secondes, ...), jusqu’à une attente maximale de 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>

Envoyer la demande en cas d’échec de la demande initiale

Dans l’exemple suivant, l’envoi d’une requête à une URL autre que le back-end défini est retenté jusqu’à trois fois si la connexion expire/est supprimée ou si la requête entraîne une erreur côté serveur. first-fast-retry ayant la valeur true, la première nouvelle tentative est exécutée immédiatement lors de l’échec de la requête initiale. Notez que send-request doit affecter la valeur true à ignore-error pour que response-variable-name soit Null en cas d’erreur.

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

Changer de serveur principal lorsque l’erreur a été reçue

Dans l’exemple suivant, la requête initiale est envoyée au back-end principal. Si un code d’état 429 Too Many Requests de réponse est retourné, la requête est retentée immédiatement et transférée vers le back-end secondaire.

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

Stratégies connexes

• Contrôle de stratégie et flux

Contenu connexe

Pour plus d’informations sur l’utilisation des stratégies, consultez :

• Tutoriel : Transformer et protéger votre API
• Référence de stratégie pour obtenir la liste complète des instructions et des paramètres de stratégie
• Expressions de stratégie
• Définir ou modifier des stratégies
• Réutilisation de configurations de stratégie
• Référentiel d’extrait de stratégie
• Dépôt de terrain de jeu de stratégie
• Kit de ressources des stratégies Gestion des API Azure
• Obtenez de l’aide de Copilot pour créer, expliquer et dépanner des politiques