Ескертпе
Бұл бетке кіру үшін қатынас шегін айқындау қажет. Жүйеге кіруді немесе каталогтарды өзгертуді байқап көруге болады.
Бұл бетке кіру үшін қатынас шегін айқындау қажет. Каталогтарды өзгертуді байқап көруге болады.
Любое приложение, работающее в облаке или взаимодействующее с удаленными службами и ресурсами, должно иметь возможность обрабатывать временные ошибки. Обычно эти приложения могут столкнуться с ошибками из-за мгновенной потери сетевого подключения, времени ожидания запроса, когда служба или ресурс занята или другие факторы. Разработчики должны создавать приложения для прозрачной обработки временных сбоев, чтобы повысить стабильность и устойчивость.
В этой статье вы узнаете, как использовать клиентская библиотека служба хранилища 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_connectretry_readи retry_status используются для подсчета различных типов ошибок. Оставшееся число повторных попыток вычисляется как минимум следующих значений: retry_total, , retry_connectretry_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. Полный список статей руководства разработчика см. в статье о создании приложения.
- Рекомендации по архитектуре и общие рекомендации по политикам повторных попыток см. в разделе "Обработка временных ошибок".
- Рекомендации по реализации шаблона повторных попыток для временных сбоев см . в шаблоне повторных попыток.