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

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

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

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

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

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

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

Свойство Тип Описание Значение по умолчанию
Задержка TimeSpan Задержка между попытками повторных попыток для фиксированного подхода или задержки, на которой выполняется базовый расчет для обратного подхода. Если служба предоставляет заголовок ответа Retry-After, следующая повторная попытка задерживается по длительности, указанной значением заголовка. 0,8 секунды
MaxDelay TimeSpan Максимальная допустимая задержка между попытками повторных попыток, когда служба не предоставляет заголовок ответа Retry-After. Если служба предоставляет заголовок ответа Retry-After, следующая повторная попытка задерживается по длительности, указанной значением заголовка. 1 минута
MaxRetries INT Максимальное количество повторных попыток перед прекращением. 5 (см. примечание)
Режим RetryMode Подход, используемый для расчета интервалов повторов. Экспоненциальный
Тайм-аут сети 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. Полный список статей руководства разработчика см. в статье о создании приложения.
  • Рекомендации по архитектуре и общие рекомендации по политикам повторных попыток см. в разделе "Обработка временных ошибок".
  • Рекомендации по реализации шаблона повторных попыток для временных сбоев см. в разделе Шаблон повторных попыток.