Sviluppo con Azure Redis gestito

  • Si applica a: ✅ Azure Managed Redis

Questo articolo illustra come sviluppare codice per Azure Redis gestito.

Resilienza della connessione e carico del server

Quando si sviluppano applicazioni client, prendere in considerazione le procedure consigliate pertinenti per la resilienza della connessione e la gestione del carico del server.

Prendere in considerazione più chiavi e valori più piccoli

Azure Managed Redis funziona meglio con valori più piccoli. Per distribuire i dati su più chiavi, è consigliabile dividere blocchi di dati più grandi in blocchi più piccoli. Per altre informazioni sulle dimensioni del valore ideale, vedere questo articolo.

Dimensioni elevate della richiesta o della risposta

Una richiesta o una risposta di grandi dimensioni può causare timeout. Si supponga, ad esempio, di configurare il valore di timeout nel client come 1 secondo. L'applicazione richiede due chiavi(ad esempio, A e B) contemporaneamente (usando la stessa connessione di rete fisica). La maggior parte dei client supporta la pipelining delle richieste, in cui entrambe le richieste A e B vengono inviate una dopo l'altra senza attendere le risposte. Il server invia le risposte nello stesso ordine. Se la risposta A è di grandi dimensioni, può utilizzare la maggior parte del timeout per le richieste successive.

Nell'esempio seguente le richieste A e B vengono inviate rapidamente al server. Il server inizia a inviare risposte A e B rapidamente. A causa dei tempi di trasferimento dei dati, la risposta B deve attendere il timeout della risposta A anche se il server ha risposto rapidamente.

|-------- 1 Second Timeout (A)----------|
|-Request A-|
     |-------- 1 Second Timeout (B) ----------|
     |-Request B-|
            |- Read Response A --------|
                                       |- Read Response B-| (**TIMEOUT**)

Questo modello di richiesta e risposta è difficile da misurare. È possibile instrumentare il codice client per tenere traccia di richieste e risposte di grandi dimensioni.

Le soluzioni per risposte di grandi dimensioni variano, ma includono:

  • Ottimizzare l'applicazione per un numero elevato di valori di piccole dimensioni, anziché per alcuni valori di grandi dimensioni.
  • Aumentare le dimensioni della macchina virtuale per ottenere funzionalità di larghezza di banda più elevate.
    • Una maggiore larghezza di banda nella macchina virtuale client o server può ridurre i tempi di trasferimento dei dati per risposte più grandi.
    • Confrontare l'uso attuale della rete su entrambe le macchine ai limiti delle dimensioni attuali della tua macchina virtuale. Una maggiore larghezza di banda solo sul server o solo sul client potrebbe non essere sufficiente.
  • Aumentare il numero di oggetti di connessione usati dall'applicazione.
    • Usare un approccio round robin per effettuare richieste su oggetti di connessione diversi.

Utilizzare il pipelining

Provare a scegliere un client Redis che supporta la pipelining di Redis. Pipelining consente di usare in modo efficiente la rete e di ottenere la massima velocità effettiva possibile.

Evitare operazioni costose

Alcune operazioni redis, come il comando KEYS , sono costose ed è consigliabile evitarle. Per alcune considerazioni sui comandi a esecuzione prolungata, vedere Comandi a esecuzione prolungata.

Scegliere un livello appropriato

Azure Managed Redis offre livelli ottimizzati per la memoria, bilanciati, ottimizzati per il calcolo e ottimizzati per Flash. Per altre informazioni su come scegliere un livello, vedere Come ridimensionare. Testare le prestazioni per scegliere il livello corretto e convalidare le impostazioni di connessione. Per altre informazioni, vedere Test delle prestazioni.

Scegliere una modalità di disponibilità appropriata

