Resilienza della connessione con Redis gestito di Azure (anteprima)
Comandi retry
Configurare le connessioni client per ripetere comandi con backoff esponenziale. Per ulteriori informazioni, consultare le linee guida relative al retry.
Impostazioni TCP per 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ù. Se le connessione non è stata chiusa normalmente, le impostazioni predefinite possono impedire all'applicazione client di rilevarla e ripristinarla automaticamente.
Può succedere che la connessione non riesca a essere ristabilita in situazioni in cui la connessione di rete è interrotta o il server Redis passa offline a causa di manutenzione non pianificata.
È consigliabile usare queste impostazioni TCP:
| Impostazione | Valore |
|---|---|
net.ipv4.tcp_retries2 |
5 |
Per ulteriori informazioni sullo scenario, consultare La connessione non viene ristabilita 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. Le istruzioni sono utili anche in generale per 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 criterio singleton ConnectionMultiplexer e consentire alle app di eseguire periodicamente una riconnessione forzata. Esaminare il progetto campione di avvio rapido più adatto al framework e alla piattaforma usati dall'applicazione. È possibile vedere un esempio di questo criterio di codice in avvio rapido.
Gli utenti del ConnectionMultiplexer devono gestire eventuali errori ObjectDisposedException che potrebbero verificarsi in seguito all'eliminazione del vecchio.
Chiamare ForceReconnectAsync() per RedisConnectionExceptions e RedisSocketExceptions. È anche possibile chiamare ForceReconnectAsync() per RedisTimeoutExceptions, ma solo se si sta facendo abbondantemente uso di ReconnectMinInterval e ReconnectErrorThreshold. In caso contrario, la definizione di nuove connessioni può causare un errore a catena in un server che è 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 adatti
Nella resilienza di connessione, è importante considerare due valori di timeout: timeout della connessione e timeout dei comandi.
Connect timeout
connect timeout è il periodo di tempo che il client attende per stabilire una connessione con il server Redis. Configurare la libreria client per l'uso di un connect timeout di cinque secondi, offrendo al sistema tempo sufficiente per connettersi anche in condizioni con CPU più elevate.
Un valore connection timeout più piccolo non garantisce che una connessione venga stabilita in tale intervallo di tempo. Se qualcosa dovesse andare storto (CPU client elevata, CPU server elevata, e così via), un valore connection timeout più breve causerà l'esito negativo del tentativo di connessione. Spesso, questo comportamento non fa che peggiorare la situazione. Invece di essere d’aiuto, i timeout più brevi aggravano il problema forzando il sistema a riavviare il tentativo di riconnessione, il che potrebbe causare un ciclo diconnessione -> errore -> tentativo di riconnessione.
Timeout comando
La maggior parte delle librerie client ha un'altra configurazione di timeout per command timeouts, ovvero il tempo per cui un client attende una risposta dal server Redis. Sebbene un'impostazione iniziale di meno di cinque secondi sia consigliabile, valutare di impostare command timeout su un valore superiore o inferiore a seconda dello scenario e delle dimensioni dei valori archiviati nella cache.
Se command timeout è troppo piccolo, la connessione potrebbe sembrare instabile. Tuttavia, se è command timeout troppo grande, l'applicazione potrebbe dover attendere molto tempo per scoprire se il comando stia per scadere o meno.
Evitare picchi di connessione client
Evitare di creare più connessioni contemporaneamente durante la riconnessione dopo una perdita di connessione perché le nuove creazioni di connessioni sono limitate. Allo stesso modo in cui timeout di connessione brevi possono causare interruzioni più lunghe, l'avvio di molti tentativi di riconnessione in contemporanea può anche aumentare il carico del server ed aumentare il tempo necessario per la riconnessione di tutti i client.
Se si riconnette molte istanze client, valutare la possibilità di sfalsare le nuove connessioni per evitare che le nuove connessioni vengano limitate.
Nota
Quando si usa la libreria client StackExchange.Redis, impostare su false abortConnect nella stringa di connessione. È consigliabile consentire a ConnectionMultiplexer di gestire la riconnessione. Per altre informazioni, vedere Procedure consigliate per StackExchange.Redis.
Evitare connessioni residue
Le cache hanno un numero limitato di connessioni client per livello di cache. Quando l’applicazione client ricrea connessioni, assicurarsi che chiuda e rimuova quelle precedenti.
Pianificare la finestra di manutenzione
Modificare le impostazioni della cache per gestire la manutenzione. Per ulteriori informazioni sulla creazione di una finestra di manutenzione per ridurre eventuali effetti negativi alla cache, consultare Canale di aggiornamento e Pianificazione degli aggiornamenti.
Altri schemi progettuali per la resilienza
Applicare schemi progettuali per la resilienza. Per ulteriori informazioni, consultare Come rendere resiliente l'applicazione.
Timeout di inattività
Azure Managed Redis (anteprima) ha un timeout di 10 minuti per le connessioni inattive. Il timeout di 10 minuti consente al server di ripulire automaticamente le connessioni che perdono o quelle rimaste orfane da un'applicazione client. La maggior parte delle librerie client Redis ha una funzionalità integrata per inviare periodicamente comandi heartbeat o keepalive per impedire la chiusura delle connessioni anche se non sono presenti richieste da parte dell’applicazione client.
Se le connessioni rischiano di essere inattive 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 la funzionalità keepalive, è possibile implementarla nell'applicazione inviando periodicamente un comando PING.