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.
Cache Redis di Azure offre un archivio dati in memoria basato sul software Redis . Si tratta di un broker di messaggistica e cache dei dati sicuro che fornisce velocità effettiva elevata e accesso a bassa latenza ai dati per le applicazioni.
I concetti chiave e le procedure consigliate che supportano l'affidabilità includono:
Importante
Queste raccomandazioni sono specifiche di Cache Redis di Azure e non di Azure Managed Redis. Per visualizzare le funzionalità di resilienza per Azure Managed Redis, vedere la documentazione sulla resilienza del servizio.
Le sezioni seguenti includono considerazioni sulla progettazione, un elenco di controllo della configurazione e opzioni di configurazione consigliate specifiche per Cache Redis di Azure.
Considerazioni sulla progettazione
Il contratto di servizio di Cache Redis di Azure copre solo le cache di livello Standard, Premium, Enterprise ed Enterprise Flash. Il livello Basic non è coperto.
Redis è una cache in memoria per coppie chiave-valore e, per impostazione predefinita, è dotata di alta disponibilità, ad eccezione del livello Basic. Esistono quattro livelli per Cache Redis di Azure:
Basic: non consigliato per i carichi di lavoro di produzione. Il livello Basic è ideale per:
- Nodo singolo
- Dimensioni multiple
- Sviluppo
- Prova
- Carichi di lavoro non critici
Standard: una cache replicata in una configurazione primaria e secondaria a due nodi gestita da Microsoft, con un contratto di servizio a disponibilità elevata.
Premium: include tutte le funzionalità di livello standard e include le altre funzionalità seguenti:
- Hardware e prestazioni più veloci rispetto al livello Basic o Standard.
- Dimensioni della cache maggiori, fino a
120GB
. - Persistenza dei dati, che include il file di database Redis (RDB) e il file AOF (Append Only File).
- Supporto della rete virtuale.
- Raggruppamento
- Replica geografica: una cache secondaria si trova in un'altra area e replica i dati dal database primario per il ripristino di emergenza. Per eseguire il failover nel database secondario, è necessario scollegare manualmente le cache e quindi il database secondario è disponibile per le scritture. L'applicazione che scrive in Redis deve essere aggiornata con la stringa di connessione della cache secondaria.
- Zone di disponibilità: distribuire la cache e le repliche tra zone di disponibilità.
Annotazioni
Per impostazione predefinita, ogni distribuzione avrà una replica per partizione. La persistenza, il clustering e la replica geografica sono tutte disabilitate in questo momento con le distribuzioni con più repliche. I nodi verranno distribuiti uniformemente in tutte le zone. Dovresti avere un numero di repliche pari a
>=
il numero di zone. - Importare ed esportare.
Enterprise ed Enterprise Flash
- Richiede una licenza Redis Enterprise di Redis Inc.
- Aumentare e aumentare le prestazioni solo, non ridurre o ridurre le prestazioni
- Supporta la replica geografica attiva
Lista di controllo
Hai configurato la Cache Redis di Azure tenendo in mente la resilienza?
- Pianificare gli aggiornamenti.
- Monitorare la cache e impostare gli avvisi.
- Distribuire la cache all'interno di una rete virtuale.
- Valutare una strategia di partizionamento all'interno della cache Redis.
- Configurare la persistenza dei dati per salvare una copia della cache in Archiviazione di Azure o usare la replica geografica, a seconda dei requisiti aziendali.
- Implementare i criteri di ripetizione dei tentativi nel contesto di Cache Redis di Azure.
- Usare un'implementazione statica o singleton del multiplexer di connessione a Redis e seguire la guida alle procedure consigliate.
- Vedere Come amministrare Cache Redis di Azure.
Consigli sulla configurazione
Esplorare la tabella di raccomandazioni seguente per ottimizzare la configurazione di Cache Redis di Azure per l'affidabilità del servizio:
Raccomandazione | Descrizione |
---|---|
Usare la ridondanza della zona. | Quando la ridondanza della zona è abilitata nella tua cache, la cache di Azure per Redis distribuisce le macchine virtuali che ospitano la cache in più zone di disponibilità. La ridondanza della zona offre disponibilità elevata e tolleranza di errore in caso di interruzione del data center. |
Pianificare gli aggiornamenti. | Pianificare i giorni e gli orari in cui gli aggiornamenti del server Redis verranno applicati alla cache, che non include gli aggiornamenti di Azure o gli aggiornamenti al sistema operativo della macchina virtuale. |
Monitorare la cache e impostare gli avvisi. | Impostare avvisi per eccezioni, utilizzo elevato della CPU, utilizzo elevato della memoria, carico del server e chiavi rimosse per informazioni dettagliate su quando ridimensionare la cache. Se la cache deve essere ridimensionata, comprendere quando ridimensionare è importante perché aumenterà la CPU durante l'evento di ridimensionamento per eseguire la migrazione dei dati. |
Distribuire la cache all'interno di una rete virtuale. | Offre al cliente un maggiore controllo sul traffico che può connettersi alla cache. Assicurarsi che la subnet disponga di spazio indirizzi sufficiente per distribuire i nodi della cache e le partizioni (cluster). |
Valutare una strategia di partizionamento all'interno della cache Redis. | Il partizionamento di un archivio dati Redis comporta la suddivisione dei dati tra istanze del server Redis. Ogni istanza costituisce una singola partizione. Cache Redis di Azure astrae i servizi Redis dietro una facciata e non li espone direttamente. Il modo più semplice per implementare il partizionamento consiste nel creare più istanze di Cache Redis di Azure e distribuire i dati tra di essi. È possibile associare ogni elemento di dati a un identificatore (una chiave di partizione) che specifica la cache in cui è archiviato l'elemento di dati. La logica dell'applicazione client può quindi usare questo identificatore per instradare le richieste alla partizione appropriata. Questo schema è semplice, ma se lo schema di partizionamento cambia (ad esempio, se vengono create istanze aggiuntive di Cache Redis di Azure), potrebbe essere necessario riconfigurare le applicazioni client. |
Configurare la persistenza dei dati per salvare una copia della cache in Archiviazione di Azure o usare la replica geografica passiva, a seconda dei requisiti aziendali. | Persistenza dei dati: se il riavvio della replica e primaria, i dati verranno caricati automaticamente dall'account di archiviazione. Replica geografica: i dati scritti nella cache primaria vengono replicati in una cache di sola lettura secondaria. Per il failover, la cache secondaria deve essere scollegata dal database primario. Il database secondario diventerà il database primario e potrà ricevere scritture. |
Implementare i criteri di ripetizione dei tentativi nel contesto di Cache Redis di Azure. | La maggior parte dei servizi di Azure e degli SDK client include un meccanismo di ripetizione dei tentativi. Questi meccanismi differiscono perché ogni servizio ha caratteristiche e requisiti diversi. Ogni meccanismo di ripetizione dei tentativi viene ottimizzato per un servizio specifico. |
Vedere Come amministrare Cache Redis di Azure. | Comprendere in che modo la perdita di dati può verificarsi con i riavvii della cache e come testare l'applicazione per ottenere resilienza. |
Artefatti di origine
Per identificare le istanze di Redis che non sono nel livello Premium, usare la query seguente:
Resources
| where type == 'microsoft.cache/redis'
| where properties.sku.name != 'Premium'