Partilhar via


Tentar novamente

APLICA-SE A: Todas as camadas de gerenciamento de API

A retry política executa suas políticas filhas uma vez e, em seguida, tenta novamente sua execução até que a nova tentativa condition se torne false ou a nova tentativa count se esgote.

A retry política pode conter quaisquer outras políticas como seus elementos filho, exceto a wait política.

Nota

Defina os elementos da política e os elementos filho na ordem fornecida na declaração de política. Saiba mais sobre como definir ou editar políticas de Gerenciamento de API.

Declaração de política

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

Atributos

Atributo Descrição Necessário Predefinição
condição Booleano. Especifica se as novas tentativas devem ser interrompidas (false) ou continuadas (true). São permitidas expressões de política. Sim N/A
contagem Um número positivo entre 1 e 50 especificando o número de tentativas de tentativas. São permitidas expressões de política. Sim N/A
intervalo Um número positivo em segundos especificando o intervalo de espera entre as tentativas de repetição. São permitidas expressões de política. Sim N/A
intervalo-máximo Um número positivo em segundos especificando o intervalo máximo de espera entre as tentativas de repetição. Ele é usado para implementar um algoritmo de repetição exponencial. São permitidas expressões de política. Não N/A
delta Um número positivo em segundos especificando o incremento do intervalo de espera. Ele é usado para implementar os algoritmos de repetição linear e exponencial. São permitidas expressões de política. Não N/A
primeira tentativa rápida Booleano. Se definido como true, a primeira tentativa de repetição é executada imediatamente. São permitidas expressões de política. Não false

Repetir os tempos de espera

  • Quando apenas o é especificado, novas tentativas de intervalo fixo interval são executadas.

  • Quando apenas o interval e delta são especificados, um algoritmo de repetição de intervalo linear é usado. O tempo de espera entre novas tentativas aumenta de acordo com a seguinte fórmula: interval + (count - 1)*delta.

  • Quando o interval, max-interval e delta são especificados, um algoritmo de repetição de intervalo exponencial é aplicado. O tempo de espera entre as novas tentativas aumenta exponencialmente de acordo com a seguinte fórmula: interval + (2^(count - 1)) * random(delta * 0.8, delta * 1.2), até um intervalo máximo definido por max-interval.

    Por exemplo, quando interval e delta ambos são definidos como 10 segundos, e max-interval é de 100 segundos, o tempo de espera aproximado entre as novas tentativas aumenta da seguinte forma: 10 segundos, 20 segundos, 40 segundos, 80 segundos, com 100 segundos de tempo de espera usado para as tentativas restantes.

Elementos

A retry política pode conter quaisquer outras políticas como seus elementos filho, exceto a wait política.

Utilização

Notas de utilização

  • A política executa as políticas filho no retry bloco antes de avaliar a condition execução da primeira tentativa de repetição.

Exemplos

Solicitar encaminhamento com repetição exponencial

No exemplo a seguir, o encaminhamento de solicitações é repetido até dez vezes usando um algoritmo de repetição exponencial. Uma vez que first-fast-retry está definido como false, todas as tentativas de repetição estão sujeitas a um aumento exponencial dos tempos de espera de repetição (neste exemplo, aproximadamente 10 segundos, 20 segundos, 40 segundos, ...), até um máximo de espera 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>

Enviar solicitação após falha na solicitação inicial

No exemplo a seguir, o envio de uma solicitação para uma URL diferente do back-end definido é repetido até três vezes se a conexão for descartada/expirada ou se a solicitação resultar em um erro no servidor. Como first-fast-retry está definido como true, a primeira tentativa é executada imediatamente após a falha da solicitação inicial. Observe que send-request deve ser definido ignore-error como true para response-variable-name ser nulo no caso de um erro.


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

Alternar back-end quando o erro é recebido

No exemplo a seguir, a solicitação inicial é despachada para o back-end primário. Se um código de status de 429 Too Many Requests resposta for retornado, a solicitação será repetida imediatamente e encaminhada para o back-end secundário.

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

Sugestão

Como alternativa, você pode configurar um recurso de back-end com regras de disjuntor para detetar condições de falha e um pool com balanceamento de carga que distribui solicitações entre vários back-ends.

Para obter mais informações sobre como trabalhar com políticas, consulte: