Повторить попытку

ОБЛАСТЬ ПРИМЕНЕНИЯ: все уровни Управление API

Политика retry выполняет свои дочерние политики один раз и затем повторяет их выполнение до тех пор, пока параметр condition попыток не примет значение false или параметр count попыток не будет исчерпан.

Политика retry может содержать любые другие политики в качестве дочерних элементов, за исключением wait политики.

Примечание.

Задайте элементы политики и дочерние элементы в порядке, указанном в правиле политики. Узнайте, как устанавливать или изменять политики службы управления API.

Правило политики

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

Атрибуты

Атрибут Описание Обязательное поле По умолчанию.
условие Логическое значение. Указывает, следует ли остановить повторные попытки (false) или продолжить (true). Допустимы выражения политики. Да Н/П
подсчет Положительное число от 1 до 50, указывающее количество повторных попыток для попытки. Допустимы выражения политики. Да Н/П
интервал Положительное значение в секундах, определяющее интервал ожидания между повторными попытками. Допустимы выражения политики. Да Н/П
максимальный интервал Положительное значение в секундах, определяющее максимальный интервал ожидания между повторными попытками. Оно используется для реализации экспоненциального алгоритма повторения. Допустимы выражения политики. нет Н/П
дельта Положительное значение в секундах, определяющее увеличение интервала ожидания. Используется для реализации линейного и экспоненциального алгоритмов повторения. Допустимы выражения политики. нет Н/П
первая быстрая повторная попытка Логическое значение. Если присвоено значение true, первая попытка повтора выполняется немедленно. Допустимы выражения политики. нет false

Время ожидания повторной попытки

  • Если указан только параметр interval, попытки выполняются с фиксированным интервалом.

  • Если указаны только interval и delta, используется алгоритм повторных попыток с линейным интервалом. Время ожидания между повторными попытками увеличивается по следующей формуле: interval + (count - 1)*delta.

  • Если указаны interval, max-interval и delta, используется алгоритм повторных попыток с экспоненциальным интервалом. Время ожидания между повторными попытками увеличивается экспоненциально по следующей формуле: interval + (2^(count - 1)) * random(delta * 0.8, delta * 1.2), до максимального интервала, заданного параметром max-interval.

    Например, если для interval и delta задано значение 10 секунд, а max-interval составляет 100 секунд, приблизительное время ожидания между повторными попытками увеличивается следующим образом: 10 секунд, 20 секунд, 40 секунд, 80 секунд, а для оставшихся повторных попыток используется интервал 100 секунд.

Элементы

Политика retry может содержать любые другие политики в качестве дочерних элементов, за исключением wait политики.

Использование

Заметки об использовании

  • Политика выполняет дочерние политики в блоке retry , прежде чем он оценивает condition выполнение первой попытки повторных попыток.

Примеры

Переадресация запросов с экспоненциальной повторными попытками

В следующем примере перенаправление запроса повторяется до 10 раз, следуя экспоненциальному алгоритму повторения. Так как first-fast-retry задано значение false, все попытки повторных попыток подвергаются экспоненциальному увеличению времени ожидания повторных попыток (в этом примере приблизительно 10 секунд, 20 секунд, 40 секунд, ...), до максимального ожидания 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>

Отправка запроса при сбое первоначального запроса

В следующем примере отправка запроса на URL-адрес, отличный от заданной серверной части, повторяется до трех раз, если подключение удалено/его время истекает, или запрос приводит к ошибке на стороне сервера. Так как для first-fast-retry задано значение True, первая повторная попытка выполняется немедленно после первоначального сбоя запроса. Обратите внимание, что send-request должно задавать для ignore-error значение True, чтобы response-variable-name имело значение NULL в случае ошибки.


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

Переключение серверной части при получении ошибки

В следующем примере исходный запрос отправляется в основную серверную часть. 429 Too Many Requests Если возвращается код состояния ответа, запрос возвращается немедленно и перенаправляется во вторичную серверную часть.

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

Подсказка

В качестве альтернативы можно настроить внутренний ресурс с правилами разбиения цепи для обнаружения условий сбоя и пула с балансировкой нагрузки, который распределяет запросы между несколькими внутренними серверами.

Связанный контент

Дополнительные сведения о работе с политиками см. в нижеуказанных статьях.

  • Last updated on