Руководство по повторным попыткам для служб Azure

Статья
03/14/2023

Большинство служб Azure и клиентских пакетов SDK содержат механизм повтора. В то же время они отличаются, поскольку каждая служба имеет разные характеристики и требования, поэтому каждый механизм повтора настроен для конкретной службы. В этом руководстве приведены функции механизма повторных попыток для большинства служб Azure и содержатся сведения, которые помогут вам использовать, адаптировать или расширить механизм повторных попыток для этой службы.

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

В следующей таблице перечислены функции механизма повтора для служб Azure, описанных в этом руководстве.

Служба	Ключевые возможности	Настройки политики	Область применения	Функции телеметрии
Microsoft Entra ID	Машинный код в библиотеке MSAL	Внедрено в библиотеку MSAL	Внутренняя	нет
Azure Cosmos DB	Машинный код в службе	Ненастраиваемые	Глобальный	TraceSource
Data Lake Store	Машинный код в клиенте	Ненастраиваемые	Индивидуальные операции	нет
Центры событий	Машинный код в клиенте	Программный	Клиент	нет
Центр IoT	Машинный код в клиентском пакете SDK	Программный	Клиент	нет
Кэш Azure для Redis	Машинный код в клиенте	Программный	Клиент	TextWriter
Найти	Машинный код в клиенте	Программный	Клиент	Трассировка событий для Windows (ETW) или настраиваемая
Служебная шина	Машинный код в клиенте	Программный	Диспетчер пространств имен, фабрика сообщений и клиент	Трассировка событий Windows
Service Fabric	Машинный код в клиенте	Программный	Клиент	нет
База данных SQL с ADO.NET	Polly	Декларативные и программные	Единые инструкции или блоки кода	Пользовательское
База данных SQL с Entity Framework	Машинный код в клиенте	Программный	Глобальные каждого домена приложения	нет
База данных SQL с Entity Framework Core	Машинный код в клиенте	Программный	Глобальные каждого домена приложения	нет
Память	Машинный код в клиенте	Программный	Клиентские и индивидуальные операции	TraceSource

Примечание.

Сейчас для большинства встроенных механизмов повтора Azure невозможно применить другую политику повтора для других типов ошибок и исключений. Вам следует настроить политику, которая обеспечит оптимальный средний уровень производительности и доступности. Одним из способов настройки политики является анализ файлов журнала для определения типа возникающих временных сбоев.

Microsoft Entra ID

Идентификатор Microsoft Entra — это комплексное облачное решение для управления удостоверениями и доступом, которое объединяет основные службы каталогов, расширенное управление удостоверениями, безопасность и управление доступом к приложениям. Идентификатор Microsoft Entra также предлагает разработчикам платформу управления удостоверениями для доставки контроля доступа к приложениям на основе централизованной политики и правил.

Примечание.

Для получения рекомендаций по удостоверению управляемой службы конечных точек см. статью Использование управляемого удостоверения службы (MSI) виртуальной машины Azure для получения маркера

Механизм повтора

Существует встроенный механизм повторных попыток для идентификатора Microsoft Entra в библиотеке проверки подлинности Майкрософт (MSAL). Чтобы избежать непредвиденных блокировок, мы рекомендуем разработчикам не применять повторные попытки в своих библиотеках и приложениях, а использовать для этого библиотеку MSAL.

Руководство по использованию механизма повторов

При использовании идентификатора Microsoft Entra следует учитывать следующие рекомендации.

Везде, где это возможно, используйте библиотеку MSAL и ее встроенный механизм повторных попыток.
Если вы используете REST API для идентификатора Microsoft Entra, повторите операцию, если результирующий код равен 429 (слишком много запросов) или ошибку в диапазоне 5xx. Повторите попытку для других ошибок.
В случае ошибки 429 повторите попытку только по истечении времени, указанного в заголовке Retry-After.
В случае ошибок 5xx используйте экспоненциальный рост задержки, выполнив первую повторную попытку по крайней мере через 5 секунд после ответа.
Не повторяйте ошибки, отличные от 429 и 5xx.

Следующие шаги

Библиотека проверки подлинности Майкрософт (MSAL)

Azure Cosmos DB

Azure Cosmos DB — это полностью управляемая база данных с несколькими моделями, которая поддерживает данные JSON без схемы. Это гибкая и надежная система, имеющая собственную обработку транзакций JavaScript и предназначенная для использования в облаке со значительным потенциалом масштабирования.

Механизм повтора

Пакеты SDK Azure Cosmos DB автоматически повторяются в определенных условиях ошибок, а пользовательские приложения рекомендуется использовать собственные политики повторных попыток. Ознакомьтесь с руководством по проектированию устойчивых приложений с помощью пакетов SDK Azure Cosmos DB для полного списка ошибок и времени повтора.

Телеметрия

В зависимости от языка приложения диагностика и телеметрии предоставляются в виде журналов или повышения свойств ответов операций. Дополнительные сведения см. в разделе "Запись диагностика" в пакете SDK для C# Azure Cosmos DB и пакете SDK java для Azure Cosmos DB.

Data Lake Store

Data Lake Storage 2-го поколения делает служба хранилища Azure основой для создания корпоративных озер данных в Azure. Data Lake Storage 2-го поколения позволяет легко управлять большими объемами данных.

Клиентская библиотека Data Lake файлов служба хранилища Azure включает все возможности, необходимые для разработчиков, специалистов по обработке и анализу данных и аналитиков для хранения данных любого размера, фигуры и скорости, а также для всех типов обработки и аналитики на разных платформах и языках.

Механизм повтора

DataLakeServiceClient позволяет управлять ресурсами и файловыми системами службы Azure Data Lake. Учетная запись хранения предоставляет пространство имен верхнего уровня для службы Data Lake. При создании клиента можно предоставить параметры конфигурации клиента для подключения к службе Azure Data Lake (DataLakeClientOptions). DataLakeClientOptions включает свойство Retry (унаследованное от Azure.Core.ClientOptions), которое можно настроить (класс RetryOptions).

Телеметрия

Мониторинг использования и производительности служба хранилища Azure является важной частью эксплуатации службы. Примеры: частые операции, операции с высокой задержкой или операции, которые приводят к регулированию на стороне службы.

Вся телеметрия для вашей учетной записи хранения доступна с помощью журналов службы хранилища Azure в Azure Monitor. Эта функция интегрирует учетную запись хранения с Log Analytics и Центрами событий, а также позволяет архивировать журналы в другой учетной записи хранения. Полный список метрик и журналов ресурсов и связанную с ними схему см. в справочнике по данным мониторинга службы хранилища Azure.

Event Hubs

Центры событий Azure — это гипермасштабируемая служба приема данных телеметрии. Она собирает, преобразовывает и хранит миллионы событий.

