Questa pagina fornisce indicazioni sull'utilizzo ottimale di Memorystore for Redis Cluster. Questa pagina indica anche i potenziali problemi da evitare.
Best practice di gestione della memoria
Questa sezione descrive le strategie per la gestione della memoria delle istanze in modo che Memorystore for Redis Cluster funzioni in modo efficiente per la tua applicazione.
Concetti di gestione della memoria
Carico di scrittura: il volume e la velocità con cui aggiungi o aggiorni le chiavi nel cluster Redis. Il carico di scrittura può variare da normale a molto elevato a seconda del caso d'uso di Redis e dei pattern di utilizzo dell'applicazione.
Criterio di eliminazione: Memorystore for Redis Cluster utilizza il
volatile-lrucriterio di eliminazione. Puoi utilizzare comandi come EXPIRE per impostare le espulsioni per le chiavi.
Monitora un cluster con un carico di scrittura normale
Visualizza la metrica /cluster/memory/maximum_utilization. Se /cluster/memory/maximum_utilization è
al 100% o inferiore, il cluster Redis funziona bene quando utilizzi un carico di scrittura normale.
Tuttavia, se l'utilizzo della memoria si avvicina al 100% e prevedi che l'utilizzo dei dati aumenterà, devi aumentare le dimensioni del cluster per fare spazio ai nuovi dati.
Monitorare un cluster con un carico di scrittura elevato
Visualizza la metrica /cluster/memory/maximum_utilization. A seconda della gravità del carico di scrittura elevato, il cluster può riscontrare problemi di prestazioni alle seguenti soglie:
Carichi di scrittura molto elevati possono riscontrare problemi se
/cluster/memory/maximum_utilizationraggiunge il 65% o più.Carichi di scrittura moderatamente elevati possono riscontrare problemi se
/cluster/memory/maximum_utilizationraggiunge l'85% o più.
In questi scenari devi aumentare le dimensioni del cluster per migliorare le prestazioni.
Se riscontri problemi o temi che la tua istanza abbia un carico di scrittura elevato, contatta l'Google Cloud assistenza.
Scalabilità degli shard
Quando ridimensioni il numero di shard in un'istanza, devi farlo durante i periodi di bassa attività di scrittura. Lo scaling durante i periodi di carico di scrittura elevato può esercitare una pressione sulla memoria dell'istanza a causa dell'overhead di memoria causato dalla replica o dalla migrazione degli slot.
Se il tuo caso d'uso di Redis utilizza l'eliminazione delle chiavi, il ridimensionamento a una dimensione del cluster più piccola può ridurre il percentuale successi cache. In questo caso, tuttavia, non devi preoccuparti di perdere dati, poiché l'eliminazione della chiave è prevista.
Per i casi d'uso di Redis in cui non vuoi perdere le chiavi, devi eseguire fare lo scale down solo a un cluster più piccolo che abbia ancora spazio sufficiente per i tuoi dati. Il nuovo conteggio di partizioni target deve consentire almeno 1,5 volte la memoria utilizzata dai dati. In altre parole, devi eseguire il provisioning di un numero sufficiente di shard per 1,5 volte la quantità di dati attualmente presenti nel cluster. Puoi utilizzare la metrica /cluster/memory/total_used_memory per visualizzare la quantità di dati archiviati nella tua istanza.
Best practice per l'utilizzo della CPU
Se si verifica un'interruzione del servizio imprevista a livello di zona, le risorse CPU del cluster vengono ridotte a causa della capacità persa dai nodi nella zona non disponibile. Ti consigliamo di utilizzare cluster a disponibilità elevata. L'utilizzo di due repliche per shard (anziché una replica per shard) fornisce risorse CPU aggiuntive durante un'interruzione. Inoltre, consigliamo di gestire l'utilizzo della CPU dei nodi in modo che abbiano un overhead della CPU sufficiente per gestire il traffico aggiuntivo dovuto alla capacità persa in caso di interruzione zonale imprevista. Devi monitorare l'utilizzo della CPU per i primari e le repliche utilizzando la metrica /cluster/cpu/maximum_utilization.
A seconda del numero di repliche di cui esegui il provisioning per nodo, ti consigliamo i seguenti target di utilizzo della CPU /cluster/cpu/maximum_utilization:
- Per le istanze con una replica per nodo, scegli come target un valore
/cluster/cpu/maximum_utilizationdi 0,5 secondi per la replica principale e di 0,5 secondi per la replica, quando la replica è designata come replica di lettura. - Per le istanze con due repliche per nodo, scegli come target un valore di
/cluster/cpu/maximum_utilizationdi 0,8 secondi per l'istanza principale e di 0,5 secondi per ogni replica.
Se i valori della metrica superano questi consigli, ti consigliamo di aumentare il numero di shard o repliche nella tua istanza.
Comandi Redis che richiedono molte risorse
Ti consigliamo vivamente di evitare di utilizzare comandi Redis che richiedono molte risorse. L'utilizzo di questi comandi potrebbe causare i seguenti problemi di prestazioni:
- Latenza elevata e timeout del client
- Pressione della memoria causata da comandi che aumentano l'utilizzo della memoria
- Perdita di dati durante la replica e la sincronizzazione dei nodi perché il thread principale di Redis è bloccato
- Controlli di integrità, osservabilità e replica con risorse insufficienti
La tabella seguente elenca alcuni esempi di comandi Redis che richiedono molte risorse e fornisce alternative efficienti in termini di risorse.
| Category | Comando che richiede molte risorse | Alternativa efficiente in termini di risorse |
|---|---|---|
| Esegui per l'intero spazio delle chiavi | KEYS |
SCAN |
| Esegui per un keyset di lunghezza variabile | LRANGE |
Limita le dimensioni dell'intervallo che utilizzi per una query. |
ZRANGE |
Limita le dimensioni dell'intervallo che utilizzi per una query. | |
HGETALL |
HSCAN |
|
SMEMBERS |
SSCAN |
|
| Bloccare l'esecuzione di uno script | EVAL |
Assicurati che lo script non venga eseguito all'infinito. |
EVALSHA |
Assicurati che lo script non venga eseguito all'infinito. | |
| Rimuovere file e link | DELETE |
UNLINK |
| Pubblica e iscriviti | PUBLISH |
SPUBLISH |
SUBSCRIBE |
SSUBSCRIBE |
Best practice per il client Redis
Quando si connette a un'istanza Memorystore for Redis Cluster, l'applicazione deve utilizzare un client Redis compatibile con il cluster. Per esempi di client compatibili con i cluster e configurazioni di esempio, consulta Esempi di codice della libreria client. Il tuo cliente deve mantenere una mappa degli slot hash ai nodi corrispondenti nel cluster per inviare le richieste ai nodi giusti ed evitare l'overhead delle prestazioni causato dai reindirizzamenti del cluster.
Mappatura client
I clienti devono ottenere un elenco completo degli slot e dei nodi mappati nelle seguenti situazioni:
Quando il client viene inizializzato, deve compilare la mappatura iniziale degli slot ai nodi.
Quando viene ricevuto un reindirizzamento
MOVEDdal server, ad esempio in caso di failover quando tutti gli slot gestiti dal nodo primario precedente vengono rilevati dalla replica o di ripartizione quando gli slot vengono spostati dal nodo primario di origine a quello di destinazione.Quando viene ricevuto un errore
CLUSTERDOWNdal server o le connessioni a un determinato server vanno costantemente in timeout.Quando viene ricevuto un errore
READONLYdal server. Ciò può accadere quando un primary viene declassato a replica.Inoltre, i client devono aggiornare periodicamente la topologia per mantenerli attivi per eventuali modifiche e conoscere quelle che potrebbero non comportare reindirizzamenti/ errori dal server, ad esempio quando vengono aggiunti nuovi nodi di replica. Tieni presente che anche le connessioni obsolete devono essere chiuse nell'ambito dell'aggiornamento della topologia per ridurre la necessità di gestire le connessioni non riuscite durante l'esecuzione del comando.
Ricerca di clienti
Il rilevamento del client viene in genere eseguito inviando un comando CLUSTER SLOT, CLUSTER NODE o CLUSTER SHARDS al server Redis. Ti consigliamo di utilizzare il comando CLUSTER SHARDS. CLUSTER SHARDS sostituisce il comando CLUSTER SLOTS (ritirato) fornendo una rappresentazione più efficiente ed estensibile del cluster.
Le dimensioni della risposta per i comandi di rilevamento dei client del cluster possono variare in base alle dimensioni e alla topologia del cluster. I cluster più grandi con più nodi producono una risposta più grande. Di conseguenza, è importante assicurarsi che il numero di client che eseguono l'individuazione della topologia del cluster non aumenti senza limiti.
Questi aggiornamenti della topologia sono costosi per il server Redis, ma sono anche importanti per la disponibilità delle applicazioni. Pertanto, è importante assicurarsi che ogni client effettui una singola richiesta di rilevamento in un determinato momento (e memorizzi nella cache il risultato in memoria) e che il numero di client che effettuano le richieste sia limitato per evitare di sovraccaricare il server.
Ad esempio, quando l'applicazione client si avvia o perde la connessione dal server e deve eseguire il rilevamento del cluster, un errore comune è che l'applicazione client effettua diverse richieste di riconnessione e rilevamento senza aggiungere il backoff esponenziale al nuovo tentativo. Ciò può rendere il server Redis non reattivo per un periodo di tempo prolungato, causando un utilizzo della CPU molto elevato.
Evitare il sovraccarico di rilevamento su Redis
Per ridurre l'impatto causato da un improvviso afflusso di richieste di connessione e rilevamento, ti consigliamo di procedere come segue:
Implementa un pool di connessioni client con dimensioni finite e ridotte per limitare il numero di connessioni in entrata simultanee dall'applicazione client.
Quando il client si disconnette dal server a causa del timeout, riprova con backoff esponenziale con jitter. In questo modo si evita che più client sovraccarichino il server contemporaneamente.
Utilizza l'endpoint di rilevamento di Memorystore for Redis Cluster per eseguire il rilevamento del cluster. L'endpoint di rilevamento è a disponibilità elevata e il carico è bilanciato su tutti i nodi del cluster. Inoltre, l'endpoint di rilevamento tenta di instradare le richieste di rilevamento del cluster ai nodi con la visualizzazione della topologia più aggiornata.
Best practice per la persistenza
Questa sezione illustra le best practice per la persistenza.
Persistenza RDB e aggiunta di repliche
Per ottenere risultati ottimali dal backup dell'istanza con snapshot RDB o dall'aggiunta di repliche all'istanza, utilizza le seguenti best practice:
Gestione della memoria
Gli snapshot RDB utilizzano un fork di processo e un meccanismo di "copy-on-write" per acquisire uno snapshot dei dati del nodo. A seconda del pattern di scrittura nei nodi, la memoria utilizzata dei nodi aumenta man mano che vengono copiate le pagine toccate dalle scritture. L'impronta di memoria può essere fino al doppio delle dimensioni dei dati nel nodo.
Per assicurarti che i nodi abbiano memoria sufficiente per completare lo snapshot, mantieni o imposta maxmemory all'80% della capacità del nodo, in modo che il 20% sia riservato all'overhead. Questo overhead di memoria, oltre agli snapshot di monitoraggio, ti aiuta a gestire il carico di lavoro per avere snapshot riusciti. Inoltre, quando aggiungi repliche, riduci il traffico di scrittura il più possibile. Per saperne di più, consulta Monitorare un cluster con un carico di scrittura elevato.
Snapshot obsoleti
Il recupero di nodi da uno snapshot obsoleto può causare problemi di prestazioni per l'applicazione, in quanto tenta di riconciliare una quantità significativa di chiavi obsolete o altre modifiche al database, ad esempio una modifica dello schema. Se ti preoccupa il recupero da uno snapshot obsoleto, puoi disattivare la funzionalità di persistenza RDB. Una volta riattivata la persistenza, viene creato uno snapshot al successivo intervallo di snapshot pianificato.
Impatto sulle prestazioni degli snapshot RDB
A seconda del pattern del carico di lavoro, gli snapshot RDB possono influire sulle prestazioni dell'istanza e aumentare la latenza delle applicazioni. Puoi ridurre al minimo l'impatto sul rendimento degli snapshot RDB pianificandone l'esecuzione durante i periodi di basso traffico dell'istanza, se preferisci snapshot meno frequenti.
Ad esempio, se la tua istanza ha un traffico basso dalle 01:00 alle 04:00, puoi impostare l'ora di inizio alle 03:00 e l'intervallo a 24 ore.
Se il tuo sistema ha un carico costante e richiede snapshot frequenti, devi valutare attentamente l'impatto sulle prestazioni e soppesare i vantaggi dell'utilizzo degli snapshot RDB per il workload.
Aggiungere una replica
L'aggiunta di una replica richiede uno snapshot RDB. Per ulteriori informazioni sugli snapshot RDB, consulta Gestione della memoria.
Scegli un'istanza a zona singola se la tua istanza non utilizza repliche
Quando configuri un'istanza senza repliche, ti consigliamo un'architettura a zona singola per una maggiore affidabilità. Ecco perché:
Ridurre al minimo l'impatto dell'interruzione del servizio
È meno probabile che le interruzioni a livello di zona influiscano sulla tua istanza. Se posizioni tutti i nodi all'interno di una singola zona, la probabilità che un'interruzione zonale influisca sul tuo server scende dal 100% al 33%. Questo perché c'è una probabilità del 33% che la zona in cui si trova la tua istanza non sia disponibile, rispetto al 100% di probabilità che i nodi che si trovano nella zona non disponibile siano interessati.
Recupero rapido
In caso di interruzione a livello di zona, il ripristino viene semplificato. Puoi rispondere eseguendo rapidamente il provisioning di una nuova istanza in una zona funzionante e reindirizzando l'applicazione per operazioni con interruzioni minime.
Best practice per Lettuce
Questa sezione descrive le best practice per l'utilizzo di Lettuce per connettersi a un'istanza Memorystore for Redis Cluster.
Aggiornare i valori dei parametri
Quando utilizzi Lettuce, modifica il parametro validateClusterNodeMembership in
false. In caso contrario, quando la topologia cambia, potresti visualizzare errori unknownPartition.