Guida alla scelta di politiche di espulsione Redis efficaci

Redis è veloce perché mantiene i dati in memoria, ma la memoria è limitata. Quando la tua istanza Redis raggiunge maxmemory, la politica di espulsione decide se Redis rimuove le chiavi, rifiuta le scritture o espelle solo le chiavi con un tempo di scadenza.

Scegliere una politica di espulsione Redis efficace è importante soprattutto quando Redis funge da cache, archivio di sessioni o archivio dati ad uso misto. La politica sbagliata può espellere chiavi importanti o far fallire le scritture durante un picco di traffico.

---

Comprendere l'espulsione Redis e maxmemory

Le politiche di espulsione entrano in gioco solo quando l'utilizzo della memoria di Redis supera il limite impostato dalla direttiva di configurazione maxmemory. Se maxmemory non è impostato o è impostato a 0, Redis non applica un limite di memoria per le scritture normali. Su un host dedicato, ciò può portare a pressione sulla memoria del sistema operativo, quindi le distribuzioni di cache in produzione di solito impostano un limite esplicito.

Per abilitare l'espulsione, devi configurare maxmemory nel tuo file redis.conf o tramite il comando CONFIG SET:

# Imposta maxmemory a 2GB
CONFIG SET maxmemory 2gb

Una volta che la memoria è limitata, Redis utilizza la politica di espulsione configurata per decidere quali chiavi scartare quando un comando di scrittura richiede più memoria.

Le politiche di espulsione Redis integrate

Redis offre diverse politiche distinte. Queste sono configurate utilizzando la direttiva maxmemory-policy. Le politiche generalmente rientrano in due categorie: quelle basate su Least Recently Used (LRU) o Least Frequently Used (LFU), e quelle che mirano alle chiavi con Time To Live (TTL) impostato.

1. Politiche senza requisiti TTL

Queste politiche operano su tutte le chiavi nel database, indipendentemente dal fatto che abbiano un tempo di scadenza impostato.

noeviction

Questa è la politica predefinita. Quando il limite di memoria viene raggiunto, Redis rifiuta i comandi di scrittura (come SET, LPUSH, ecc.), restituendo un errore al client. Le letture (GET) sono ancora consentite. Questo è spesso adatto per dati critici dove la perdita di dati è inaccettabile, ma può portare a errori dell'applicazione sotto alta pressione di scrittura.

allkeys-lru

Espelle le chiavi meno recentemente utilizzate tra tutte le chiavi nel database fino a quando l'utilizzo della memoria è al di sotto del limite maxmemory. Questa è la scelta standard per una cache generica dove tutti gli elementi dati sono ugualmente memorizzabili in cache.

allkeys-lfu

Espelle le chiavi meno frequentemente utilizzate tra tutte le chiavi. LFU dà priorità al mantenimento delle chiavi che vengono accedute spesso, anche se non sono state accedute recentemente. Questo è efficace quando i modelli di accesso sono volatili, ma gli elementi molto popolari potrebbero rimanere residenti indefinitamente.

allkeys-random

Espelle chiavi scelte casualmente fino a quando il limite di memoria è soddisfatto. Questo è raramente raccomandato per cache di produzione a meno che il modello di accesso ai dati non sia completamente uniforme e imprevedibile.

2. Politiche che richiedono TTL (Chiavi volatili)

Queste politiche considerano solo le chiavi che hanno un tempo di scadenza esplicito (EXPIRE o SETEX) impostato. Ignorano le chiavi senza scadenza quando eseguono l'espulsione.

volatile-lru

Espelle le chiavi meno recentemente utilizzate tra quelle che hanno una scadenza impostata.

volatile-lfu

Espelle le chiavi meno frequentemente utilizzate tra quelle che hanno una scadenza impostata.

volatile-random

Espelle una chiave casuale tra quelle che hanno una scadenza impostata.

volatile-ttl

Espelle per prima la chiave con il tempo di vita residuo più breve (TTL). Questo è ideale per dati sensibili al tempo, come token di sessione o stato dell'applicazione temporaneo, assicurando che i dati più vecchi e in scadenza vengano puliti per primi.