Механизм повтора

Механизм повторных попыток в клиентской библиотеке для Центров событий Azure управляется свойством RetryPolicy в классе EventHubClient. Политика по умолчанию повторяется с экспоненциальным обратным выходом, когда Центры событий Azure возвращает временный EventHubsException или временныйOperationCanceledException. Политика повтора по умолчанию для Центров событий — до 9 повторных попыток с экспоненциальным увеличением интервала до 30 секунд.

Пример

EventHubClient client = EventHubClient.CreateWithManagedIdentity(new Uri("sb://full_namespace_url", "entity_path");
client.RetryPolicy = RetryPolicy.Default;

Следующие шаги

клиентская библиотека Центры событий Azure для .NET

Центр Интернета вещей

Центр Интернета вещей Azure — это служба подключения, мониторинга и администрирования устройств для разработки приложений Интернета вещей (IoT).

Механизм повтора

С помощью пакета SDK для устройств Azure IoT можно обнаруживать ошибки в сети, протоколе и приложениях. В зависимости от типа ошибки пакет SDK проверяет необходимость выполнения повторной попытки. Если ошибка является устранимой, пакет SDK выполняет повторные попытки, используя настроенную политику повтора.

Политика повтора по умолчанию использует стратегию экспоненциальной отсрочки со случайным дрожанием, но эту конфигурацию можно изменить.

Настройки политики

Конфигурации политики отличаются для разных языков. Дополнительные сведения см. в разделе Центр Интернета вещей конфигурации политики повторных попыток.

Следующие шаги

Кэш Azure для Redis

Кэш Azure для Redis является средством быстрого доступа к данным и службой кэша с низкой задержкой, созданной на основе популярного кэша Redis с открытым кодом. Она безопасна, управляется корпорацией Майкрософт и доступна из любого приложения в Azure.

Рекомендации в этом разделе основаны на использовании клиента StackExchange.Redis для доступа к кэшу. Список других подходящих клиентов можно найти на веб-сайте Redis, и они могут применять различные механизмы.

Клиент StackExchange.Redis использует мультиплексирование через одно подключение. Рекомендуется создавать экземпляр клиента при запуске приложения и использовать этот экземпляр для всех операций в кэше. По этой причине подключение к кэшу происходит только один раз, и поэтому все инструкции в этом разделе относятся к политике повтора для этого исходного соединения, а не для каждой операции, которая обращается к кэшу.

Механизм повтора

Клиент StackExchange.Redis использует класс диспетчера подключений, для настройки которого доступен ряд параметров, в том числе:

ConnectRetry. Число повторных попыток при сбое подключения к кэшу.
ReconnectRetryPolicy. Используемая стратегия повторных попыток.
ConnectTimeout. Максимальное время ожидания в миллисекундах.

Настройки политики

Политики повтора настраиваются программным способом с помощью параметров клиента перед подключением к кэшу. Для этого нужно создать экземпляр класса ConfigurationOptions, заполнить его свойства и передать ему метод Connect.

Встроенные классы поддерживают линейные (постоянные) паузы и экспоненциальное увеличение задержки с псевдослучайными интервалами. Также вы можете создать пользовательскую политику повторных попыток, реализовав интерфейс IReconnectRetryPolicy.

Код следующего примера настраивает стратегию повторных попыток с экспоненциальным увеличением задержки.

var deltaBackOffInMilliseconds = TimeSpan.FromSeconds(5).TotalMilliseconds;
var maxDeltaBackOffInMilliseconds = TimeSpan.FromSeconds(20).TotalMilliseconds;
var options = new ConfigurationOptions
{
    EndPoints = {"localhost"},
    ConnectRetry = 3,
    ReconnectRetryPolicy = new ExponentialRetry(deltaBackOffInMilliseconds, maxDeltaBackOffInMilliseconds),
    ConnectTimeout = 2000
};
ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

Кроме того, можно указать параметры в виде строки и передать эти данные методу Connect . Свойство ReconnectRetryPolicy не может быть задано таким образом, только с помощью кода.

var options = "localhost,connectRetry=3,connectTimeout=2000";
ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

Также вы можете указать параметры непосредственно при подключении к кэшу.

var conn = ConnectionMultiplexer.Connect("redis0:6380,redis1:6380,connectRetry=3");

Дополнительные сведения см. в документации по StackExchange.Redis.

Следующая таблица показывает значения по умолчанию для встроенной политики повторов.

Контекст	Параметр	Значение по умолчанию (версия 1.2.2)	Значение
Параметры конфигурации	ConnectRetry ConnectTimeout SyncTimeout ReconnectRetryPolicy	3 Максимально 5000 мс плюс SyncTimeout 1000 LinearRetry 5000 мс	Количество попыток повторов подключения во время начального подключения. Время ожидания (мс) для операций подключения. Без задержки между повторными попытками. Время (мс) для синхронных операций. Повторы через каждые 5000 мс.

Примечание.

Для синхронных операций можно добавить SyncTimeout для определения совокупного времени задержки, но слишком низкое значение этого параметра приведет к чрезмерному времени ожидания. Дополнительные сведения см. в разделе "Устранение неполадок Кэш Azure для Redis". Обычно следует избегать синхронных операций и использовать асинхронные везде, где это возможно. Дополнительные сведения см. в статье Конвейеры и мультиплексоры.

Руководство по использованию механизма повторов

При использовании Кэша Azure для Redis придерживайтесь приведенных ниже рекомендаций.

Клиент StackExchange Redis управляет собственными операциями повтора, но только при установлении соединения с кэшем при первом запуске приложения. Вы можете настроить время ожидания подключения, количество попыток повтора и время между повторными попытками установить это подключение, но политика повторных попыток не применяется к операциям с кэшем.
Вместо использования большого числа повторных попыток рассмотрите возможность возврата к исходному источнику данных.

Телеметрия

Можно собирать сведения о подключении (но не о других операциях) с помощью TextWriter.

var writer = new StringWriter();
ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

Ниже показан пример генерируемых выходных данных.

localhost:6379,connectTimeout=2000,connectRetry=3
1 unique nodes specified
Requesting tie-break from localhost:6379 > __Booksleeve_TieBreak...
Allowing endpoints 00:00:02 to respond...
localhost:6379 faulted: SocketFailure on PING
localhost:6379 failed to nominate (Faulted)
> UnableToResolvePhysicalConnection on GET
No masters detected
localhost:6379: Standalone v2.0.0, master; keep-alive: 00:01:00; int: Connecting; sub: Connecting; not in use: DidNotRespond
localhost:6379: int ops=0, qu=0, qs=0, qc=1, wr=0, sync=1, socks=2; sub ops=0, qu=0, qs=0, qc=0, wr=0, socks=2
Circular op-count snapshot; int: 0 (0.00 ops/s; spans 10s); sub: 0 (0.00 ops/s; spans 10s)
Sync timeouts: 0; fire and forget: 0; last heartbeat: -1s ago
resetting failing connections to retry...
retrying; attempts left: 2...
...

Примеры

Следующий пример кода настраивает постоянную (линейную) задержку между повторными попытками при инициализации клиента StackExchange.Redis. В этом примере показано, как настроить конфигурацию с помощью экземпляра ConfigurationOptions.

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using StackExchange.Redis;

namespace RetryCodeSamples
{
    class CacheRedisCodeSamples
    {
        public async static Task Samples()
        {
            var writer = new StringWriter();
            {
                try
                {
                    var retryTimeInMilliseconds = TimeSpan.FromSeconds(4).TotalMilliseconds; // delay between retries

                    // Using object-based configuration.
                    var options = new ConfigurationOptions
                                        {
                                            EndPoints = { "localhost" },
                                            ConnectRetry = 3,
                                            ReconnectRetryPolicy = new LinearRetry(retryTimeInMilliseconds)
                                        };
                    ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

                    // Store a reference to the multiplexer for use in the application.
                }
                catch
                {
                    Console.WriteLine(writer.ToString());
                    throw;
                }
            }
        }
    }
}

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

using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using StackExchange.Redis;

namespace RetryCodeSamples
{
    class CacheRedisCodeSamples
    {
        public async static Task Samples()
        {
            var writer = new StringWriter();
            {
                try
                {
                    // Using string-based configuration.
                    var options = "localhost,connectRetry=3,connectTimeout=2000";
                    ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

                    // Store a reference to the multiplexer for use in the application.
                }
                catch
                {
                    Console.WriteLine(writer.ToString());
                    throw;
                }
            }
        }
    }
}

Дополнительные примеры см. в разделе Конфигурация на веб-сайте проекта.

Следующие шаги

Веб-сайт Redis

Поиск Azure

Поиск Azure является мощным и сложным инструментом поиска для сайта или приложения с возможностями быстрой и простой настройки результатов поиска и построения информативных и точных моделей ранжирования.

Механизм повтора

Пакет SDK Azure для .NET включает клиентская библиотека Azure.Search.Documents из команды azure SDK, которая функционально эквивалентна предыдущей клиентской библиотеке Microsoft.Azure.Search.

Поведение повторных попыток в Microsoft.Azure.Search управляется методом SetRetryPolicy в классах SearchServiceClient и SearchIndexClient. Повтор политики по умолчанию осуществляется с экспоненциальной задержкой, если Поиск Azure возвращает ответ с кодом 5xx или 408 (истекло время ожидания запроса).

Поведение повторных попыток в Azure.Search.Documents управляется searchClientOptions (он является частью конструктора SearchClient) в свойстве Retry, который принадлежит классу Azure.Core.RetryOptions (где доступны все конфигурации).

Телеметрия

Используйте трассировку событий Windows или осуществляйте трассировку путем регистрации пользовательского поставщика трассировки. Дополнительные сведения см. в документации по AutoRest.

Cлужебная шина

Служебная шина является облачной платформой обмена сообщениями, которая предоставляет слабосвязанный обмен сообщениями с улучшенным масштабированием и устойчивостью для компонентов приложения, размещенных в облаке или локально.

Механизм повтора

Пространство имен и некоторые сведения о конфигурации зависят от используемого клиентского пакета SDK для Служебной шины:

Пакет	Description	Пространство имен
Azure.Messaging.ServiceBus	клиентская библиотека Служебная шина Azure для .NET	`Azure.Messaging.ServiceBus`
WindowsAzure.ServiceBus	Этот пакет является устаревшей клиентской библиотекой для Служебной шины. Ему требуется .NET Framework 4.5.2.	`Microsoft.Azure.ServiceBus`

Руководство по использованию механизма повторов

Свойство ServiceBusRetryOptions задает параметры повторных попыток для ServiceBusClient объекта:

Параметр	Default value	Значение
CustomRetryPolicy		Настраиваемая политика повторных попыток, используемая вместо отдельных значений параметров.
Задержка	0,8 секунды	Задержка между попытками повторных попыток для фиксированного подхода или задержки, на которой выполняется базовый расчет для обратного подхода.
MaxDelay	60 секунд	Максимальная допустимая задержка между повторными попытками.
MaxRetries	3	Максимальное количество повторных попыток, после которого связанная операция будет считаться неудавшейся.
Режим	Экспоненциально	Режим, используемый для расчета интервалов повтора.
TryTimeout	60 секунд	Максимальная длительность ожидания завершения одной попытки, будь то начальная попытка или повторная попытка.

Mode Задайте свойство для настройки ServiceBusRetryMode с любым из следующих значений:

Свойство	Значение	Описание
Экспоненциально	1	Повторные попытки будут отложены на основе стратегии отката, где каждая попытка увеличит продолжительность ожидания перед повторным повтором.
Фиксированный	0	Повторные попытки выполняются через фиксированные интервалы; каждая задержка является согласованной длительностью.

Пример:

using Azure.Identity;
using Azure.Messaging.ServiceBus;

string namespace = "<namespace>";
string queueName = "<queue_name>";

// Because ServiceBusClient implements IAsyncDisposable, we'll create it
// with "await using" so that it is automatically disposed for us.
var options = new ServiceBusClientOptions();
options.RetryOptions = new ServiceBusRetryOptions
{
    Delay = TimeSpan.FromSeconds(10),
    MaxDelay = TimeSpan.FromSeconds(30),
    Mode = ServiceBusRetryMode.Exponential,
    MaxRetries = 3,
};
await using var client = new ServiceBusClient(namespace, new DefaultAzureCredential(), options);

Телеметрия

служебная шина собирает те же типы данных мониторинга, что и другие ресурсы Azure. Вы можете отслеживать Служебная шина Azure с помощью Azure Monitor.

Вы также можете отправлять данные телеметрии с помощью клиентских библиотек .NET служебная шина.

Пример

В следующем примере кода показано, как использовать Azure.Messaging.ServiceBus пакет для:

Задайте политику повторных попыток для ServiceBusClient нового ServiceBusClientOptions.
Создайте новое сообщение с новым экземпляром ServiceBusMessageобъекта.
Отправьте сообщение в служебная шина с помощью ServiceBusSender.SendMessageAsync(message) метода.
Получение с помощью ServiceBusReceiverобъекта, которое представлено в виде ServiceBusReceivedMessage объектов.

using Azure.Identity;
using Azure.Messaging.ServiceBus;

string namespace = "<namespace>";
string queueName = "queue1";

// Because ServiceBusClient implements IAsyncDisposable, we'll create it 
// with "await using" so that it is automatically disposed for us.
var options = new ServiceBusClientOptions();
options.RetryOptions = new ServiceBusRetryOptions
{
    Delay = TimeSpan.FromSeconds(10),
    MaxDelay = TimeSpan.FromSeconds(30),
    Mode = ServiceBusRetryMode.Exponential,
    MaxRetries = 3,
};
await using var client = new ServiceBusClient(namespace, new DefaultAzureCredential(), options);

// The sender is responsible for publishing messages to the queue.
ServiceBusSender sender = client.CreateSender(queueName);
ServiceBusMessage message = new ServiceBusMessage("Hello world!");

await sender.SendMessageAsync(message);

// The receiver is responsible for reading messages from the queue.
ServiceBusReceiver receiver = client.CreateReceiver(queueName);
ServiceBusReceivedMessage receivedMessage = await receiver.ReceiveMessageAsync();

string body = receivedMessage.Body.ToString();
Console.WriteLine(body);

Следующие шаги

Шаблоны асинхронного обмена сообщениями и высокий уровень доступности

Service Fabric

Распространение надежных служб в кластере Service Fabric защищает от большинства потенциальных временных сбоев, которые описаны в этой статье. Но некоторые временные сбои все равно могут произойти. Например, если служба именования в момент получения запроса выполняет изменение маршрутизации, она создаст исключение. Если повторить этот же запрос через 100 миллисекунд, он, скорее всего, завершится успешно.

Service Fabric обрабатывает такие временные сбои на внутреннем уровне. Некоторые параметры можно настроить с помощью класса OperationRetrySettings при настройке служб. Следующий код показывает пример. В большинстве случаев это не должно быть обязательным, и параметры по умолчанию будут оштрафованы.

FabricTransportRemotingSettings transportSettings = new FabricTransportRemotingSettings
{
    OperationTimeout = TimeSpan.FromSeconds(30)
};

var retrySettings = new OperationRetrySettings(TimeSpan.FromSeconds(15), TimeSpan.FromSeconds(1), 5);

var clientFactory = new FabricTransportServiceRemotingClientFactory(transportSettings);

var serviceProxyFactory = new ServiceProxyFactory((c) => clientFactory, retrySettings);

var client = serviceProxyFactory.CreateServiceProxy<ISomeService>(
    new Uri("fabric:/SomeApp/SomeStatefulReliableService"),
    new ServicePartitionKey(0));

Следующие шаги

Обработка исключений удаленного взаимодействия

Использование Базы данных SQL с ADO.NET

База данных SQL — это размещенная База данных SQL, доступная в диапазоне размеров и как стандартная (общая) и (не общая) служба .

Механизм повтора

База данных SQL не имеет встроенной поддержки выполнения повторных попыток, если доступ осуществляется с помощью ADO.NET. Однако коды возврата от запросов могут быть использованы для определения причины сбоя запроса. Дополнительные сведения о регулировании базы данных SQL см. в статье Ограничения ресурсов Базы данных SQL Azure. Список кодов ошибок см. в описании кодов ошибок SQL для клиентских приложений Базы данных SQL.

Для реализации повторных попыток при обращении к Базе данных SQL вы можете использовать библиотеку Polly. Дополнительные сведения см. в разделе "Обработка временных сбоев" с помощью Polly.

Руководство по использованию механизма повторов

При доступе к базе данных SQL с помощью ADO.NET придерживайтесь следующих рекомендаций.

Выберите соответствующую службу (общую или премиальную). Общий экземпляр может испытывать большие задержки подключения и регулирования чем обычно из-за использования другими клиентами общего сервера. Если требуется более прогнозируемая производительность и выполнение надежных операций с низкой задержкой, попробуйте выбрать премиальный вариант.
Убедитесь, что выполнение повторов происходит на соответствующем уровне или области во избежание операций, не являющихся идемпотентными, что может вызвать несоответствие в данных. В идеальном случае все операции должны быть идемпотентными таким образом, чтобы их можно было повторить без возникновения несоответствия. Если это не так, повторная попытка должна выполняться на уровне или в области, которая позволяет отменить все связанные изменения при сбое одной операции; например, из области транзакций. Для получения дополнительных сведений обратитесь к разделу Основы облачной службы. Уровень доступа к данным: обработка временных ошибок.
Для использования с База данных SQL Azure не рекомендуется использовать стратегию фиксированного интервала, за исключением интерактивных сценариев, в которых имеется только несколько повторных попыток с короткими интервалами. Вместо этого рекомендуется использовать экспоненциальную стратегию обратного отключения для большинства сценариев.
Выберите подходящее значение для времени ожидания подключения и команды при определении подключения. Слишком короткое время ожидания может привести к преждевременным сбоям подключений, когда база данных занята. Слишком длинное время ожидания может помешать правильной работе логики повторов из-за слишком долгого ожидания до обнаружения ошибки соединения. Значение времени ожидания является компонентом сквозной задержки; Он фактически добавляется в задержку повторных попыток, указанную в политике повторных попыток для каждой попытки повтора.
Закройте подключение после некоторых повторных попыток, даже при использовании экспоненциальной логики повтора и повторите операцию при новом подключении. Повторение одной и той же операции несколько раз для одного соединения может стать фактором возникновения проблем с подключением. Пример использования этой технологии см. в статье Основы облачной службы. Уровень доступа к данным: обработка временных ошибок.
При использовании пула подключений (по умолчанию) есть вероятность того, что то же подключение будет выбрано из пула, даже после закрытия и повторного открытия подключения. Если это так, метод, чтобы устранить его, вызовите метод ClearPool класса SqlConnection, чтобы пометить соединение как неиспользуемое повторно. Тем не менее это следует делать только после сбоя нескольких попыток соединения и только при обнаружении определенного класса временных ошибок, таких как время ожидания SQL (код ошибки -2), связанных со сбоями в подключениях.
Если код доступа к данным использует транзакции, инициируемые как экземпляры TransactionScope , то логика повторных попыток должна включать повторное открытие подключения и инициацию новой области транзакции. По этой причине блок кода повторной попытки должен охватывать всю область транзакции.

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

Контекст	Пример целевого объекта E2E максимальная задержка	Стратегия повторов	Параметры	Значения	Принцип работы
Интерактивный, пользовательский интерфейс или передний план	2 с	FixedInterval	Счетчик повторов Интервал попытки Первый быстрый повтор	3 500 мс true	Попытка 1 — задержка 0 с Попытка 2 — задержка 500 мс попытка 3 — задержка 500 мс
Общие сведения или пакетный	30 с	ExponentialBackoff	Счетчик повторов Минимальная задержка Максимальная задержка Разностная задержка Первый быстрый повтор	5 0 с 60 с 2 с false	Попытка 1 — задержка 0 с Попытка 2 — задержка 2 с Попытка 3 — задержка 6 с Попытка 4 — задержка 14 с Попытка 5 — задержка 30 с

Примечание.

Целевые значения сквозной задержки подразумевают время ожидания по умолчанию для подключения к службе. При указании более длинного времени ожидания подключения величина сквозной задержки будет увеличена путем добавления этого дополнительного времени для каждой попытки повтора.

Примеры

В этом разделе показано, как с помощью Polly обращаться к Базе данных SQL Azure с использованием набора политик повторных попыток, настроенных в классе Policy.

Следующий код демонстрирует метод расширения для класса SqlCommand, который вызывает ExecuteAsync с экспоненциальным увеличением задержки.

public async static Task<SqlDataReader> ExecuteReaderWithRetryAsync(this SqlCommand command)
{
    GuardConnectionIsNotNull(command);

    var policy = Policy.Handle<Exception>().WaitAndRetryAsync(
        retryCount: 3, // Retry 3 times
        sleepDurationProvider: attempt => TimeSpan.FromMilliseconds(200 * Math.Pow(2, attempt - 1)), // Exponential backoff based on an initial 200 ms delay.
        onRetry: (exception, attempt) =>
        {
            // Capture some information for logging/telemetry.
            logger.LogWarn($"ExecuteReaderWithRetryAsync: Retry {attempt} due to {exception}.");
        });

    // Retry the following call according to the policy.
    await policy.ExecuteAsync<SqlDataReader>(async token =>
    {
        // This code is executed within the Policy

        if (conn.State != System.Data.ConnectionState.Open) await conn.OpenAsync(token);
        return await command.ExecuteReaderAsync(System.Data.CommandBehavior.Default, token);

    }, cancellationToken);
}

Этот асинхронный метод расширения можно использовать следующим образом.

var sqlCommand = sqlConnection.CreateCommand();
sqlCommand.CommandText = "[some query]";

using (var reader = await sqlCommand.ExecuteReaderWithRetryAsync())
{
    // Do something with the values
}

Следующие шаги

Основы облачной службы. Уровень доступа к данным: обработка временных ошибок

Использование Базы данных SQL с Entity Framework 6

База данных SQL — это размещенная База данных SQL, доступная в диапазоне размеров и как стандартная (общая) и (не общая) служба . Механизм Entity Framework является модулем объектно-реляционного сопоставления, который позволяет разработчикам .NET работать с реляционными данными с помощью специфических для домена объектов. Это исключает необходимость в большинстве кодов доступа к данным, которые обычно требуется писать разработчикам.

Механизм повтора

Поддержка повторных попыток при доступе к Базе данных SQL с помощью Entity Framework 6.0 и выше предоставляется через механизм, называемый устойчивость подключения и логика повторных попыток. Ниже перечислены основные возможности механизма повтора.

Интерфейс IDbExecutionStrategy является основной абстракцией. Этот интерфейс:
- Определяет синхронные и асинхронные методы Execute.
- Определяет классы для непосредственного использования, или которые могут быть настроены на контекст базы данных как стратегию по умолчанию, с сопоставленным именем поставщика или сопоставленным именем поставщика и именем сервера. При настройке на контекст повторы происходят на уровне операций с отдельными базами данных, из которых несколько может соответствовать заданному контексту операции.
- Определяет, когда и каким образом следует выполнить повтор при ошибке соединения.
Он включает несколько встроенных реализаций интерфейса IDbExecutionStrategy :
- Значение по умолчанию — не повторять.
- По умолчанию для базы данных SQL (автоматический режим) — не повторять, но проверять исключения и завершать их с предложением использовать стратегию базы данных SQL.
- По умолчанию для базы данных SQL — экспоненциальная задержка (наследуется от базового класса) плюс логика обнаружения базы данных SQL.
Это реализует стратегию экспоненциальной отсрочки, которая также включает случайный выбор.
Встроенные классы повторных попыток являются отслеживанием состояния и не являются потокобезопасными. Однако они могут использоваться повторно после завершения текущей операции.
В случае превышения заданного счетчика повторов результаты помещаются в новое исключение. Он не пузырьк текущего исключения.

Настройки политики

Поддержка повторных попыток предоставляется при доступе к базе данных SQL с помощью Entity Framework 6.0 и более поздних версий. Политики повтора настраиваются программным способом. Конфигурация не может быть изменена на основе каждой операции.

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

public class BloggingContextConfiguration : DbConfiguration
{
  public BlogConfiguration()
  {
    // Set up the execution strategy for SQL Database (exponential) with 5 retries and 4 sec delay
    this.SetExecutionStrategy(
         "System.Data.SqlClient", () => new SqlAzureExecutionStrategy(5, TimeSpan.FromSeconds(4)));
  }
}

Затем можно указать это в качестве стратегии повторных попыток по умолчанию для всех операций с помощью метода SetConfiguration экземпляра DbConfiguration при запуске приложения. По умолчанию EF будет автоматически обнаруживать и использовать класс конфигурации.

DbConfiguration.SetConfiguration(new BloggingContextConfiguration());

Класс конфигурации повторных попыток для контекста задается дополнением контекста класса атрибутом DbConfigurationType . Однако при наличии только одного класса конфигурации EF будет использовать его без необходимости дополнения контекста.

[DbConfigurationType(typeof(BloggingContextConfiguration))]
public class BloggingContext : DbContext

Если необходимо использовать различные стратегии для конкретных операций или отключить повторы для определенных операций, то можно создать класс конфигурации, который позволяет приостановить или заменить стратегии, установив флаг CallContext. Класс конфигурации может использовать этот флаг для переключения стратегии или отключения стратегии, предоставленной вами, с последующим использованием стратегии по умолчанию. Дополнительные сведения см. в статье "Стратегия приостановки выполнения" (EF6).

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

var executionStrategy = new SqlAzureExecutionStrategy(5, TimeSpan.FromSeconds(4));
var blogs = await executionStrategy.ExecuteAsync(
    async () =>
    {
        using (var db = new BloggingContext("Blogs"))
        {
            // Acquire some values asynchronously and return them
        }
    },
    new CancellationToken()
);

Самый простой способ использовать класс DbConfiguration — это обнаружить его в той же сборке, что и класс DbContext. Однако это не подходит, если в разных сценариях требуется один и тот же контекст, например различные интерактивные и фоновые стратегии повторных попыток. Если разные контексты выполняются в отдельных доменах приложений, можно использовать встроенную поддержку для указания классов конфигурации в файле конфигурации или задать ее явным образом с помощью кода. Если различные контексты должны выполняться в том же домене приложения, потребуется создание пользовательского решения.

Дополнительные сведения см. в разделе "Конфигурация на основе кода" (EF6).

Следующая таблица показывает значения по умолчанию для встроенной политики повторов при использовании EF6.

Параметр	Default value	Значение
Политика	Экспоненциально	Экспоненциальная задержка.
MaxRetryCount	5	Максимальное число попыток.
MaxDelay	30 секунд	Максимальная задержка между повторными попытками. Это значение не влияет на вычисление ряда задержек. Оно определяет только верхнюю границу.
DefaultCoefficient	1 с	Коэффициент для вычисления значения экспоненциальной задержки. Это значение невозможно изменить.
DefaultRandomFactor	1,1	Множитель, который используется для добавления значения случайной задержки для каждой записи. Это значение невозможно изменить.
DefaultExponentialBase	2	Множитель, который используется для вычисления значения следующей задержки. Это значение невозможно изменить.

Руководство по использованию механизма повторов

При доступе к базе данных SQL с помощью EF6, придерживайтесь следующих рекомендаций.

Выберите соответствующую службу (общую или премиальную). Общий экземпляр может испытывать большие задержки подключения и регулирования чем обычно из-за использования другими клиентами общего сервера. Если требуется выполнение надежных операций с низкой задержкой и прогнозируемая производительность, попробуйте выбрать премиальный вариант.
Для использования с База данных SQL Azure не рекомендуется использовать стратегию фиксированного интервала. Вместо этого используйте стратегию экспоненциальной отсрочки, так как служба может быть перегружена и большее время задержки обеспечит большее время для ее восстановления.
Выберите подходящее значение для времени ожидания подключения и команды при определении подключения. Выберите значение времени ожидания на основе логики вашей работы и на основе испытаний. Может потребоваться изменить это значение по мере изменения объемов данных или бизнес-процессов. Слишком короткое время ожидания может привести к преждевременным сбоям подключений, когда база данных занята. Слишком длинное время ожидания может помешать правильной работе логики повторов из-за слишком долгого ожидания до обнаружения ошибки соединения. Значение времени ожидания является компонентом сквозной задержки, хотя вы не можете легко определить, сколько команд будет выполняться при сохранении контекста. Время ожидания по умолчанию можно изменить, задав свойство CommandTimeout экземпляра DbContext.
Платформа Entity Framework поддерживает конфигурации повторов, определенные в файлах конфигурации. Однако для максимальной гибкости в Azure необходимо создать конфигурацию программным способом в приложении. Определенные параметры политик повторов, например количество повторных попыток и интервалы повтора, можно сохранить в файле конфигурации службы и использовать во время выполнения для создания соответствующих политик. Это позволяет изменять параметры без перезапуска приложения.

Для начала установите следующие параметры для операций повтора. Невозможно указать задержку между повторными попытками (она исправлена и создана в виде экспоненциальной последовательности). Максимальные значения можно указать, как показано ниже, если только вы не создаете пользовательскую стратегию. Это параметры общего назначения, и вам будет необходимо отслеживать операции и проводить тонкую настройку параметров в соответствии с конкретной ситуацией.

Контекст	Пример целевого объекта E2E максимальная задержка	Политика повтора	Параметры	Значения	Принцип работы
Интерактивный, пользовательский интерфейс или передний план	2 секунды	Экспоненциально	MaxRetryCount MaxDelay	3 750 мс	Попытка 1 — задержка 0 с Попытка 2 — задержка 750 мс Попытка 3 – задержка 750 мс
Общие сведения или пакетный	30 секунд	Экспоненциально	MaxRetryCount MaxDelay	5 12 секунд	Попытка 1 — задержка 0 с Попытка 2 — задержка 1 с Попытка 3 — задержка 3 с Попытка 4 — задержка 7 с Попытка 5 — задержка 12 с

Примечание.

Примеры

В следующем примере кода определяется простое решение доступа к данным, использующее Entity Framework. Программа определяет конкретную стратегию путем определения класса с именем экземпляра BlogConfiguration, который расширяет DbConfiguration.

using System;
using System.Collections.Generic;
using System.Data.Entity;
using System.Data.Entity.SqlServer;
using System.Threading.Tasks;

namespace RetryCodeSamples
{
    public class BlogConfiguration : DbConfiguration
    {
        public BlogConfiguration()
        {
            // Set up the execution strategy for SQL Database (exponential) with 5 retries and 12 sec delay.
            // These values could be loaded from configuration rather than being hard-coded.
            this.SetExecutionStrategy(
                    "System.Data.SqlClient", () => new SqlAzureExecutionStrategy(5, TimeSpan.FromSeconds(12)));
        }
    }

    // Specify the configuration type if more than one has been defined.
    // [DbConfigurationType(typeof(BlogConfiguration))]
    public class BloggingContext : DbContext
    {
        // Definition of content goes here.
    }

    class EF6CodeSamples
    {
        public async static Task Samples()
        {
            // Execution strategy configured by DbConfiguration subclass, discovered automatically or
            // or explicitly indicated through configuration or with an attribute. Default is no retries.
            using (var db = new BloggingContext("Blogs"))
            {
                // Add, edit, delete blog items here, then:
                await db.SaveChangesAsync();
            }
        }
    }
}

Дополнительные примеры использования механизма повтора Entity Framework можно найти в разделе Устойчивость соединения и логика повтора.

Использование Базы данных SQL с Entity Framework Core

Механизм Entity Framework Core отслеживает взаимоотношения между объектами и позволяет разработчикам .NET использовать объекты на уровне доменов при работе с данными. Это исключает необходимость в большинстве кодов доступа к данным, которые обычно требуется писать разработчикам. Эта версия Entity Framework полностью создана с нуля и по умолчанию не наследует возможности EF6.x.

Механизм повтора

Поддержка повторных попыток при доступе к Базе данных SQL с использованием Entity Framework Core предоставляется через механизм, называемый устойчивость подключения. Устойчивость подключения впервые появилась в версии EF Core 1.1.0.

Основным объектом абстракции является интерфейс IExecutionStrategy. Стратегия выполнения для SQL Server, в том числе SQL Azure, учитывает типы исключений, которые могут быть извлечены и имеют разумные значения по умолчанию для максимальных повторных попыток, задержки между повторными попытками и т. д.

Примеры

Следующий пример кода использует автоматические повторные попытки при настройке объекта DbContext, который представляет сеанс подключения к базе данных.

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder
        .UseSqlServer(
            @"Server=(localdb)\mssqllocaldb;Database=EFMiscellaneous.ConnectionResiliency;Trusted_Connection=True;",
            options => options.EnableRetryOnFailure());
}

