Indicazioni sulla ripetizione dei tentativi per i servizi di Azure

La maggior parte dei servizi di Azure e degli SDK client include un meccanismo di ripetizione dei tentativi. Ogni servizio, tuttavia, presenta caratteristiche e requisiti diversi e, quindi, ogni meccanismo di ripetizione dei tentativi è ottimizzato per il servizio specifico in cui è incorporato. Questa guida riepiloga le funzionalità del meccanismo di ripetizione dei tentativi per la maggior parte dei servizi di Azure e include informazioni utili per usare, adattare o estendere il meccanismo di ripetizione dei tentativi per tale servizio.

Per indicazioni generali sulla gestione degli errori temporanei e sulla ripetizione dei tentativi di eseguire connessioni e operazioni su servizi e risorse, vedere Indicazioni generali per la ripetizione di tentativi.

La tabella seguente riepiloga le caratteristiche dei meccanismi di ripetizione dei tentativi associati ai servizi di Azure descritti in questo articolo.

Servizio Funzionalità per la ripetizione di tentativi Configurazione dei criteri Scope Funzionalità di telemetria
Microsoft Entra ID Native nella libreria MSAL Incorporata nella libreria MSAL Internal None
Azure Cosmos DB Native nel servizio Non configurabili Generale TraceSource
Data Lake Store Native nel client Non configurabili Singole operazioni None
Hub eventi Native nel client Programmatica Client None
Hub IoT Native nell'SDK client Programmatica Client None
Cache Redis di Azure Native nel client Programmatica Client TextWriter
Ricerca Native nel client Programmatica Client ETW o personalizzato
Bus di servizio Native nel client Programmatica Gestore dello spazio dei nomi, factory di messaggistica e client ETW
Service Fabric Native nel client Programmatica Client None
Database SQL con ADO.NET Polly Dichiarativa e a livello di codice Singole istruzioni o blocchi di codice Personalizzata
Database SQL con Entity Framework Native nel client Programmatica Globale per AppDomain None
Database SQL con Entity Framework Core Native nel client Programmatica Globale per AppDomain None
Storage Native nel client Programmatica Client e singole operazioni TraceSource

Nota

Per la maggior parte dei meccanismi di ripetizione dei tentativi predefiniti di Azure, non è attualmente possibile applicare criteri di ripetizione differenti per diversi tipi di errori o eccezioni. È necessario configurare un criterio che fornisca prestazioni e disponibilità medie ottimali. I criteri possono essere successivamente ottimizzati analizzando i file di log per determinare i tipi di errori temporanei che si sono verificati.

Microsoft Entra ID

Microsoft Entra ID è una soluzione cloud completa per la gestione delle identità e degli accessi che combina i servizi directory di base, la governance avanzata delle identità, la sicurezza e la gestione degli accessi alle applicazioni. Microsoft Entra ID offre inoltre agli sviluppatori una piattaforma di gestione delle identità per fornire il controllo di accesso alle applicazioni, in base a criteri e regole centralizzati.

Nota

Per informazioni sulla ripetizione dei tentativi negli endpoint dell'identità del servizio gestita, vedere Come usare un'identità del servizio gestita di una macchina virtuale di Azure per l'acquisizione di token.

Meccanismo di ripetizione dei tentativi

Esiste un meccanismo di ripetizione dei tentativi predefinito per Microsoft Entra ID in Microsoft Authentication Library (MSAL). Per evitare blocchi imprevisti, è consigliabile che le librerie di terze parti e il codice dell'applicazione non ripetano i tentativi di connessione non riusciti, ma consentano a MSAL di gestire i tentativi.

Linee guida sull'uso dei criteri di ripetizione dei tentativi

Quando si usa Microsoft Entra ID, prendere in considerazione le linee guida seguenti:

  • Quando possibile, usare la libreria MSAL e il supporto predefinito per le ripetizioni dei tentativi.
  • Se si usa l'API REST per Microsoft Entra ID, ripetere l'operazione se il codice del risultato è 429 (Troppe richieste) o un errore nell'intervallo 5xx. Non riprovare per altri errori.
  • Per gli errori 429, riprovare solo dopo il tempo indicato nell'intestazione Retry-After.
  • Per gli errori 5xx, usare il backoff esponenziale, con il primo tentativo effettuato almeno 5 secondi dopo la risposta.
  • Non riprovare sugli errori diversi da 429 e 5xx.

Passaggi successivi

Azure Cosmos DB

Azure Cosmos DB è un database multimodelli completamente gestito che supporta dati JSON senza schema. Offre prestazioni affidabili e configurabili, consente l'elaborazione transazionale JavaScript nativa e, grazie alla scalabilità elastica, è ottimizzato per il cloud.

Meccanismo di ripetizione dei tentativi

Gli SDK di Azure Cosmos DB riprovano automaticamente in determinate condizioni di errore e le applicazioni utente sono incoraggiate ad avere criteri di ripetizione dei tentativi. Vedere la guida alla progettazione di applicazioni resilienti con Azure Cosmos DB SDK per un elenco completo delle condizioni di errore e quando riprovare.

Telemetria

A seconda del linguaggio dell'applicazione, la diagnostica e i dati di telemetria vengono esposti come log o proprietà alzate di livello nelle risposte dell'operazione. Per altre informazioni, vedere la sezione "Acquisire la diagnostica" in Azure Cosmos DB C# SDK e Azure Cosmos DB Java SDK.

Data Lake Store

Data Lake Archiviazione Gen2 rende Archiviazione di Azure base per la creazione di data lake aziendali in Azure. Data Lake Archiviazione Gen2 consente di gestire facilmente grandi quantità di dati.

La libreria client di Archiviazione di Azure Files Data Lake include tutte le funzionalità necessarie per semplificare gli sviluppatori, i data scientist e gli analisti per archiviare i dati di qualsiasi dimensione, forma e velocità ed eseguire tutti i tipi di elaborazione e analisi tra piattaforme e linguaggi.

Meccanismo di ripetizione dei tentativi

DataLakeServiceClient consente di modificare le risorse e i file system del servizio Azure Data Lake. L'account di archiviazione fornisce lo spazio dei nomi di primo livello per il servizio Data Lake. Quando si crea il client, è possibile fornire le opzioni di configurazione client per la connessione al servizio Azure Data Lake (DataLakeClientOptions). DataLakeClientOptions include una proprietà Retry (ereditata da Azure.Core.ClientOptions) che può essere configurata (classe RetryOptions).

Telemetria

Il monitoraggio dell'uso e delle prestazioni di Archiviazione di Azure è una parte importante dell'operazionalizzazione del servizio. Gli esempi includono operazioni frequenti, operazioni con latenza elevata o operazioni che causano la limitazione lato servizio.

Tutti i dati di telemetria per l'account di archiviazione sono disponibili tramite Archiviazione di Azure log in Monitoraggio di Azure. Questa funzionalità integra l'account di archiviazione con Log Analytics e Hub eventi, consentendo anche di archiviare i log in un altro account di archiviazione. Per visualizzare l'elenco completo dei log delle metriche e delle risorse e dello schema associato, vedere Archiviazione di Azure riferimento ai dati di monitoraggio.

Hub eventi di

Hub eventi di Azure è un servizio di inserimento di dati di telemetria con iperscalabilità che raccoglie, trasforma e archivia milioni di eventi.

