Erneut versuchen

GILT FÜR: Alle API Management-Ebenen

Die retry-Richtlinie führt ihre untergeordneten Richtlinien einmal aus und versucht dann, die Ausführung zu wiederholen, bis condition für die Wiederholung false wird oder der Wert count für die Wiederholung ausgeschöpft ist.

Die retry Richtlinie kann alle anderen Richtlinien als untergeordnete Elemente enthalten, mit Ausnahme der wait Richtlinie.

Richtlinienanweisung

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

Attribute

Wiederholungswartezeiten

• Wenn nur interval angegeben ist, werden Wiederholungsversuche nach interval Intervallen durchgeführt.

• Wenn nur interval und delta angegeben werden, wird ein linearer Intervallwiederholungsalgorithmus verwendet. Die Wartezeit zwischen Wiederholungsversuchen erhöht sich entsprechend folgender Formel: interval + (count - 1)*delta.

• Wenn interval, max-interval und delta angegeben werden, wird ein exponentieller Intervallwiederholungsalgorithmus angewendet. Die Wartezeit zwischen den Wiederholungsversuchen erhöht sich exponentiell gemäß folgender Formel: interval + (2^(count - 1)) * random(delta * 0.8, delta * 1.2), bis zu einem durch max-interval festgelegten maximalen Intervall.

  Wenn z. B. interval und delta beide auf 10 Sekunden eingestellt sind und max-interval 100 Sekunden beträgt, erhöht sich die ungefähre Wartezeit zwischen den Wiederholungsversuchen wie folgt: 10 Sekunden, 20 Sekunden, 40 Sekunden, 80 Sekunden, wobei 100 Sekunden Wartezeit für die verbleibenden Wiederholungsversuche verwendet werden.

Elemente

Die retry Richtlinie kann alle anderen Richtlinien als untergeordnete Elemente enthalten, mit Ausnahme der wait Richtlinie.

Verwendung

• Richtlinienabschnitte: inbound, outbound, backend, on-error
• Richtlinienbereiche: global, Arbeitsbereich, Produkt, API, Vorgang
• Gateways: klassisch, v2, Verbrauch, selbstgehostet, Arbeitsbereich

Verwendungshinweise

• Die Richtlinie führt die untergeordneten Richtlinien im retry Block aus, bevor sie den condition ersten Wiederholungsversuch auswertet.

Beispiele

Anforderungsweiterleitung mit exponentiellen Wiederholungsversuchen

Im folgenden Beispiel wird mit einem exponentiellen Wiederholungsalgorithmus bis zu zehnmal versucht, die Anforderungsweiterleitung zu wiederholen. Da first-fast-retry auf false festgelegt ist, wird bei allen Wiederholungsversuchen die Wiederholungswartezeit exponentiell erhöht (in diesem Beispiel etwa 10 Sekunden, 20 Sekunden, 40 Sekunden usw.). Die maximale Wartezeit wird durch max-interval festgelegt.

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

Senden einer Anforderung nach einem Fehler bei der ursprünglichen Anforderung

Im folgenden Beispiel wird das Senden einer Anforderung an eine andere URL als die des festgelegten Back-Ends bis zu drei Mal wiederholt, wenn die Verbindung getrennt wird bzw. ein Timeout auftritt oder die Anforderung zu einem serverseitigen Fehler führt. Da first-fast-retry auf „true“ festgelegt ist, wird die erste Wiederholung sofort nach dem anfänglichen Anforderungsfehler ausgeführt. Beachten Sie, dass send-request unter ignore-error auf „true“ festgelegt werden muss, damit response-variable-name im Falle eines Fehlers null ist.

<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 wechseln, wenn ein Fehler empfangen wird

Im folgenden Beispiel wird die anfängliche Anforderung an das primäre Back-End verteilt. Wenn ein 429 Too Many Requests Antwortstatuscode zurückgegeben wird, wird die Anforderung sofort wiederholt und an das sekundäre Back-End weitergeleitet.

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

Verwandte Richtlinien

• Richtliniensteuerung und -flow

Zugehöriger Inhalt

Weitere Informationen zum Arbeiten mit Richtlinien finden Sie hier:

• Tutorial: Transformieren und Schützen Ihrer API
• Unter Richtlinien für die API-Verwaltung finden Sie eine komplette Liste der Richtlinienanweisungen und der zugehörigen Einstellungen.
• Richtlinienausdrücke
• Festlegen oder Bearbeiten von Richtlinien
• Wiederverwenden von Richtlinienkonfigurationen
• Repository für Richtliniencodeausschnitte
• Richtlinien-Playground-Repository
• Azure API Management-Richtlinientoolkit
• Anfordern von Copilot-Unterstützung zum Erstellen, Erläutern und Problembehandlung von Richtlinien