Следующий пример кода демонстрирует, как выполнять транзакцию с автоматическими повторными попытками с использованием стратегии выполнения. Транзакция определяется в делегате. Если происходит временный сбой, стратегия выполнения снова вызывает делегат.

using (var db = new BloggingContext())
{
    var strategy = db.Database.CreateExecutionStrategy();

    strategy.Execute(() =>
    {
        using (var transaction = db.Database.BeginTransaction())
        {
            db.Blogs.Add(new Blog { Url = "https://blogs.msdn.com/dotnet" });
            db.SaveChanges();

            db.Blogs.Add(new Blog { Url = "https://blogs.msdn.com/visualstudio" });
            db.SaveChanges();

            transaction.Commit();
        }
    });
}

Хранилище Azure

Службы хранилища Azure включают хранилища больших двоичных объектов, файлов и очереди хранилища.

Большие двоичные объекты, очереди и файлы

Класс ClientOptions является базовым типом для всех типов клиентских параметров и предоставляет различные общие параметры клиента, такие как Diagnostics, Retry и Transport. Чтобы предоставить параметры конфигурации клиента для подключения к хранилищу очередей, больших двоичных объектов и файлов Azure, необходимо использовать соответствующий производный тип. В следующем примере класс QueueClientOptions (производный от ClientOptions) используется для настройки подключения клиента к службе очередей Azure. Свойство Retry — это набор параметров, с помощью которых можно влиять на способ выполнения повторных попыток и возможность их выполнения в случае сбоя.