Meccanismo di ripetizione dei tentativi

Il comportamento di ripetizione dei tentativi nella libreria client dell'Hub eventi di Azure è controllato dalla proprietà RetryPolicy nella classe EventHubClient. Il criterio predefinito esegue nuovi tentativi con backoff esponenziale quando Hub eventi di Azure restituisce un oggetto temporaneo EventHubsException o .OperationCanceledException I criteri di ripetizione predefiniti per Hub eventi prevedono un massimo di 9 tentativi con un intervallo di backoff esponenziale di 30 secondi al massimo.

Esempio

EventHubClient client = EventHubClient.CreateFromConnectionString("[event_hub_connection_string]");
client.RetryPolicy = RetryPolicy.Default;

Passaggi successivi

libreria client Hub eventi di Azure per .NET

Hub IoT

Hub IoT di Azure è un servizio per la connessione, il monitoraggio e la gestione di dispositivi per lo sviluppo di applicazioni Internet delle cose (IoT).

Meccanismo di ripetizione dei tentativi

Azure IoT SDK per dispositivi è in grado di rilevare errori nella rete, nel protocollo o nell'applicazione. In base al tipo di errore, l'SDK verifica se è necessario eseguire un nuovo tentativo. Se l'errore è reversibile, l'SDK avvia un nuovo tentativo usando i criteri di ripetizione configurati.

I criteri di ripetizione predefiniti prevedono il backoff esponenziale con instabilità casuale, ma possono essere configurati.

Configurazione dei criteri

La configurazione dei criteri varia a seconda del linguaggio. Per altre informazioni, vedere hub IoT configurazione dei criteri di ripetizione dei tentativi.

Passaggi successivi

Cache Redis di Azure

La cache di Azure per Redis è un servizio cache a bassa latenza e di rapido accesso ai dati basato sulla nota Cache Redis open source. È sicuro, gestito da Microsoft ed è accessibile da qualsiasi applicazione in Azure.

Le indicazioni fornite in questa sezione presuppongono che si usi il client StackExchange.Redis per accedere alla cache. Nel sito Web di Redisè disponibile un elenco di altri client idonei, a cui possono essere associati vari meccanismi di ripetizione dei tentativi.

Il client StackExchange.Redis usa il multiplexing tramite una singola connessione. È consigliabile quindi creare un'istanza del client all'avvio dell'applicazione e usarla per tutte le operazioni eseguite sulla cache. In questo modo, la connessione alla cache viene eseguita una sola volta e tutte le indicazioni fornite in questa sezione fanno riferimento ai criteri di ripetizione dei tentativi definiti per la connessione iniziale e non per ogni operazione che accede alla cache.

Meccanismo di ripetizione dei tentativi

Il client StackExchange.Redis usa una classe di gestione della connessione configurata tramite un set di opzioni, che include:

  • ConnectRetry. Il numero di volte in cui una connessione non riuscita per la cache verrà ritentata.
  • ReconnectRetryPolicy. La strategia di ripetizione dei tentativi da usare.
  • ConnectTimeout. Il tempo di attesa massimo in millisecondi.

Configurazione dei criteri

I criteri di ripetizione dei tentativi vengono configurati a livello di codice impostando le opzioni per il client prima di connettersi alla cache. Questa operazione può essere eseguita creando un'istanza della classe ConfigurationOptions, popolandone le proprietà e passandola al metodo Connect.

Le classi incorporate supportano i ritardi lineari, ovvero il tempo d'intervallo costante, e i backoff esponenziali con intervalli di ripetizione dei tentativi casuali. È anche possibile creare un criterio di ripetizione dei tentativi personalizzato implementando l'interfaccia IReconnectRetryPolicy.

L'esempio seguente consente di configurare una strategia di ripetizione dei tentativi con backoff esponenziale.

var deltaBackOffInMilliseconds = TimeSpan.FromSeconds(5).TotalMilliseconds;
var maxDeltaBackOffInMilliseconds = TimeSpan.FromSeconds(20).TotalMilliseconds;
var options = new ConfigurationOptions
{
    EndPoints = {"localhost"},
    ConnectRetry = 3,
    ReconnectRetryPolicy = new ExponentialRetry(deltaBackOffInMilliseconds, maxDeltaBackOffInMilliseconds),
    ConnectTimeout = 2000
};
ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

In alternativa, è possibile specificare le opzioni sotto forma di stringa, per poi passarla al metodo Connect . La proprietà ReconnectRetryPolicy non può essere impostata in questo modo, solo tramite il codice.

var options = "localhost,connectRetry=3,connectTimeout=2000";
ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

È anche possibile specificare le opzioni direttamente durante la connessione alla cache.

var conn = ConnectionMultiplexer.Connect("redis0:6380,redis1:6380,connectRetry=3");

Per altre informazioni, vedere Configurazione di Stack Exchange Redis nella documentazione di StackExchange.Redis.

La tabella seguente mostra le impostazioni predefinite per i criteri di ripetizione dei tentativi incorporati.

Contesto Impostazione Valore predefinito:
(v 1.2.2)
significato
Opzioni configurazione ConnectRetry

ConnectTimeout

SyncTimeout

ReconnectRetryPolicy
3

Massimo 5000 ms più SyncTimeout
1000

LinearRetry 5.000 ms
Numero di nuovi tentativi di connessione durante l'operazione di connessione iniziale.
Timeout (ms) per operazioni di connessione. Non un intervallo tra i tentativi.
Tempo (ms) concesso per consentire operazioni sincrone.

Ripetizione dei tentativi ogni 5.000 ms.

Nota

Per le operazioni sincrone, è possibile aggiungere SyncTimeout alla latenza end-to-end, ma impostare un valore troppo basso può causare timeout eccessivi. Vedere Risoluzione dei problemi della cache di Azure per Redis. In generale, evitare di usare operazioni sincrone, usare invece operazioni asincrone. Per altre informazioni, vedere Pipeline e multiplexer.

Linee guida sull'uso dei criteri di ripetizione dei tentativi

Quando si usa la cache di Azure per Redis, tenere presente le linee guida seguenti:

  • Il client StackExchange Redis gestisce autonomamente i propri tentativi, ma solo se viene stabilita una connessione alla cache al primo avvio dell'applicazione. È possibile configurare il timeout della connessione, il numero di tentativi e il tempo tra i tentativi per stabilire questa connessione, ma il criterio di ripetizione dei tentativi non si applica alle operazioni sulla cache.
  • Anziché ricorrere a un numero elevato di tentativi, valutare la possibilità di eseguire il fallback accedendo alla sorgente originale dei dati.

Telemetria

È possibile raccogliere informazioni sulle connessioni, ma su non altre operazioni, usando un TextWriter.

var writer = new StringWriter();
ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

Seguito è riportato un esempio di output generato.

localhost:6379,connectTimeout=2000,connectRetry=3
1 unique nodes specified
Requesting tie-break from localhost:6379 > __Booksleeve_TieBreak...
Allowing endpoints 00:00:02 to respond...
localhost:6379 faulted: SocketFailure on PING
localhost:6379 failed to nominate (Faulted)
> UnableToResolvePhysicalConnection on GET
No masters detected
localhost:6379: Standalone v2.0.0, master; keep-alive: 00:01:00; int: Connecting; sub: Connecting; not in use: DidNotRespond
localhost:6379: int ops=0, qu=0, qs=0, qc=1, wr=0, sync=1, socks=2; sub ops=0, qu=0, qs=0, qc=0, wr=0, socks=2
Circular op-count snapshot; int: 0 (0.00 ops/s; spans 10s); sub: 0 (0.00 ops/s; spans 10s)
Sync timeouts: 0; fire and forget: 0; last heartbeat: -1s ago
resetting failing connections to retry...
retrying; attempts left: 2...
...

Esempi

L'esempio di codice seguente consente di configurare un intervallo costante, ovvero lineare, tra le ripetizioni di tentativi durante l'inizializzazione del client StackExchange.Redis. Questo esempio illustra come impostare la configurazione usando un'istanza ConfigurationOptions.

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using StackExchange.Redis;

namespace RetryCodeSamples
{
    class CacheRedisCodeSamples
    {
        public async static Task Samples()
        {
            var writer = new StringWriter();
            {
                try
                {
                    var retryTimeInMilliseconds = TimeSpan.FromSeconds(4).TotalMilliseconds; // delay between retries

                    // Using object-based configuration.
                    var options = new ConfigurationOptions
                                        {
                                            EndPoints = { "localhost" },
                                            ConnectRetry = 3,
                                            ReconnectRetryPolicy = new LinearRetry(retryTimeInMilliseconds)
                                        };
                    ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

                    // Store a reference to the multiplexer for use in the application.
                }
                catch
                {
                    Console.WriteLine(writer.ToString());
                    throw;
                }
            }
        }
    }
}

L'esempio successivo imposta la configurazione specificando le opzioni sotto forma di stringa. Il timeout di connessione è l'intervallo di tempo massimo di attesa per la connessione alla cache, non l'intervallo tra i tentativi. La proprietà ReconnectRetryPolicy può essere impostata solo dal codice.

using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using StackExchange.Redis;

namespace RetryCodeSamples
{
    class CacheRedisCodeSamples
    {
        public async static Task Samples()
        {
            var writer = new StringWriter();
            {
                try
                {
                    // Using string-based configuration.
                    var options = "localhost,connectRetry=3,connectTimeout=2000";
                    ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

                    // Store a reference to the multiplexer for use in the application.
                }
                catch
                {
                    Console.WriteLine(writer.ToString());
                    throw;
                }
            }
        }
    }
}

Per altri esempi, vedere la sezione relativa alla configurazione sul sito Web di progetto.

Passaggi successivi

Lo strumento Ricerca di Azure può essere usato per aggiungere sofisticate e avanzate funzionalità di ricerca in un sito Web o un'applicazione, ottimizzare i risultati di ricerca in modo semplice e rapido e creare avanzati modelli di classificazione.

Meccanismo di ripetizione dei tentativi

Azure SDK per .NET include una libreria client di Azure.Search.Documents del team di Azure SDK equivalente funzionalmente alla libreria client precedente, Microsoft.Azure.Search.

Il comportamento di ripetizione dei tentativi in Microsoft.Azure.Search è controllato dal metodo SetRetryPolicy nelle classi SearchServiceClient e SearchIndexClient. I criteri predefiniti eseguono nuovi tentativi con backoff esponenziale quando Ricerca di Azure restituisce una risposta 5xx o 408 (Timeout della richiesta).

Il comportamento di ripetizione dei tentativi in Azure.Search.Documents è controllato da SearchClientOptions (fa parte del costruttore SearchClient) nella proprietà Retry, che appartiene alla classe Azure.Core.RetryOptions(dove sono disponibili tutte le configurazioni).

Telemetria

Tracciare con ETW o registrando un provider di traccia personalizzato. Per altre informazioni, consultare la documentazione di AutoRest.

Bus di servizio

Il bus di servizio è una piattaforma di messaggistica basata sul cloud che offre una funzione di scambio dei messaggi di tipo "loosely coupled" con alti livelli di scalabilità e resilienza per i componenti di un'applicazione (ospitata nel cloud o in locale).

Meccanismo di ripetizione dei tentativi

Lo spazio dei nomi e alcuni dei dettagli di configurazione dipendono dal pacchetto SDK client del bus di servizio usato:

Pacchetto Descrizione Spazio dei nomi
Azure.Messaging.ServiceBus libreria client bus di servizio di Azure per .NET Azure.Messaging.ServiceBus
WindowsAzure.ServiceBus Questo pacchetto è la libreria client del bus di servizio precedente. Richiede .NET Framework 4.5.2. Microsoft.Azure.ServiceBus

Linee guida sull'uso dei criteri di ripetizione dei tentativi

La ServiceBusRetryOptions proprietà specifica le opzioni di ripetizione dei tentativi per l'oggetto ServiceBusClient :

Impostazione Valore predefinito Significato
CustomRetryPolicy Criteri di ripetizione dei tentativi personalizzati da usare al posto dei singoli valori di opzione.
Ritardo 0,8 secondi Ritardo tra i tentativi di ripetizione per un approccio fisso o il ritardo su cui basare i calcoli per un approccio basato sul backoff.
MaxDelay 60 secondi Ritardo massimo consentito tra i tentativi.
MaxRetries 3 Numero massimo di tentativi prima di considerare l'operazione associata non riuscita.
Modalità Esponenziale Approccio da usare per calcolare i ritardi di ripetizione dei tentativi.
TryTimeout 60 secondi Durata massima di attesa del completamento di un singolo tentativo, sia che si tratti del tentativo iniziale o di un nuovo tentativo.

Impostare la Mode proprietà per configurare ServiceBusRetryMode con uno di questi valori:

Proprietà valore Descrizione
Esponenziale 1 I tentativi di ripetizione ritarderanno in base a una strategia di backoff, in cui ogni tentativo aumenterà la durata di attesa prima di riprovare.
Corretto 0 I tentativi vengono eseguiti a intervalli fissi; ogni ritardo è una durata coerente.

Esempio:

using Azure.Messaging.ServiceBus;

string connectionString = "<connection_string>";
string queueName = "<queue_name>";

// Because ServiceBusClient implements IAsyncDisposable, we'll create it
// with "await using" so that it is automatically disposed for us.
var options = new ServiceBusClientOptions();
options.RetryOptions = new ServiceBusRetryOptions
{
    Delay = TimeSpan.FromSeconds(10),
    MaxDelay = TimeSpan.FromSeconds(30),
    Mode = ServiceBusRetryMode.Exponential,
    MaxRetries = 3,
};
await using var client = new ServiceBusClient(connectionString, options);

Telemetria

bus di servizio raccoglie gli stessi tipi di dati di monitoraggio delle altre risorse di Azure. È possibile monitorare bus di servizio di Azure usando Monitoraggio di Azure.

Sono disponibili anche diverse opzioni per l'invio di dati di telemetria con le librerie client .NET bus di servizio.

Esempio

Nell'esempio di codice seguente viene illustrato come usare il Azure.Messaging.ServiceBus pacchetto per:

  • Impostare i criteri di ripetizione dei tentativi per un ServiceBusClient oggetto usando un nuovo ServiceBusClientOptionsoggetto .
  • Creare un nuovo messaggio con una nuova istanza di .ServiceBusMessage
  • Inviare un messaggio al bus di servizio usando il ServiceBusSender.SendMessageAsync(message) metodo .
  • Ricevere utilizzando , ServiceBusReceiverrappresentato come ServiceBusReceivedMessage oggetti .
// using Azure.Messaging.ServiceBus;

using Azure.Messaging.ServiceBus;

string connectionString = "<connection_string>";
string queueName = "queue1";

// Because ServiceBusClient implements IAsyncDisposable, we'll create it 
// with "await using" so that it is automatically disposed for us.
var options = new ServiceBusClientOptions();
options.RetryOptions = new ServiceBusRetryOptions
{
    Delay = TimeSpan.FromSeconds(10),
    MaxDelay = TimeSpan.FromSeconds(30),
    Mode = ServiceBusRetryMode.Exponential,
    MaxRetries = 3,
};
await using var client = new ServiceBusClient(connectionString, options);

// The sender is responsible for publishing messages to the queue.
ServiceBusSender sender = client.CreateSender(queueName);
ServiceBusMessage message = new ServiceBusMessage("Hello world!");

await sender.SendMessageAsync(message);

// The receiver is responsible for reading messages from the queue.
ServiceBusReceiver receiver = client.CreateReceiver(queueName);
ServiceBusReceivedMessage receivedMessage = await receiver.ReceiveMessageAsync();

string body = receivedMessage.Body.ToString();
Console.WriteLine(body);

Passaggi successivi

Service Fabric

La distribuzione di servizi affidabili in un cluster di Service Fabric protegge dalla maggior parte degli errori temporanei potenziali descritti in questo articolo. Tuttavia, alcuni errori temporanei sono comunque possibili. Ad esempio, il servizio di denominazione potrebbe essere all'interno di una modifica di routing quando rileva una richiesta, provocando la generazione di un'eccezione. Se la stessa richiesta arriva 100 millisecondi dopo, verrà probabilmente completata.

Service Fabric gestisce internamente questo tipo di errori temporanei. È possibile configurare alcune impostazioni tramite la classe OperationRetrySettings durante la configurazione dei servizi. Il seguente codice illustra un esempio. Nella maggior parte dei casi, questo non dovrebbe essere necessario e le impostazioni predefinite saranno appropriate.

FabricTransportRemotingSettings transportSettings = new FabricTransportRemotingSettings
{
    OperationTimeout = TimeSpan.FromSeconds(30)
};

var retrySettings = new OperationRetrySettings(TimeSpan.FromSeconds(15), TimeSpan.FromSeconds(1), 5);

var clientFactory = new FabricTransportServiceRemotingClientFactory(transportSettings);

var serviceProxyFactory = new ServiceProxyFactory((c) => clientFactory, retrySettings);

var client = serviceProxyFactory.CreateServiceProxy<ISomeService>(
    new Uri("fabric:/SomeApp/SomeStatefulReliableService"),
    new ServicePartitionKey(0));

Passaggi successivi

Database SQL con ADO.NET

Il database SQL, in questo caso, è un database SQL ospitato, di varie dimensioni, disponibile come servizio standard (condiviso) o premium (non condiviso).

Meccanismo di ripetizione dei tentativi

Il database SQL non offre il supporto incorporato per la ripetizione dei tentativi quando si accede ad esso con ADO.NET. Per determinare il motivo per cui una richiesta ha avuto esito negativo, è possibile usare i codici restituiti dalle richieste. Per altre informazioni sulla limitazione delle richieste del database SQL, vedere Limiti delle risorse del database SQL di Azure. Per un elenco dei codici di errore pertinenti, vedere Codici di errore SQL per le applicazioni client del database SQL.

È possibile usare la libreria Polly per implementare la ripetizione di tentativi per il database SQL. Vedere Gestione degli errori temporanei con Polly.

Linee guida sull'uso dei criteri di ripetizione dei tentativi

Quando si accede al database SQL con ADO.NET, tenere presente le linee guida seguenti:

  • Scegliere il tipo di servizio appropriato (condiviso o premium). Un'istanza condivisa può subire limitazioni o ritardi di connessione maggiori rispetto alla media perché può essere usata da altri tenant del server condiviso. Se sono necessarie prestazioni più prevedibili o affidabili operazioni di bassa latenza, valutare la possibilità di scegliere il tipo servizio premium.
  • Assicurarsi di eseguire i nuovi tentativi al livello o nell'ambito appropriato per evitare operazioni non idempotenti che possono causare incoerenze nei dati. In teoria, tutte le operazioni dovrebbero essere idempotenti in modo da poter essere ripetute senza causare incoerenze. In caso contrario, il nuovo tentativo deve essere eseguito a un livello o a un ambito che consente l'annullamento di tutte le modifiche correlate in caso di errore di un'operazione; ad esempio dall'interno di un ambito transazionale. Per altre informazioni, vedere l'articolo sul livello di accesso ai dati di Cloud Service Fundamentals e la gestione degli errori temporanei.
  • Una strategia a intervalli fissi non è consigliata per l'uso con database SQL di Azure ad eccezione degli scenari interattivi in cui sono presenti solo alcuni tentativi a intervalli brevi. Prendere invece in considerazione l'uso di una strategia di back-off esponenziale per la maggior parte degli scenari.
  • Quando si definiscono le connessioni, scegliere un valore appropriato per i timeout di connessione e dei comandi. Un timeout troppo breve può comportare errori di connessione prematuri quando il database è occupato, mentre un timeout troppo lungo può impedire che la logica di ripetizione dei tentativi funzioni correttamente, poiché l'intervallo di attesa prima che venga rilevata una connessione non riuscita è troppo lungo. Il valore del timeout è un componente della latenza end-to-end; viene aggiunto in modo efficace al ritardo dei tentativi specificato nei criteri di ripetizione dei tentativi per ogni tentativo.
  • Chiudere la connessione dopo alcuni tentativi, anche quando si usa una logica di ripetizione dei tentativi di back-off esponenziale e ripetere l'operazione in una nuova connessione. Se si ripete più volte la stessa operazione su un'unica connessione, infatti, è possibile che si verifichino problemi di connessione. Per altre informazioni su questa tecnica, vedere l'articolo sul livello di accesso ai dati di Cloud Service Fundamentals e la gestione degli errori temporanei.
  • Quando il pool di connessioni è in uso (impostazione predefinita) è possibile che la stessa connessione venga scelta dal pool, anche dopo la chiusura e la riapertura di una connessione. In tal caso, una tecnica per risolvere il problema consiste nel chiamare il metodo ClearPool della classe Sql Connessione ion per contrassegnare la connessione come non riutilizzabile. Questo metodo, tuttavia, deve essere adottato solo dopo vari tentativi di connessione non riusciti e solo quando è presente la classe di errori temporanei, come i timeout SQL (codice di errore -2), specifica delle connessioni difettose.
  • Se il codice di accesso ai dati usa transazioni avviate come istanze TransactionScope , la logica di ripetizione dei tentativi deve riaprire la connessione e avviare un nuovo ambito della transazione. Per questo motivo, il blocco di codice non irreversibile deve interessare l'intero ambito della transazione.

È consigliabile iniziare le operazioni di ripetizione dei tentativi usando le impostazioni seguenti. Queste impostazioni sono di utilizzo generico ed è quindi necessario monitorare le operazioni e personalizzare i valori in base allo scenario.

Contesto Latenza massima destinazione
esempio E2E
Strategia di ripetizione dei tentativi Impostazioni Valori Funzionamento
Interattivo, interfaccia utente
o in primo piano
2 secondi FixedInterval Conteggio tentativi
Intervallo tentativi
Primo tentativo rapido
3
500 ms
true
Tentativo di 1 - intervallo di 0 sec
Tentativo 2 - intervallo di 500 ms
Tentativo 3 - intervallo di 500 ms
Background
o batch
30 Secondi ExponentialBackoff Conteggio tentativi
Interruzione temporanea minima
Interruzione temporanea massima
Interruzione temporanea delta
Primo tentativo rapido
5
0 secondi
60 secondi
2 secondi
false
Tentativo di 1 - intervallo di 0 sec
Tentativo 2 - intervallo di ~2 sec
Tentativo 3 - intervallo di ~6 sec
Tentativo 4 - intervallo di ~14 sec
Tentativo 5 - intervallo di 30 sec

Nota

Gli obiettivi di latenza end-to-end presuppongono il timeout predefinito per le connessioni al servizio. Se si specifica un timeout di connessione più lungo, la latenza end-to-end verrà estesa di questo intervallo di tempo aggiuntivo per ogni nuovo tentativo.

Esempi

Questa sezione illustra come usare Polly per accedere al database SQL di Azure usando un set di criteri di ripetizione dei tentativi configurato nella classe Policy.

Il codice seguente illustra un metodo di estensione nella classe SqlCommand che richiama ExecuteAsync con backoff esponenziale.

public async static Task<SqlDataReader> ExecuteReaderWithRetryAsync(this SqlCommand command)
{
    GuardConnectionIsNotNull(command);

    var policy = Policy.Handle<Exception>().WaitAndRetryAsync(
        retryCount: 3, // Retry 3 times
        sleepDurationProvider: attempt => TimeSpan.FromMilliseconds(200 * Math.Pow(2, attempt - 1)), // Exponential backoff based on an initial 200 ms delay.
        onRetry: (exception, attempt) =>
        {
            // Capture some information for logging/telemetry.
            logger.LogWarn($"ExecuteReaderWithRetryAsync: Retry {attempt} due to {exception}.");
        });

    // Retry the following call according to the policy.
    await policy.ExecuteAsync<SqlDataReader>(async token =>
    {
        // This code is executed within the Policy

        if (conn.State != System.Data.ConnectionState.Open) await conn.OpenAsync(token);
        return await command.ExecuteReaderAsync(System.Data.CommandBehavior.Default, token);

    }, cancellationToken);
}

Questo metodo di estensione asincrona può essere usato come indicato di seguito.

var sqlCommand = sqlConnection.CreateCommand();
sqlCommand.CommandText = "[some query]";

using (var reader = await sqlCommand.ExecuteReaderWithRetryAsync())
{
    // Do something with the values
}

Passaggi successivi

Database SQL con Entity Framework 6

Il database SQL, in questo caso, è un database SQL ospitato, di varie dimensioni, disponibile come servizio standard (condiviso) o premium (non condiviso). Entity Framework, invece, è un mapper relazionale a oggetti che consente agli sviluppatori .NET di usare dati relazionali mediante oggetti specifici di dominio. Elimina la necessità di gran parte del codice di accesso ai dati che in genere gli sviluppatori devono scrivere.

Meccanismo di ripetizione dei tentativi

Quando si accede al database SQL con Entity Framework 6.0 o versione superiore, il supporto per la ripetizione di tentativi viene fornito attraverso un meccanismo denominato resilienza delle connessioni / logica di ripetizione dei tentativi. Di seguiti sono illustrate le caratteristiche principali del meccanismo di ripetizione dei tentativi:

  • L'astrazione primaria è l'interfaccia IDbExecutionStrategy . Questa interfaccia:
    • Definisce i metodi Execute sincroni e asincroni.
    • Definisce le classi che possono essere usate direttamente o configurate in un contesto di database come strategia predefinita, quindi mappate a un nome di provider o a un nome di provider e un nome di server. Se configurate in un contesto, i nuovi tentativi vengono eseguiti a livello di singole operazioni di database, che possono essere molteplici per una determinata operazione di contesto.
    • Definisce quando tentare di eseguire nuovamente una connessione non riuscita e in che modo.
  • Include diverse implementazioni predefinite dell'interfaccia IDbExecutionStrategy :
    • Predefinita: nessun nuovo tentativo.
    • Predefinita per il database SQL (automatica): nessun nuovo tentativo, ma controlla le eccezioni e ne esegue il wrapping con il suggerimento di usare la strategia relativa al database SQL.
    • Predefinita per il database SQL: esponenziale (ereditata dalla classe di base), combinata con la logica di rilevamento del database SQL.
  • Implementa una strategia di backoff esponenziale che include la sequenza casuale.
  • Le classi di ripetizione dei tentativi predefinite sono con stato e non sono thread-safe. Possono comunque essere riusate dopo il completamento dell'operazione corrente.
  • Se viene superato il numero di tentativi specificato, i risultati vengono inclusi in una nuova eccezione Non viene visualizzata l'eccezione corrente.

Configurazione dei criteri

Quando si accede al database SQL con Entity Framework 6.0, o versioni successive, è già disponibile il supporto per la ripetizione di tentativi. I criteri di ripetizione dei tentativi sono configurati a livello di codice. La configurazione non può essere modificata per ogni operazione.

Quando si configura una strategia di contesto come impostazione predefinita, è necessario specificare anche una funzione che consente di creare una nuova strategia su richiesta. Il codice seguente mostra come creare una classe di configurazione di nuovi tentativi che estende la classe di base DbConfiguration .

public class BloggingContextConfiguration : DbConfiguration
{
  public BlogConfiguration()
  {
    // Set up the execution strategy for SQL Database (exponential) with 5 retries and 4 sec delay
    this.SetExecutionStrategy(
         "System.Data.SqlClient", () => new SqlAzureExecutionStrategy(5, TimeSpan.FromSeconds(4)));
  }
}

È quindi possibile impostarla come strategia di ripetizione dei tentativi predefinita per tutte le operazioni usando il metodo SetConfiguration dell'istanza DbConfiguration all'avvio dell'applicazione. Per impostazione predefinita, Entity Framework rileverà e userà automaticamente questa classe di configurazione.

DbConfiguration.SetConfiguration(new BloggingContextConfiguration());

È possibile specificare la classe di configurazione di nuovi tentativi per un contesto specifico annotando la classe del contesto con un attributo DbConfigurationType . Tuttavia, se è presente una sola classe di configurazione, Entity Framework la userà anche senza dover annotare il contesto.

[DbConfigurationType(typeof(BloggingContextConfiguration))]
public class BloggingContext : DbContext

Se per determinate operazioni è necessario usare strategie di ripetizione dei tentativi diverse o si disabilita la ripetizione dei tentativi, è possibile creare una classe di configurazione che consente di sospendere o cambiare strategie impostando un flag in CallContext. Questo flag può essere usato dalla classe di configurazione per cambiare strategie o per disabilitare la strategia specificata e usare invece una strategia predefinita. Per altre informazioni, vedere l'articolo sulla strategia di esecuzione della sospensione (Entity Framework 6 e versioni successive).

Un'altra tecnica per usare strategie di ripetizione specifiche per singole operazioni consiste nel creare un'istanza della classe di strategia necessaria, fornire le impostazioni desiderate attraverso dei parametri e quindi richiamare il metodo ExecuteAsync.

var executionStrategy = new SqlAzureExecutionStrategy(5, TimeSpan.FromSeconds(4));
var blogs = await executionStrategy.ExecuteAsync(
    async () =>
    {
        using (var db = new BloggingContext("Blogs"))
        {
            // Acquire some values asynchronously and return them
        }
    },
    new CancellationToken()
);

Il modo più semplice per usare una classe DbConfiguration consiste nell'individuarla nello stesso assembly della classe DbContext. Tuttavia, questo non è appropriato quando lo stesso contesto è necessario in scenari diversi, ad esempio diverse strategie interattive e di ripetizione in background. Se i diversi contesti vengono eseguiti in AppDomain distinti, è possibile usare il supporto incorporato per specificare le classi di configurazione nel file di configurazione o impostarle in modo esplicito tramite codice. Se invece i diversi contesti devono essere eseguiti nello stesso AppDomain, sarà necessaria una soluzione personalizzata.

Per altre informazioni, vedere l'articolo sulla configurazione basata su codice (Entity Framework 6 o versione successiva).

La tabella seguente mostra le impostazioni predefinite per i criteri di ripetizione dei tentativi incorporati quando si usa Entity Framework 6.

Impostazione Valore predefinito Significato
Criteri Esponenziale Backoff esponenziale.
MaxRetryCount 5 Numero massimo di tentativi.
MaxDelay 30 secondi Ritardo massimo tra i tentativi. Questo valore non influisce sulla modalità di calcolo della serie di ritardi. Definisce solo un limite superiore.
DefaultCoefficient 1 secondo Coefficiente per il calcolo del backoff esponenziale. Questo valore non può essere modificato.
DefaultRandomFactor 1.1 Moltiplicatore usato per aggiungere un ritardo casuale per ogni voce. Questo valore non può essere modificato.
DefaultExponentialBase 2 Moltiplicatore usato per calcolare il ritardo successivo. Questo valore non può essere modificato.

Linee guida sull'uso dei criteri di ripetizione dei tentativi

Quando si accede al database SQL con Entity Framework 6, tenere presente le linee guida seguenti:

  • Scegliere il tipo di servizio appropriato (condiviso o premium). Un'istanza condivisa può subire limitazioni o ritardi di connessione maggiori rispetto alla media perché può essere usata da altri tenant del server condiviso. Se sono necessarie prestazioni prevedibili o affidabili operazioni di bassa latenza, valutare la possibilità di scegliere il tipo servizio premium.

  • Una strategia a intervalli fissi non è consigliata per l'uso con database SQL di Azure. bensì una strategia di backoff esponenziale, poiché il servizio può essere sovraccarico e intervalli più lunghi concedono più tempo per il ripristino del servizio.

  • Quando si definiscono le connessioni, scegliere un valore appropriato per i timeout di connessione e dei comandi. I timeout devono essere definiti in base alla progettazione della logica di business e tramite una serie di test. Potrebbe essere necessario modificare questi valori nel tempo man mano che i volumi dei dati o dei processi di business cambiano. Un timeout troppo breve può comportare errori di connessione prematuri quando il database è occupato, mentre un timeout troppo lungo può impedire che la logica di ripetizione dei tentativi funzioni correttamente, poiché l'intervallo di attesa prima che venga rilevata una connessione non riuscita è troppo lungo. Il valore del timeout è un componente della latenza end-to-end, anche se non è possibile determinare facilmente il numero di comandi che verranno eseguiti durante il salvataggio del contesto. È possibile modificare il timeout predefinito impostando la proprietà CommandTimeout dell'istanza DbContext.

  • Entity Framework supporta le configurazioni di ripetizione dei tentativi definite nei file di configurazione. Per ottenere la massima flessibilità in Azure, tuttavia, è opportuno valutare la possibilità di creare la configurazione a livello di codice all'interno dell'applicazione. I parametri specifici dei criteri di ripetizione dei tentativi, ad esempio il numero di tentativi e l'intervallo tra di essi, possono essere archiviati nel file di configurazione del servizio e usati in fase di esecuzione per creare i criteri appropriati. In questo modo è possibile modificare le impostazioni senza dover riavviare l'applicazione.

È consigliabile iniziare le operazioni di ripetizione dei tentativi usando le impostazioni seguenti. Non è possibile specificare il ritardo tra i tentativi (è fisso e generato come sequenza esponenziale). è possibile specificare solo i valori massimi, come illustrato di seguito, a meno che non sia stata creata una strategia di ripetizione dei tentativi personalizzata. Queste impostazioni sono di utilizzo generico ed è quindi necessario monitorare le operazioni e personalizzare i valori in base allo scenario.

Contesto Latenza massima destinazione
esempio E2E
Criterio di ripetizione Impostazioni Valori Funzionamento
Interattivo, interfaccia utente
o in primo piano
2 secondi Esponenziale MaxRetryCount
MaxDelay
3
750 ms
Tentativo di 1 - intervallo di 0 sec
Tentativo 2 - intervallo di 750 ms
Tentativo 3 - intervallo di 750 ms
Background
o batch
30 secondi Esponenziale MaxRetryCount
MaxDelay
5
12 secondi
Tentativo di 1 - intervallo di 0 sec
Tentativo 2 - intervallo di ~1 sec
Tentativo 3 - intervallo di ~3 sec
Tentativo 4 - intervallo di ~7 sec
Tentativo 5 - intervallo di 12 sec

Nota

Gli obiettivi di latenza end-to-end presuppongono il timeout predefinito per le connessioni al servizio. Se si specifica un timeout di connessione più lungo, la latenza end-to-end verrà estesa di questo intervallo di tempo aggiuntivo per ogni nuovo tentativo.

Esempi

L'esempio di codice seguente definisce una soluzione di accesso ai dati semplice che usa Entity Framework. Imposta una strategia di ripetizione dei tentativi specifica tramite la definizione di un'istanza di una classe denominata BlogConfiguration che estende DbConfiguration.

using System;
using System.Collections.Generic;
using System.Data.Entity;
using System.Data.Entity.SqlServer;
using System.Threading.Tasks;

namespace RetryCodeSamples
{
    public class BlogConfiguration : DbConfiguration
    {
        public BlogConfiguration()
        {
            // Set up the execution strategy for SQL Database (exponential) with 5 retries and 12 sec delay.
            // These values could be loaded from configuration rather than being hard-coded.
            this.SetExecutionStrategy(
                    "System.Data.SqlClient", () => new SqlAzureExecutionStrategy(5, TimeSpan.FromSeconds(12)));
        }
    }

    // Specify the configuration type if more than one has been defined.
    // [DbConfigurationType(typeof(BlogConfiguration))]
    public class BloggingContext : DbContext
    {
        // Definition of content goes here.
    }

    class EF6CodeSamples
    {
        public async static Task Samples()
        {
            // Execution strategy configured by DbConfiguration subclass, discovered automatically or
            // or explicitly indicated through configuration or with an attribute. Default is no retries.
            using (var db = new BloggingContext("Blogs"))
            {
                // Add, edit, delete blog items here, then:
                await db.SaveChangesAsync();
            }
        }
    }
}

Altri esempi sull'uso del meccanismo di ripetizione dei tentavi in Entity Framework sono disponibili in Resilienza della connessione/logica di ripetizione dei tentativi.

Database SQL con Entity Framework Core

Entity Framework Core è un mapper relazionale a oggetti che consente agli sviluppatori .NET Core di usare dati mediante oggetti specifici di dominio. Elimina la necessità di gran parte del codice di accesso ai dati che in genere gli sviluppatori devono scrivere. Questa versione di Entity Framework è stata scritta da zero e non eredita automaticamente tutte le funzionalità di EF6.x.

Meccanismo di ripetizione dei tentativi

Quando si accede al database SQL con Entity Framework Core, il supporto per la ripetizione di tentativi viene offerto attraverso un meccanismo denominato Resilienza della connessione. Resilienza connessione è stato introdotto in EF Core 1.1.0.

La principale astrazione è l'interfaccia IExecutionStrategy. La strategia di esecuzione per SQL Server, che include SQL Azure, riconosce i tipi di eccezione per cui è possibile ripetere i tentativi e dispone di impostazioni predefinite ragionevoli per un numero massimo ripetizione dei tentativi, intervalli tra di essi e così via.

Esempi

Il codice seguente abilita le ripetizioni automatiche di tentativi quando si configura l'oggetto DbContext, che rappresenta una sessione con il database.

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder
        .UseSqlServer(
            @"Server=(localdb)\mssqllocaldb;Database=EFMiscellaneous.ConnectionResiliency;Trusted_Connection=True;",
            options => options.EnableRetryOnFailure());
}

Il codice seguente illustra come eseguire una transazione con la ripetizione di tentativi automatica, usando una strategia di esecuzione. La transazione viene definita in un delegato. Se si verifica un errore temporaneo, la strategia di esecuzione chiamerà nuovamente il delegato.

using (var db = new BloggingContext())
{
    var strategy = db.Database.CreateExecutionStrategy();

    strategy.Execute(() =>
    {
        using (var transaction = db.Database.BeginTransaction())
        {
            db.Blogs.Add(new Blog { Url = "https://blogs.msdn.com/dotnet" });
            db.SaveChanges();

            db.Blogs.Add(new Blog { Url = "https://blogs.msdn.com/visualstudio" });
            db.SaveChanges();

            transaction.Commit();
        }
    });
}

Archiviazione di Azure

I servizi di archiviazione di Azure includono funzioni di archiviazione di BLOB, file e code di archiviazione.

BLOB, code e file

La classe ClientOptions è il tipo di base per tutti i tipi di opzioni client ed espone diverse opzioni client comuni, ad esempio Diagnostica, Nuovo tentativo, Trasporto. Per fornire le opzioni di configurazione client per la connessione ad Archiviazione code, BLOB e file di Azure, è necessario usare il tipo derivato corrispondente. Nell'esempio successivo si usa la classe QueueClientOptions (derivata da ClientOptions) per configurare la connessione di un client al servizio di accodamento di Azure. La proprietà Retry è il set di opzioni che possono essere specificate per determinare come eseguire i tentativi e come stabilire che un errore è idoneo per la ripetizione.

using System;
using System.Threading;
using Azure.Core;
using Azure.Identity;
using Azure.Storage;
using Azure.Storage.Queues;
using Azure.Storage.Queues.Models;

namespace RetryCodeSamples
{
    class AzureStorageCodeSamples {

        public async static Task Samples() {

               // Provide the client configuration options for connecting to Azure Queue Storage
                QueueClientOptions queueClientOptions = new QueueClientOptions()
                {
                    Retry = {
                    Delay = TimeSpan.FromSeconds(2),     //The delay between retry attempts for a fixed approach or the delay on which to base
                                                         //calculations for a backoff-based approach
                    MaxRetries = 5,                      //The maximum number of retry attempts before giving up
                    Mode = RetryMode.Exponential,        //The approach to use for calculating retry delays
                    MaxDelay = TimeSpan.FromSeconds(10)  //The maximum permissible delay between retry attempts
                    },

                    GeoRedundantSecondaryUri = new Uri("https://...")
                    // If the GeoRedundantSecondaryUri property is set, the secondary Uri will be used for GET or HEAD requests during retries.
                    // If the status of the response from the secondary Uri is a 404, then subsequent retries for the request will not use the
                    // secondary Uri again, as this indicates that the resource may not have propagated there yet.
                    // Otherwise, subsequent retries will alternate back and forth between primary and secondary Uri.
                };

                Uri queueServiceUri = new Uri("https://storageaccount.queue.core.windows.net/");
                string accountName = "Storage account name";
                string accountKey = "storage account key";

                // Create a client object for the Queue service, including QueueClientOptions.
                QueueServiceClient serviceClient = new QueueServiceClient(queueServiceUri, new DefaultAzureCredential(), queueClientOptions);

                CancellationTokenSource source = new CancellationTokenSource();
                CancellationToken cancellationToken = source.Token;

                // Return an async collection of queues in the storage account.
                var queues = serviceClient.GetQueuesAsync(QueueTraits.None, null, cancellationToken);

Supporto delle tabelle

Nota

WindowsAzure. Archiviazione pacchetto Nuget e il pacchetto Nuget Microsoft.Azure.Cosmos.Table sono stati deprecati. Per il supporto delle tabelle di Azure, vedere Pacchetto NuGet Azure.Data.Tables

Meccanismo di ripetizione dei tentativi

La libreria client si basa sulla libreria Core di Azure, ovvero una libreria che fornisce servizi di taglio incrociato ad altre librerie client.

Esistono molti motivi per cui può verificarsi un errore quando un'applicazione client tenta di inviare una richiesta di rete a un servizio. Alcuni esempi sono timeout, errori dell'infrastruttura di rete, servizio che rifiuta la richiesta a causa della limitazione o della disponibilità, terminazione dell'istanza del servizio a causa del ridimensionamento del servizio, istanza del servizio che viene sostituita con un'altra versione, arresto anomalo del servizio a causa di un'eccezione non gestita e così via. Offrendo un meccanismo di ripetizione dei tentativi predefinito (con una configurazione predefinita che il consumer può eseguire l'override), gli SDK e l'applicazione del consumer diventano resilienti a questi tipi di errori. Si noti che alcuni servizi addebitano denaro reale per ogni richiesta e quindi i consumatori dovrebbero essere in grado di disabilitare completamente i tentativi se preferiscono risparmiare denaro rispetto alla resilienza.

Configurazione dei criteri

I criteri di ripetizione dei tentativi sono configurati a livello di codice. La configurazione si basa sulla classe RetryOption. Esiste un attributo in TableClientOptions ereditato da ClientOptions

