Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Importante
Cache di Azure per Redis ha annunciato la sequenza temporale di ritiro per tutti gli SKU. È consigliabile spostare le istanze di Cache Redis di Azure esistenti in Azure Managed Redis non appena è possibile.
Per altre informazioni sul ritiro:
Comandi di riavvio
Configurare le connessioni client per ripetere comandi con backoff esponenziale. Per altre informazioni, vedere Linee guida per i tentativi.
Testare la resilienza
Testare la resilienza del sistema per le interruzioni di connessione usando un riavvio per simulare una patch. Per altre informazioni sul test delle prestazioni, vedere Test delle prestazioni.
Impostazioni TCP per le applicazioni client ospitate in Linux
Le impostazioni TCP predefinite in alcune versioni di Linux possono causare l'esito negativo delle connessioni al server Redis per 13 minuti o più. Le impostazioni predefinite possono impedire all'applicazione client di rilevare le connessioni chiuse e ripristinarle automaticamente se la connessione non è stata chiusa normalmente.
L'errore di ristabilire una connessione può verificarsi in situazioni in cui la connessione di rete viene interrotta o il server Redis passa offline per la manutenzione non pianificata.
È consigliabile usare queste impostazioni TCP:
| Impostazione | Value |
|---|---|
net.ipv4.tcp_retries2 |
5 |
Per altre informazioni sullo scenario, vedere La connessione non viene stabilita nuovamente per 15 minuti durante l'esecuzione in Linux. Anche se questa discussione riguarda la libreria StackExchange.Redis , anche altre librerie client in esecuzione in Linux sono interessate. La spiegazione è ancora utile ed è possibile generalizzare in altre librerie.
Uso di ForceReconnect con StackExchange.Redis
In rari casi , StackExchange.Redis non riesce a riconnettersi dopo l'eliminazione di una connessione. In questi casi, riavviare il client o creare un nuovo ConnectionMultiplexer risolverà il problema. È consigliabile usare un modello singleton ConnectionMultiplexer consentendo alle app di forzare periodicamente una riconnessione. Esaminare il progetto di esempio di avvio rapido che meglio corrisponde al framework e alla piattaforma usati dall'applicazione. È possibile vedere un esempio di questo modello di codice nelle guide introduttive.
Gli utenti del ConnectionMultiplexer devono gestire eventuali errori ObjectDisposedException che potrebbero verificarsi in seguito all'eliminazione del vecchio.
Chiama ForceReconnectAsync() per RedisConnectionExceptions e RedisSocketExceptions. È anche possibile chiamare ForceReconnectAsync() per RedisTimeoutExceptions, ma solo se si sta facendo abbondantemente uso di ReconnectMinInterval e ReconnectErrorThreshold. Altrimenti, stabilire nuove connessioni può causare un errore a catena su un server che va in timeout perché è già sovraccarico.
In un'applicazione ASP.NET è possibile usare l'implementazione integrata nel pacchetto Microsoft.Extensions.Caching.StackExchangeRedis anziché usare direttamente il pacchetto StackExchange.Redis . Se si usa Microsoft.Extensions.Caching.StackExchangeRedis in un'applicazione ASP.NET anziché usare direttamente StackExchange.Redis , è possibile impostare la UseForceReconnect proprietà su true:
Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true
Configurare i timeout appropriati
Due valori di timeout sono importanti da considerare nella resilienza della connessione: timeout della connessione e timeout dei comandi.
Timeout connessione
È connect timeout il momento in cui il client attende di stabilire una connessione con il server Redis. Configurare la libreria client per l'uso di un connect timeout valore di cinque secondi, offrendo al sistema tempo sufficiente per connettersi anche in condizioni di CPU più elevate.
Un valore ridotto connection timeout non garantisce che una connessione venga stabilita in tale intervallo di tempo. Se si verifica un errore (CPU client elevata, CPU server elevata e così via), un valore breve connection timeout causa l'esito negativo del tentativo di connessione. Questo comportamento spesso peggiora la situazione. Invece di contribuire, i timeout più brevi aggravano il problema forzando il sistema a riavviare il processo di tentativo di riconnessione, che può causare una connessione -> errore -> ciclo di ripetizione dei tentativi .
Timeout del comando
La maggior parte delle librerie client ha un'altra configurazione di timeout per command timeouts, ovvero il tempo in cui il client attende una risposta dal server Redis. Sebbene sia consigliabile impostare un'impostazione iniziale di meno di cinque secondi, è consigliabile impostare il command timeout valore superiore o inferiore a seconda dello scenario e delle dimensioni dei valori archiviati nella cache.
Se è command timeout troppo piccolo, la connessione può sembrare instabile. Tuttavia, se command timeout è troppo grande, l'applicazione potrebbe dover attendere a lungo per capire se il comando andrà in timeout oppure no.
Evitare picchi di connessione dei client
Evitare di creare più connessioni contemporaneamente durante la riconnessione dopo una perdita di connessione. Analogamente al modo in cui i timeout di connessione brevi possono causare interruzioni più lunghe, l'avvio di molti tentativi di riconnessione contemporaneamente può anche aumentare il carico del server ed estendere il tempo necessario per la riconnessione di tutti i client.
Se si stanno riconnettendo molte istanze client, valutare la possibilità di sfalsare le nuove connessioni per evitare un picco elevato nel numero di client connessi.
Annotazioni
Quando si utilizza la libreria client StackExchange.Redis, imposta abortConnect su false nella stringa di connessione. È consigliabile lasciare che ConnectionMultiplexer gestisca la riconnessione. Per altre informazioni, vedere Procedure consigliate per StackExchange.Redis.
Evitare connessioni residue
Le cache hanno limiti al numero di connessioni client per livello di cache. Assicurarsi che quando l'applicazione client ricrea le connessioni che chiude e rimuove le connessioni precedenti.
Notifica di manutenzione avanzata
Usare le notifiche per apprendere la manutenzione imminente. Per altre informazioni, vedere È possibile ricevere una notifica in anticipo di una manutenzione pianificata.
Finestra pianificazione della manutenzione
Modificare le impostazioni della cache per gestire la manutenzione. Per altre informazioni sulla creazione di una finestra di manutenzione per ridurre eventuali effetti negativi alla cache, vedere Canale di aggiornamento e Pianificazione degli aggiornamenti.
Altri modelli di progettazione per la resilienza
Applicare modelli di progettazione per la resilienza. Per altre informazioni, vedere Come rendere resiliente l'applicazione.
Timeout di inattività
Cache Redis di Azure ha un timeout di 10 minuti per le connessioni inattive. Il timeout di 10 minuti consente al server di pulire automaticamente le connessioni perse o le connessioni orfane da un'applicazione client. La maggior parte delle librerie client Redis ha una funzionalità predefinita per inviare heartbeat o keepalive comandi periodicamente per impedire la chiusura delle connessioni anche se non sono presenti richieste dall'applicazione client.
Se si verifica un rischio di inattività delle connessioni per 10 minuti, configurare l'intervallo keepalive su un valore inferiore a 10 minuti. Se l'applicazione usa una libreria client che non dispone del supporto nativo per keepalive la funzionalità, è possibile implementarla nell'applicazione inviando periodicamente un PING comando.