using System;
using System.Threading;
using Azure.Core;
using Azure.Identity;
using Azure.Storage;
using Azure.Storage.Queues;
using Azure.Storage.Queues.Models;

namespace RetryCodeSamples
{
    class AzureStorageCodeSamples {

        public async static Task Samples() {

               // Provide the client configuration options for connecting to Azure Queue Storage
                QueueClientOptions queueClientOptions = new QueueClientOptions()
                {
                    Retry = {
                    Delay = TimeSpan.FromSeconds(2),     //The delay between retry attempts for a fixed approach or the delay on which to base
                                                         //calculations for a backoff-based approach
                    MaxRetries = 5,                      //The maximum number of retry attempts before giving up
                    Mode = RetryMode.Exponential,        //The approach to use for calculating retry delays
                    MaxDelay = TimeSpan.FromSeconds(10)  //The maximum permissible delay between retry attempts
                    },

                    GeoRedundantSecondaryUri = new Uri("https://...")
                    // If the GeoRedundantSecondaryUri property is set, the secondary Uri will be used for GET or HEAD requests during retries.
                    // If the status of the response from the secondary Uri is a 404, then subsequent retries for the request will not use the
                    // secondary Uri again, as this indicates that the resource may not have propagated there yet.
                    // Otherwise, subsequent retries will alternate back and forth between primary and secondary Uri.
                };

                Uri queueServiceUri = new Uri("https://storageaccount.queue.core.windows.net/");
                string accountName = "Storage account name";
                string accountKey = "storage account key";

                // Create a client object for the Queue service, including QueueClientOptions.
                QueueServiceClient serviceClient = new QueueServiceClient(queueServiceUri, new DefaultAzureCredential(), queueClientOptions);

                CancellationTokenSource source = new CancellationTokenSource();
                CancellationToken cancellationToken = source.Token;

                // Return an async collection of queues in the storage account.
                var queues = serviceClient.GetQueuesAsync(QueueTraits.None, null, cancellationToken);

Поддержка таблиц

Примечание.

Пакет Nuget WindowsAzure.Storage и пакет Nuget Microsoft.Azure.Cosmos.Table не рекомендуется. Сведения о поддержке таблиц Azure см. в разделе "Пакет Nuget Azure.Data.Tables"

Механизм повтора

Клиентская библиотека основана на библиотеке Azure Core, которая предоставляет перекрестные службы другим клиентским библиотекам.

Существует множество причин, по которым может произойти сбой, когда клиентское приложение пытается отправить сетевой запрос в службу. Некоторые примеры: время ожидания, сбои сетевой инфраструктуры, отклонение запроса из-за ограничения или занятости, завершение экземпляра службы из-за уменьшения масштаба службы, экземпляр службы будет заменен другой версией, сбоем службы из-за необработанного исключения и т. д. Предлагая встроенный механизм повторных попыток (с конфигурацией по умолчанию потребитель может переопределить), наши пакеты SDK и приложение потребителя становятся устойчивыми к таким типам сбоев. Обратите внимание, что некоторые службы взимает реальные деньги за каждый запрос, поэтому потребители должны иметь возможность отключить повторные попытки полностью, если они предпочитают сэкономить деньги на устойчивость.

Настройки политики

Политики повтора настраиваются программным способом. Конфигурация основана на классе RetryOption. Атрибут TableClientOptions наследуется от ClientOptions

var tableClientOptions = new TableClientOptions();
tableClientOptions.Retry.Mode = RetryMode.Exponential;
tableClientOptions.Retry.MaxRetries = 5;
var serviceClient = new TableServiceClient("<endpoint>", new DefaultAzureCredential(), tableClientOptions);

В следующих таблицах показаны возможности встроенных политик повторных попыток.

RetryOption

Параметр	Значение
Задержка	Задержка между попытками повторных попыток для фиксированного подхода или задержки, на которой выполняется базовый расчет для обратного подхода. Если служба предоставляет заголовок ответа Retry-After, следующая повторная попытка будет отложена по длительности, указанной значением заголовка.
MaxDelay	Максимальная допустимая задержка между попытками повторных попыток, когда служба не предоставляет заголовок ответа Retry-After. Если служба предоставляет заголовок ответа Retry-After, следующая повторная попытка будет отложена по длительности, указанной значением заголовка.
Режим	Режим, используемый для расчета интервалов повтора.
NetworkTimeout	Время ожидания, применяемое к отдельным сетевым операциям.

RetryMode

Параметр	Значение
Экспоненциально	Повторные попытки будут отложены на основе стратегии отката, где каждая попытка увеличит продолжительность ожидания перед повторным повтором.
MaxDelay	Повторные попытки выполняются через фиксированные интервалы; каждая задержка является согласованной длительностью.

Телеметрия

Самый простой способ просмотра журналов — включить ведение журнала консоли. Чтобы создать прослушиватель журналов Azure SDK, который выводит сообщения в консоль с помощью метода AzureEventSourceListener.CreateConsoleLogger.

// Setup a listener to monitor logged events.
using AzureEventSourceListener listener = AzureEventSourceListener.CreateConsoleLogger();

Примеры

Выполнение следующего примера кода с завершением работы эмулятора хранения позволит нам просмотреть сведения о повторных попытках в консоли.

using Azure.Core;
using Azure.Core.Diagnostics;
using Azure.Data.Tables;
using Azure.Data.Tables.Models;
using Azure.Identity;

namespace RetryCodeSamples
{
    class AzureStorageCodeSamples
    {
        private const string tableName = "RetryTestTable";

        public async static Task SamplesAsync()
        {
            // Setup a listener to monitor logged events.
            using AzureEventSourceListener listener = AzureEventSourceListener.CreateConsoleLogger();

            var tableClientOptions = new TableClientOptions();
            tableClientOptions.Retry.Mode = RetryMode.Exponential;
            tableClientOptions.Retry.MaxRetries = 5;

            var serviceClient = new TableServiceClient("<endpoint>", new DefaultAzureCredential(), tableClientOptions);

            TableItem table = await serviceClient.CreateTableIfNotExistsAsync(tableName);
            Console.WriteLine($"The created table's name is {table.Name}.");
        }
    }
}

Общие рекомендации по использованию REST и механизма повторов

При обращении к службам Azure или службам сторонних производителей учитывайте следующее:

Используйте систематический подход к управлению механизмом повторов, возможно в виде повторно используемого кода, что таким образом дает возможность применения согласованной методологии ко всем клиентам и всем решениям.
Если целевая служба или клиент не имеет встроенного механизма повторов, рекомендуется использовать платформы повторов, например Polly, для управления механизмом повторов. Это поможет реализовать согласованный механизм повтора и может предоставить подходящую стратегию повторов по умолчанию для целевой службы. Однако может потребоваться создать пользовательский код повторных попыток для служб, которые имеют нестандартное поведение, которое не зависит от исключений, чтобы указать временные сбои или использовать ответ Retry-Response для управления поведением повторных попыток.
Логика обнаружения временных сбоев будет зависеть от фактического клиентского API, который используется для вызова REST. Некоторые клиенты, такие как новый класс HttpClient , не будут вызывать исключения для завершенных запросов с кодом состояния HTTP без успешного выполнения.
Код состояния HTTP, возвращаемый службой, позволяет указать, является ли ошибка временной. Необходимо изучить исключения, генерируемые клиентом, или механизм повторов для доступа к коду состояния для определения эквивалентного типа исключения. Следующие коды HTTP обычно показывают, что повтор может быть выполнен.
- 408 — истекло время ожидания запроса
- 429 — слишком много запросов
- 500 Internal Server Error (внутренняя ошибка сервера).
- 502 — Недопустимый шлюз
- 503 Сервис недоступен
- 504 — Истекло время ожидания шлюза
Если логика повторов основана на исключениях, следующие параметры обычно указывают, что произошел временный сбой где не удалось создать подключение.
- WebExceptionStatus.ConnectionClosed
- WebExceptionStatus.ConnectFailure
- WebExceptionStatus.Timeout
- WebExceptionStatus.RequestCanceled
Если служба недоступна, она может передать прогнозируемое значение задержки перед следующей повторной попыткой в заголовке ответа Retry-After или другом пользовательском заголовке. Службы также отправляют дополнительную информацию в виде пользовательских заголовков или внедренной в содержимое ответа.
Не повторяйте коды состояния, представляющие ошибки клиента (ошибки в диапазоне 4xx), за исключением времени ожидания запроса 408 и 429 слишком много запросов.
Тщательно протестируйте свои стратегии и механизмы повторов для различных условий, например, указав другую сеть и с различными нагрузками системы.

Стратегия повторов

Ниже приведены типичные виды интервалов стратегий повтора.

Экспоненциальная. Политика повторов, основанная на выполнении указанного числа повторных попыток и использующая случайный экспоненциальный пассивный метод для определения интервала между повторными попытками. Например:

var random = new Random();

var delta = (int)((Math.Pow(2.0, currentRetryCount) - 1.0) *
            random.Next((int)(this.deltaBackoff.TotalMilliseconds * 0.8),
            (int)(this.deltaBackoff.TotalMilliseconds * 1.2)));
var interval = (int)Math.Min(checked(this.minBackoff.TotalMilliseconds + delta),
                this.maxBackoff.TotalMilliseconds);
retryInterval = TimeSpan.FromMilliseconds(interval);

Добавочная. Стратегия повторов с указанным числом повторных попыток и добавочным интервалом между повторными попытками. Например:
```
retryInterval = TimeSpan.FromMilliseconds(this.initialInterval.TotalMilliseconds +
                (this.increment.TotalMilliseconds * currentRetryCount));
```
Линейный повтор. Политика повторов, выполняющая указанное число повторных попыток и использующая указанный фиксированный интервал времени между повторными попытками. Например:
```
retryInterval = this.deltaBackoff;
```

Обработка временного сбоя с помощью Polly

Библиотека Polly предназначена для программной обработки повторных попыток и стратегий автоматического прерывания. Проект Polly является частью .NET Foundation. Для служб, где клиент не поддерживает повторные попытки в собственном коде, Polly является допустимой альтернативой и избегает необходимости писать пользовательский код повторных попыток, который может быть трудно реализовать правильно. Polly также поддерживает трассировку возникающих ошибок, что позволяет вести журнал повторных попыток.

Следующие шаги

Устойчивость подключения Entity Framework

Поделиться через

Руководство по повторным попыткам для служб Azure

Microsoft Entra ID

Механизм повтора

Руководство по использованию механизма повторов

Следующие шаги

Azure Cosmos DB

Механизм повтора

Телеметрия

Data Lake Store

Механизм повтора

Телеметрия

Event Hubs

Механизм повтора

Пример

Следующие шаги

Центр Интернета вещей

Механизм повтора

Настройки политики

Следующие шаги

Кэш Azure для Redis

Механизм повтора

Настройки политики

Руководство по использованию механизма повторов

Телеметрия

Примеры

Следующие шаги

Поиск Azure

Механизм повтора

Телеметрия

Cлужебная шина

Механизм повтора

Руководство по использованию механизма повторов

Телеметрия

Пример

Следующие шаги

Service Fabric

Следующие шаги

Использование Базы данных SQL с ADO.NET

Механизм повтора

Руководство по использованию механизма повторов

Примеры

Следующие шаги

Использование Базы данных SQL с Entity Framework 6

Механизм повтора

Настройки политики

Руководство по использованию механизма повторов

Примеры

Использование Базы данных SQL с Entity Framework Core

Механизм повтора

Примеры

Хранилище Azure

Большие двоичные объекты, очереди и файлы

Поддержка таблиц

Механизм повтора

Настройки политики

RetryMode

Телеметрия

Примеры

Общие рекомендации по использованию REST и механизма повторов

Стратегия повторов

Обработка временного сбоя с помощью Polly

Следующие шаги

Обратная связь

Дополнительные ресурсы