Implémenter une stratégie de nouvelles tentatives pour .NET
Toute application qui s’exécute dans le cloud ou communique avec les services et ressources distants doit être en mesure de gérer les erreurs temporaires. Il est courant que ces applications rencontrent des erreurs en raison d’une perte momentanée de connectivité réseau, d’un délai d’expiration de requête lorsqu’un service ou une ressource est occupé ou d’autres facteurs. Les développeurs doivent créer des applications pour gérer les erreurs temporaires de manière transparente afin d’améliorer la stabilité et la résilience.
Dans cet article, vous découvrez comment utiliser les bibliothèques de client Stockage Azure pour .NET afin de configurer une stratégie de nouvelles tentatives pour une application qui se connecte à Stockage Blob Azure. Les stratégies de nouvelles tentatives définissent la façon dont l’application gère les demandes ayant échoué et doivent toujours être ajustées pour répondre aux exigences métier de l’application et à la nature de l’échec.
Configurer les options de nouvelles tentatives
Les stratégies de nouvelles tentatives pour le stockage d’objets blob sont configurées par programme, offrant un contrôle sur la façon dont les options de nouvelle tentative sont appliquées à diverses demandes de service et scénarios. Par exemple, une application web qui émet des demandes en fonction de l’interaction utilisateur peut implémenter une stratégie avec moins de nouvelles tentatives et des retards plus courts pour augmenter la réactivité et avertir l’utilisateur lorsqu’une erreur se produit. Par ailleurs, une application ou un composant exécutant des demandes de traitement par lots en arrière-plan peut augmenter le nombre de nouvelles tentatives et utiliser une stratégie d’interruption exponentielle pour permettre la fin de la demande.
Le tableau suivant présente les propriétés de la classe RetryOptions, ainsi que leur type, une brève description et leur valeur par défaut si vous n’apportez aucune modification. Vous devez régler la valeur de ces propriétés de manière proactive pour répondre aux besoins de votre application.
| Propriété | Type | Description | Valeur par défaut |
|---|---|---|---|
| Retard | TimeSpan | Délai entre les nouvelles tentatives pour une approche fixe, ou délai sur lequel baser les calculs pour une approche reposant sur un backoff. Si le service fournit un en-tête de réponse Retry-After, la nouvelle tentative suivante est reportée de la durée spécifiée par la valeur d’en-tête. | 0,8 seconde |
| MaxDelay | TimeSpan | Délai maximal autorisé entre les nouvelles tentatives lorsque le service ne fournit pas d’en-tête de réponse Retry-After. Si le service fournit un en-tête de réponse Retry-After, la nouvelle tentative suivante est reportée de la durée spécifiée par la valeur d’en-tête. | 1 minute |
| MaxRetries | int | Nombre maximal de nouvelles tentatives avant abandon. | 5 (voir la remarque) |
| Mode | RetryMode | Approche à utiliser pour calculer les délais de nouvelle tentative. | Exponentielle |
| NetworkTimeout | TimeSpan | Délai d’expiration appliqué à une opération réseau individuelle. | 100 secondes |
Remarque
StorageClientOptions augmente la valeur par défaut pour MaxRetries de 3 à 5. Toutes les autres propriétés ont les mêmes valeurs par défaut que RetryOptions.
Dans cet exemple de code pour Stockage Blob, nous allons configurer les options de nouvelles tentatives dans la propriété Retry de la classe BlobClientOptions. Ensuite, nous créons un objet client pour le service blob à l’aide des options de nouvelles tentatives.
// 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);
Dans cet exemple, chaque demande de service émise à partir de l’objet BlobServiceClient utilise les options de nouvelles tentatives définies dans l’objet BlobClientOptions. Vous pouvez configurer différentes stratégies de nouvelles tentatives pour les clients de service en fonction des besoins de votre application.
Utiliser la géoredondance pour améliorer la résilience des applications
Si votre application nécessite une haute disponibilité et une plus grande résilience contre les défaillances, vous pouvez tirer parti des options de géoredondance de stockage Azure dans le cadre de votre stratégie de nouvelle tentative. Les comptes de stockage configurés pour la réplication géoredondante sont répliqués de manière synchrone dans la région primaire, puis répliqués de manière asynchrone dans une région secondaire à des centaines de kilomètres.
Stockage Azure offre deux options pour la réplication géoredondante : le stockage géoredondant (GRS) et le stockage géoredondant interzone (GZRS). Outre l’activation de la géoredondance pour votre compte de stockage, vous devez également configurer l’accès en lecture aux données de la région secondaire. Pour savoir comment modifier les options de réplication de votre compte de stockage, consultez Modifier la façon dont un compte de stockage est répliqué.
Dans cet exemple, nous définissons la propriété GeoRedundantSecondaryUri dans BlobClientOptions. Si cette propriété est définie, l’URI secondaire est utilisé pour GET ou HEAD requêtes pendant les nouvelles tentatives. Si le statut de la réponse de l’URI secondaire est 404, les tentatives ultérieures de réponse à la demande n’utilisent plus l’URI secondaire, car ce code de statut indique que la ressource ne s’y est peut-être pas encore propagée. Dans le cas contraire, les nouvelles tentatives alternent entre l’URI principal et l’URI secondaire.
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);
Les applications qui utilisent la géoredondance doivent garder à l’esprit certaines considérations de conception spécifiques. Pour en savoir plus, voir Utiliser la géoredondance pour concevoir des applications hautement disponibles.
Étapes suivantes
- Cet article fait partie du guide du développeur Stockage Blob pour .NET. Consultez la liste complète des articles du guide pour les développeurs à la page Générer votre application.
- Pour obtenir des conseils architecturaux et des bonnes pratiques générales pour les stratégies de nouvelles tentatives, consultez Gestion des erreurs temporaires.
- Pour obtenir des conseils sur l’implémentation d’un modèle de nouvelles tentatives pour les échecs temporaires, consultez Modèle de nouvelle tentative.