Azure Redis gestito offre la possibilità di abilitare o disabilitare la configurazione a disponibilità elevata. Quando si disabilita la modalità a disponibilità elevata, i dati nell'istanza AMR non vengono replicati e l'istanza di Redis non è disponibile durante la manutenzione. Tutti i dati nell'istanza AMR vengono persi durante la manutenzione pianificata o non pianificata. Disabilitare la disponibilità elevata solo per i carichi di lavoro di sviluppo o test. Le prestazioni delle istanze di Redis con disponibilità elevata possono anche essere inferiori a causa della mancanza di replica dei dati, che è un carico di distribuzione fondamentale tra la partizione di dati primaria e di replica.

Client nella stessa area dell'istanza di Redis

Individua la tua istanza Redis e la tua applicazione nella stessa regione. La connessione a redis in un'area diversa può aumentare significativamente la latenza e ridurre l'affidabilità.

Anche se è possibile connettersi dall'esterno di Azure, non è consigliabile, soprattutto quando si usa Redis per accelerare le prestazioni dell'applicazione o del database. Se si usa il server Redis come archivio chiave/valore, la latenza potrebbe non essere il problema principale.

Fare affidamento su nome host non su indirizzo IP pubblico

L'indirizzo IP assegnato alla cache può cambiare in seguito a un'operazione di scalabilità o a un miglioramento del back-end. Fare affidamento sul nome host anziché su un indirizzo IP pubblico o privato esplicito. L'indirizzo IP statico configurato per una cache in una rete virtuale non è una garanzia non modificabile e può cambiare durante determinate operazioni, anche se le modifiche sono rare.

I nomi host in Redis gestito di Azure hanno un aspetto simile al seguente: <DNS name>.<Azure region>.redis.azure.net

Usare la crittografia TLS

Azure Redis gestito richiede comunicazioni crittografate TLS per impostazione predefinita. Le versioni 1.2 e 1.3 di TLS sono attualmente supportate. Se la libreria client o lo strumento non supporta TLS, è possibile abilitare connessioni non crittografate.

Monitorare l'utilizzo della memoria, le metriche di utilizzo della CPU, le connessioni client e la larghezza di banda di rete

Quando si usa un'istanza di Azure Managed Redis in produzione, impostare avvisi per le metriche Used Memory Percentage, CPU e Client connessi. Se queste metriche superano costantemente il 75%, valutare la possibilità di ridimensionare l'istanza in un livello di memoria maggiore o di velocità effettiva migliore. Per altri dettagli, vedere quando ridimensionare. Per informazioni dettagliate su come viene segnalata la memoria e su come pianificare la capacità, vedere Gestione della memoria.

Valutare la possibilità di abilitare la persistenza dei dati o il backup dei dati

Redis è progettato per i dati temporanei per impostazione predefinita, il che significa che in rari casi i dati possono andare persi a causa di diverse circostanze, ad esempio manutenzione o interruzioni. Se l'applicazione è sensibile alla perdita di dati, abilitare la persistenza dei dati o il backup periodico dei dati usando l'operazione di esportazione dei dati.

La funzionalità di persistenza dei dati fornisce automaticamente un punto di ripristino rapido per i dati quando una cache si arresta. Il ripristino rapido è possibile perché la funzionalità archivia il file RDB o AOF in un disco gestito che monta nell'istanza della cache. Gli utenti non possono accedere ai file di persistenza sul disco e nessun'altra istanza AMR può usarli.

Molti clienti vogliono usare la persistenza per eseguire backup periodici dei dati nella cache. Non usare la persistenza dei dati a questo scopo. Usare invece la funzionalità di importazione/esportazione. È possibile esportare copie di dati in formato RDB direttamente nell'account di archiviazione scelto e attivare l'esportazione dei dati con la frequenza necessaria. È possibile attivare l'esportazione dal portale o usando l'interfaccia della riga di comando, PowerShell o gli strumenti sdk.

Indicazioni specifiche della libreria client

Per altre informazioni, vedere Librerie client per Managed Redis di Azure.

Contenuti correlati

  • Last updated on