---

Selezionare la politica giusta per il tuo carico di lavoro

La politica di espulsione ottimale dipende interamente da cosa stai memorizzando nella cache e come la tua applicazione utilizza i dati.

Tipo di carico di lavoro	Politica raccomandata	Motivazione
Cache generica (Più comune)	allkeys-lru	Assume che i dati più vecchi e non utilizzati debbano essere rimossi per primi, indipendentemente dal TTL. Semplice e molto efficace.
Dati sensibili al tempo (es. token, sessioni di breve durata)	volatile-ttl	Espelle preferenzialmente le chiavi con il TTL residuo più breve.
Cache di dati caldi (Alta asimmetria di accesso)	allkeys-lfu o volatile-lfu	Protegge gli elementi frequentemente acceduti dall'essere espulsi a causa di inattività recente.
Conservazione obbligatoria dei dati (Nessuna perdita consentita)	noeviction	Previene la perdita di dati causando errori nelle scritture, richiedendo intervento manuale o gestione da parte dell'applicazione a monte.
Carichi di lavoro misti (Alcuni dati scadono, altri no)	volatile-lru, volatile-lfu o volatile-ttl	Se le tue chiavi senza scadenza sono essenziali, usa una politica volatile per proteggerle espellendo solo le chiavi con scadenza esplicita.

Esempio pratico: Implementare un archivio di sessioni

Se Redis è utilizzato principalmente per memorizzare le sessioni utente, imposta un TTL esplicito su ogni chiave di sessione, ad esempio 30 minuti. volatile-ttl può funzionare quando il tempo di vita residuo è il segnale più importante. Se la tua applicazione aggiorna i TTL delle sessioni in base all'attività, le sessioni attive mantengono naturalmente un TTL residuo più lungo. Se non aggiorna i TTL, considera invece volatile-lru o volatile-lfu.

# 1. Imposta maxmemory (es. 10GB)
CONFIG SET maxmemory 10gb

# 2. Scegli la politica che mira ai dati con tempo di vita
CONFIG SET maxmemory-policy volatile-ttl

Esempio pratico: Implementare una cache HTTP

Per memorizzare nella cache risposte HTTP complete (che potrebbero non avere sempre un TTL impostato), vuoi mantenere i dati che vengono acceduti più spesso, anche se quei dati sono rimasti intatti per alcune ore. allkeys-lru o allkeys-lfu sono ideali.

# Usa LFU per conservare gli oggetti veramente 'caldi', indipendentemente dal loro tempo di creazione
CONFIG SET maxmemory-policy allkeys-lfu

Monitoraggio e ottimizzazione

Dopo aver selezionato una politica, il monitoraggio continuo è essenziale. Dovresti tracciare le seguenti metriche tramite il comando INFO:

• used_memory: Quanto sei vicino al limite maxmemory.
• evicted_keys: Il tasso con cui Redis sta scartando dati. Un tasso di espulsione costantemente alto indica che la tua impostazione maxmemory è troppo bassa per il tuo carico di lavoro, o la tua politica di espulsione è eccessivamente aggressiva.
• Tasso di hit della cache dell'applicazione: La misura ultima del successo. Se il tuo tasso di hit diminuisce quando la pressione della memoria aumenta, la selezione della politica o il limite maxmemory necessitano di regolazione.

Buona pratica: Quando ottimizzi maxmemory, lascia sempre un buffer di sicurezza (es. 10-20% di memoria libera) per tenere conto del buffering di replica, del buffering dei comandi e del potenziale overhead delle strutture dati interne di Redis.

Conclusione finale

Inizia con allkeys-lru per una cache generica, allkeys-lfu quando un piccolo insieme di chiavi calde domina il traffico, e una politica volatile-* solo quando le chiavi senza scadenza devono essere protette. Poi osserva evicted_keys, il tasso di hit dell'applicazione e gli errori di scrittura sotto carico prima di considerare la politica completata.