Condividi tramite

Sviluppo con Redis gestito di Azure (anteprima)

  • Articolo

Resilienza della connessione e carico del server

Quando si sviluppano applicazioni client, assicurarsi di considerare 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 (anteprima) 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 di richiesta o risposta di grandi dimensioni

Una richiesta/risposta di grandi dimensioni può causare un timeout. Si supponga, ad esempio, che il valore di timeout configurato nel client sia di 1 secondo. L'applicazione richiede due chiavi, ad esempio "A" e "B", nello stesso momento (con 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' è grande, può consumare la maggior parte del timeout per le richieste successive.

Nell'esempio seguente, la richiesta 'A' e 'B' vengono inviate rapidamente al server. Il server avvia rapidamente l'invio di risposte 'A' e 'B'. 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**)

Non è semplice misurare questa richiesta/risposta. È possibile instrumentare il codice client per tenere traccia di richieste e risposte di grandi dimensioni.

Le risoluzioni per le dimensioni delle risposte di grandi dimensioni sono varie, 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 (VM) per ottenere funzionalità di larghezza di banda superiori
    • 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'utilizzo di rete corrente in entrambi i computer con i limiti delle dimensioni correnti della 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.

Usare 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 e devono essere evitate. Per alcune considerazioni sui comandi a esecuzione prolungata, vedere Comandi a esecuzione prolungata.

Scegliere un livello appropriato

Redis gestito di Azure offre livelli ottimizzati per la memoria, bilanciati, ottimizzati per il calcolo e con ottimizzazione flash. Per altre informazioni su come scegliere un livello , vedere qui. È consigliabile 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

Redis gestito di Azure offre la possibilità di abilitare o disabilitare la configurazione a disponibilità elevata. Quando la modalità a disponibilità elevata è disabilitata, i dati dell'istanza AMR non verranno replicati e quindi l'istanza di Redis non sarà disponibile durante la manutenzione. Tutti i dati nell'istanza AMR andranno persi anche in caso di manutenzione pianificata o non pianificata. È consigliabile 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 cruciale tra la partizione di dati primaria e di replica.

Client nella stessa area dell'istanza di Redis

Individuare l'istanza di Redis e l'applicazione nella stessa area. 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 pubblico assegnato all'istanza AMR può cambiare in seguito a un'operazione di scalabilità o a un miglioramento del back-end. È consigliabile basarsi sul nome host anziché su un indirizzo IP pubblico esplicito.

Usare la crittografia TLS

Per impostazione predefinita, Azure Managed Redis richiede comunicazioni crittografate TLS. 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 l'istanza di Redis gestita di Azure nell'ambiente di produzione, è consigliabile impostare avvisi per le metriche "Percentuale memoria usata", "CPU", "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 .

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, è consigliabile abilitare la persistenza dei dati o il backup periodico dei dati usando l'operazione di esportazione dei dati.

La funzionalità di persistenza dei dati è progettata per fornire automaticamente un punto di ripristino rapido per i dati quando una cache viene disattivata. Il ripristino rapido è reso possibile archiviando il file RDB o AOF in un disco gestito montato nell'istanza della cache. I file di persistenza sul disco non sono accessibili agli utenti o non possono essere usati da altre istanze AMR.

Molti clienti vogliono usare la persistenza per eseguire backup periodici dei dati nella cache. Non è consigliabile usare la persistenza dei dati in questo modo. 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. Questi dati esportati possono quindi essere importati in qualsiasi istanza di Redis. L'esportazione può essere attivata 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 Redis gestite di Azure

Contenuto correlato