      var tableClientOptions = new TableClientOptions();
      tableClientOptions.Retry.Mode = RetryMode.Exponential;
      tableClientOptions.Retry.MaxRetries = 5;
      var serviceClient = new TableServiceClient(connectionString, tableClientOptions);

Le tabelle seguenti illustrano le possibilità per i criteri di ripetizione dei tentativi predefiniti.

RetryOption

Impostazione significato
Ritardo Ritardo tra i tentativi di ripetizione per un approccio fisso o il ritardo su cui basare i calcoli per un approccio basato sul backoff. Se il servizio fornisce un'intestazione di risposta Retry-After, il successivo tentativo verrà ritardato dalla durata specificata dal valore dell'intestazione.
MaxDelay Ritardo massimo consentito tra i tentativi quando il servizio non fornisce un'intestazione di risposta Retry-After. Se il servizio fornisce un'intestazione di risposta Retry-After, il successivo tentativo verrà ritardato dalla durata specificata dal valore dell'intestazione.
Modalità Approccio da usare per calcolare i ritardi di ripetizione dei tentativi.
NetworkTimeout Timeout applicato a una singola operazione di rete.

RetryMode

Impostazione significato
Esponenziale I tentativi di ripetizione ritarderanno in base a una strategia di backoff, in cui ogni tentativo aumenterà la durata di attesa prima di riprovare.
MaxDelay I tentativi vengono eseguiti a intervalli fissi; ogni ritardo è una durata coerente.

Telemetria

Il modo più semplice per visualizzare i log consiste nell'abilitare la registrazione della console. Per creare un listener di log di Azure SDK che restituisce messaggi nella console, usare il metodo AzureEventSourceListener.CreateConsoleLogger.

      // Setup a listener to monitor logged events.
      using AzureEventSourceListener listener = AzureEventSourceListener.CreateConsoleLogger();

Esempi

L'esecuzione dell'esempio di codice seguente con l'emulatore di archiviazione arrestata consentirà di visualizzare informazioni sui tentativi nella console.

using Azure.Core;
using Azure.Core.Diagnostics;
using Azure.Data.Tables;
using Azure.Data.Tables.Models;

namespace RetryCodeSamples
{
    class AzureStorageCodeSamples
    {
        private const string connectionString = "UseDevelopmentStorage=true";
        private const string tableName = "RetryTestTable";

        public async static Task SamplesAsync()
        {
            // Setup a listener to monitor logged events.
            using AzureEventSourceListener listener = AzureEventSourceListener.CreateConsoleLogger();

            var tableClientOptions = new TableClientOptions();
            tableClientOptions.Retry.Mode = RetryMode.Exponential;
            tableClientOptions.Retry.MaxRetries = 5;

            var serviceClient = new TableServiceClient(connectionString, tableClientOptions);

            TableItem table = await serviceClient.CreateTableIfNotExistsAsync(tableName);
            Console.WriteLine($"The created table's name is {table.Name}.");
        }
    }
}

Linee guida generali su REST e sulla ripetizione di tentativi

Quando si accede a servizi di Azure o di terze parti, tenere presente quanto segue:

  • Usare un approccio sistematico per gestire la ripetizione di tentativi, ad esempio sotto forma di codice riusabile, in modo da poter applicare una metodologia coerente tra tutti i client e le soluzioni.

  • Valutare la possibilità di usare un framework di ripetizione dei tentativi come Polly per gestire la ripetizione di tentativi se nel client o nel servizio di destinazione non è incorporato un meccanismo di ripetizione dei tentativi. In questo modo, sarà possibile implementare un comportamento coerente per la gestione dei nuovi tentativi e usufruire di un'adeguata strategia di ripetizione dei tentativi predefinita per il servizio di destinazione. Potrebbe tuttavia essere necessario creare codice di ripetizione dei tentativi personalizzato per i servizi con comportamento non standard che non si basano sulle eccezioni per indicare errori temporanei o se si vuole usare una risposta Retry-Response per gestire il comportamento di ripetizione dei tentativi.

  • La logica di rilevamento degli errori temporanei dipenderà dall'API client effettiva usata per richiamare le chiamate REST. Alcuni client, ad esempio la classe HttpClient più recente, non generano eccezioni per le richieste completate con un codice di stato HTTP non riuscito.

  • Il codice di stato HTTP restituito dal servizio consente di stabilire se l'errore è temporaneo. È possibile che sia necessario esaminare le eccezioni generate da un client o dal framework di ripetizione dei tentativi per accedere al codice di stato o determinare il tipo di eccezione equivalente. I seguenti codici HTTP indicano, in genere, che è opportuno eseguire un nuovo tentativo:

    • 408 - Timeout richiesta
    • 429 Troppe richieste
    • 500 Errore interno del server
    • 502 Gateway non valido
    • 503 Servizio non disponibile
    • 504 - Timeout gateway
  • Se si usa una logica di ripetizione dei tentativi basata sulle eccezioni, i valori seguenti indicano un errore temporaneo in cui non è possibile stabilire una connessione:

    • WebExceptionStatus.ConnectionClosed
    • WebExceptionStatus.ConnectFailure
    • WebExceptionStatus.Timeout
    • WebExceptionStatus.RequestCanceled
  • In caso di stato non disponibile di un servizio, l'intervallo di tempo appropriato prima di un nuovo tentativo può essere riportato nell'intestazione della risposta Retry-After o in un'altra intestazione personalizzata del servizio. Alcuni servizi possono anche inviare informazioni aggiuntive come intestazioni personalizzate o incorporate nel contenuto della risposta.

  • Non riprovare per i codici di stato che rappresentano errori client (errori nell'intervallo 4xx), ad eccezione di un timeout di richiesta 408 e 429 Troppe richieste.

  • Verificare accuratamente le strategie e i meccanismi di ripetizione dei tentativi in condizioni diverse, ad esempio in vari stati di rete e carichi di sistema.

Strategie di ripetizione dei tentativi

Di seguito sono riportati i tipi intervallo più comuni nelle strategie di ripetizione dei tentativi:

  • Esponenziale. Criteri di ripetizione dei tentativi che eseguono un numero prestabilito di nuovi tentativi e usano un approccio di backoff esponenziale casuale per determinare l'intervallo di tempo tra i tentativi. Ad esempio:

    var random = new Random();
    
    var delta = (int)((Math.Pow(2.0, currentRetryCount) - 1.0) *
                random.Next((int)(this.deltaBackoff.TotalMilliseconds * 0.8),
                (int)(this.deltaBackoff.TotalMilliseconds * 1.2)));
    var interval = (int)Math.Min(checked(this.minBackoff.TotalMilliseconds + delta),
                    this.maxBackoff.TotalMilliseconds);
    retryInterval = TimeSpan.FromMilliseconds(interval);
    
  • Incrementale. Strategia di ripetizione dei tentativi con un numero prestabilito di nuovi tentativi e un intervallo di tempo incrementale tra i tentativi. Ad esempio:

    retryInterval = TimeSpan.FromMilliseconds(this.initialInterval.TotalMilliseconds +
                    (this.increment.TotalMilliseconds * currentRetryCount));
    
  • LinearRetry. Criteri di ripetizione dei tentativi che eseguono un numero prestabilito di nuovi tentativi e usano un intervallo di tempo fisso tra i tentativi. Ad esempio:

    retryInterval = this.deltaBackoff;
    

Gestione degli errori temporanei con Polly

Polly è una libreria per gestire a livello di codice la ripetizione dei tentativi e le strategie dell'interruttore. Il progetto Polly è membro di .NET Foundation. Per i servizi in cui il client non supporta i tentativi in modo nativo, Polly è un'alternativa valida ed evita la necessità di scrivere codice di ripetizione dei tentativi personalizzato, che può essere difficile da implementare correttamente. Polly offre anche un modo per tracciare gli errori quando questi si verificano, in modo che sia possibile registrare i tentativi.

Passaggi successivi