Реализация политики повторных попыток с помощью Python
Любое приложение, работающее в облаке или взаимодействующее с удаленными службами и ресурсами, должно иметь возможность обрабатывать временные ошибки. Обычно эти приложения могут столкнуться с ошибками из-за мгновенной потери сетевого подключения, времени ожидания запроса, когда служба или ресурс занята или другие факторы. Разработчики должны создавать приложения для прозрачной обработки временных сбоев, чтобы повысить стабильность и устойчивость.
В этой статье вы узнаете, как использовать клиентская библиотека служба хранилища Azure для Python для настройки политики повторных попыток для приложения, подключающегося к Хранилище BLOB-объектов Azure. Политики повторных попыток определяют, как приложение обрабатывает неудачные запросы, и всегда должны быть настроены на соответствие бизнес-требованиям приложения и характеру сбоя.
Настройка параметров повтора
Политики повторных попыток для хранилища BLOB-объектов настраиваются программным способом, предлагая контроль над применением параметров повторных попыток к различным запросам и сценариям службы. Например, веб-приложение, которое выдает запросы на основе взаимодействия с пользователем, может реализовать политику с меньшим количеством повторных попыток и более короткими задержками, чтобы повысить скорость реагирования и уведомить пользователя о возникновении ошибки. Кроме того, приложение или компонент, выполняющий пакетные запросы в фоновом режиме, может увеличить количество повторных попыток и использовать экспоненциальную стратегию обратного выхода, чтобы разрешить успешное выполнение запроса.
Чтобы настроить политику повторных попыток для запросов клиентов, можно выбрать один из следующих подходов:
- Используйте значения по умолчанию: политика повторных попыток по умолчанию для клиентской библиотеки служба хранилища Azure для Python — это экземпляр Экспоненциального повтора со значениями по умолчанию. Если политика повторных попыток не указана, используется политика повторных попыток по умолчанию.
- Передайте значения в качестве ключевых слов конструктору клиента: при создании клиентского объекта службы можно передать значения для свойств политики повтора в качестве аргументов ключевых слов. Этот подход позволяет настроить политику повторных попыток для клиента и полезен, если вам нужно настроить только несколько параметров.
- Создайте экземпляр класса политики повторных попыток: можно создать экземпляр класса ExponentialRetry или LinearRetry и задать свойства для настройки политики повторных попыток. Затем вы можете передать экземпляр конструктору клиента, чтобы применить политику повторных попыток ко всем запросам службы.
В следующей таблице показаны все свойства, которые можно использовать для настройки политики повторных попыток. Любое из этих свойств можно передать в качестве ключевых слов конструктору клиента, но некоторые из них доступны только для использования с экземпляром или LinearRetry
экземпляромExponentialRetry
. Эти ограничения отмечены в таблице, а также значения по умолчанию для каждого свойства, если вы не вносите изменений. Необходимо упреждать настройку значений этих свойств в соответствии с потребностями приложения.
Свойство | Type | Описание | Default value | Экспоненциальная повторная попытка | Линейная повторная попытка |
---|---|---|---|---|---|
retry_total |
INT | Максимальное число попыток. | 3 | Да | Да |
retry_connect |
INT | Максимальное количество повторных попыток подключения | 3 | Да | Да |
retry_read |
INT | Максимальное количество повторных попыток чтения | 3 | Да | Да |
retry_status |
INT | Максимальное количество повторных попыток состояния | 3 | Да | Да |
retry_to_secondary |
bool | Следует ли запрашивать запрос на вторичную конечную точку, если это возможно. Используйте этот параметр только для учетных записей хранения с поддержкой геоизбыточного репликации, например RA-GRS или RA-GZRS. Кроме того, необходимо убедиться, что ваше приложение может обрабатывать потенциально устаревшие данные. | False |
Да | Да |
initial_backoff |
INT | Начальный интервал обратного выхода (в секундах) для первого повтора. Применяется только к экспоненциальной стратегии обратного выхода. | 15 секунд | Да | Нет |
increment_base |
INT | Базовая (в секундах) для увеличения initial_backoff после первой попытки. Применяется только к экспоненциальной стратегии обратного выхода. | 3 секунды | Да | Нет |
backoff |
INT | Интервал обратной передачи (в секундах) между каждой повторным попыткой. Применяется только к линейной стратегии отката. | 15 секунд | No | Да |
random_jitter_range |
INT | Число (в секундах), указывающее диапазон для jitter/randomize для интервала отката. Например, значение random_jitter_range 3 означает, что интервал отступа x может отличаться от x+3 до x-3. |
3 секунды | Да | Да |
Примечание.
Свойства retry_connect
retry_read
и retry_status
используются для подсчета различных типов ошибок. Оставшееся число повторных попыток вычисляется как минимум следующих значений: retry_total
, , retry_connect
retry_read
и retry_status
. Из-за этого параметр может не иметь эффекта, retry_total
если вы также не задали другие свойства. В большинстве случаев можно задать для всех четырех свойств одно и то же значение, чтобы обеспечить максимальное количество повторных попыток. Однако эти свойства следует настроить на основе конкретных потребностей приложения.
В следующих разделах показано, как настроить политику повторных попыток с помощью различных подходов:
- Использование политики повторных попыток по умолчанию
- Создание политики экспоненциальных повторных попыток
- Создание политики linearRetry
Использование политики повторных попыток по умолчанию
Политика повторных попыток по умолчанию для клиентской библиотеки служба хранилища Azure для Python — это экземпляр ExponentialRetry со значениями по умолчанию. Если политика повторных попыток не указана, используется политика повторных попыток по умолчанию. Вы также можете передать любые свойства конфигурации в качестве аргументов ключевых слов при создании клиентского объекта для службы.
В следующем примере кода показано, как передать значение свойства retry_total
в качестве аргумента ключевого слова при создании клиентского объекта для службы BLOB-объектов. В этом примере клиентский объект использует политику повторных попыток по умолчанию со retry_total
свойством и другими свойствами счетчика повторных попыток, равными 5:
# TODO: Replace <storage-account-name> with your actual storage account name
account_url = "https://<storage-account-name>.blob.core.windows.net"
credential = DefaultAzureCredential()
# Create the BlobServiceClient object with retry options
blob_service_client = BlobServiceClient(account_url, credential, retry_total=5,
retry_connect=5, retry_read=5, retry_status=5)
Создание политики экспоненциальных повторных попыток
Политику повторных попыток можно настроить, создав экземпляр ExponentialRetry и передав экземпляр в конструктор клиента с помощью аргумента ключевого retry_policy
слова. Этот подход может быть полезным, если необходимо настроить несколько свойств или несколько политик для разных клиентов.
В следующем примере кода показано, как настроить параметры повторных попыток с помощью экземпляра ExponentialRetry
. В этом примере установлено initial_backoff
значение 10 секунд, increment_base
4 секунды и retry_total
3 повторных попыток:
# TODO: Replace <storage-account-name> with your actual storage account name
account_url = "https://<storage-account-name>.blob.core.windows.net"
credential = DefaultAzureCredential()
# Specify retry policy parameters
retry = ExponentialRetry(initial_backoff=10, increment_base=4, retry_total=3)
# Create the BlobServiceClient object
blob_service_client = BlobServiceClient(account_url, credential, retry_policy=retry)
Создание политики linearRetry
Политику повторных попыток можно настроить, создав экземпляр LinearRetry и передав экземпляр в конструктор клиента с помощью аргумента ключевого retry_policy
слова. Этот подход может быть полезным, если необходимо настроить несколько свойств или несколько политик для разных клиентов.
В следующем примере кода показано, как настроить параметры повторных попыток с помощью экземпляра LinearRetry
. В этом примере установлено backoff
значение 10 секунд, retry_total
3 повторных попыток и retry_to_secondary
:True
# TODO: Replace <storage-account-name> with your actual storage account name
account_url = "https://<storage-account-name>.blob.core.windows.net"
credential = DefaultAzureCredential()
# Specify retry policy parameters
retry = LinearRetry(backoff=10, retry_total=3, retry_to_secondary=True)
# Create the BlobServiceClient object
blob_service_client = BlobServiceClient(account_url, credential, retry_policy=retry)
Следующие шаги
- Эта статья является частью руководства разработчика хранилища BLOB-объектов для Python. Полный список статей руководства разработчика см. в статье о создании приложения.
- Рекомендации по архитектуре и общие рекомендации по политикам повторных попыток см. в разделе "Обработка временных ошибок".
- Рекомендации по реализации шаблона повторных попыток для временных сбоев см . в шаблоне повторных попыток.