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

Реализация политики повторных попыток с помощью .NET

  • Статья

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

В этой статье вы узнаете, как использовать клиентская библиотека служба хранилища Azure для .NET для настройки политики повторных попыток для приложения, подключающегося к Хранилище BLOB-объектов Azure. Политики повторных попыток определяют, как приложение обрабатывает неудачные запросы, и всегда должны быть настроены на соответствие бизнес-требованиям приложения и характеру сбоя.

Настройка параметров повтора

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

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

Свойство Type Описание Default value
Задержка TimeSpan Задержка между попытками повторных попыток для фиксированного подхода или задержки, на которой выполняется базовый расчет для обратного подхода. Если служба предоставляет заголовок ответа Retry-After, следующая повторная попытка задерживается по длительности, указанной значением заголовка. 0,8 секунды
MaxDelay TimeSpan Максимальная допустимая задержка между попытками повторных попыток, когда служба не предоставляет заголовок ответа Retry-After. Если служба предоставляет заголовок ответа Retry-After, следующая повторная попытка задерживается по длительности, указанной значением заголовка. 1 минута
MaxRetries INT Максимальное количество попыток повторных попыток перед отказом. 5 (см. примечание)
Режим RetryMode Режим, используемый для расчета интервалов повтора. Экспоненциально
NetworkTimeout TimeSpan Время ожидания, применяемое к отдельной сетевой операции. 100 секунд

Примечание.

StorageClientOptions увеличивает значение по умолчанию от MaxRetries 3 до 5. Все остальные свойства имеют те же значения по умолчанию, что RetryOptionsи .

В этом примере кода для хранилища BLOB-объектов мы настраиваем параметры повторных попыток в свойстве Retry класса BlobClientOptions . Затем мы создадим клиентский объект для службы BLOB-объектов с помощью параметров повтора.

// Provide the client configuration options for connecting to Azure Blob Storage
BlobClientOptions blobOptions = new BlobClientOptions()
{
    Retry = {
        Delay = TimeSpan.FromSeconds(2),
        MaxRetries = 5,
        Mode = RetryMode.Exponential,
        MaxDelay = TimeSpan.FromSeconds(10),
        NetworkTimeout = TimeSpan.FromSeconds(100)
    },
};

BlobServiceClient blobServiceClient = new BlobServiceClient(
    accountUri,
    new DefaultAzureCredential(),
    blobOptions);

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

Использование геоизбыточности для повышения устойчивости приложений

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

Служба хранилища Azure предлагает два варианта для геоизбыточной репликации данных: геоизбыточное хранилище (GRS) и хранилище, избыточное между зонами (GZRS). Помимо включения геоизбыточности для учетной записи хранения, необходимо также настроить доступ на чтение к данным в дополнительном регионе. Сведения об изменении параметров репликации для учетной записи хранения см. в статье "Изменение репликации учетной записи хранения".

В этом примере мы зададим свойство GeoRedundantSecondaryUri в BlobClientOptions. Если это свойство задано, вторичный URI используется для GET или HEAD запрашивается во время повторных попыток. Если состояние ответа из вторичного URI равно 404, последующие повторные попытки запроса еще не используют дополнительный универсальный код ресурса (URI), так как этот код состояния указывает, что ресурс еще не распространился. В противном случае последующие повторные попытки будут повторяться между первичным и вторичным универсальным кодом ресурса (URI).

Uri secondaryAccountUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/");

// Provide the client configuration options for connecting to Azure Blob Storage
BlobClientOptions blobOptionsGRS = new BlobClientOptions()
{
    Retry = {
        Delay = TimeSpan.FromSeconds(2),
        MaxRetries = 5,
        Mode = RetryMode.Exponential,
        MaxDelay = TimeSpan.FromSeconds(10),
        NetworkTimeout = TimeSpan.FromSeconds(100)
    },

    // Set the secondary storage URI
    GeoRedundantSecondaryUri = secondaryAccountUri
};

BlobServiceClient blobServiceClient = new BlobServiceClient(
    accountUri,
    new DefaultAzureCredential(),
    blobOptionsGRS);

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

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

  • Эта статья является частью руководства разработчика хранилища BLOB-объектов для .NET. Полный список статей руководства разработчика см. в статье о создании приложения.
  • Рекомендации по архитектуре и общие рекомендации по политикам повторных попыток см. в разделе "Обработка временных ошибок".
  • Рекомендации по реализации шаблона повторных попыток для временных сбоев см . в шаблоне повторных попыток.