Scegliere la Migliore Strategia di Persistenza Redis: RDB vs AOF.

Redis memorizza i dati in memoria, quindi hai bisogno di una strategia di persistenza prima di fare affidamento su di esso per qualsiasi cosa che non possa essere facilmente ricostruita. La scelta tra RDB e AOF influisce sulla quantità di dati che puoi perdere, sulla velocità di riavvio di Redis e sul carico di I/O su disco generato dal tuo carico di lavoro.

Usa RDB quando gli snapshot periodici sono sufficienti. Usa AOF quando hai bisogno di una maggiore durabilità. Usa entrambi quando desideri una durabilità pratica più backup più facili, ma testa comunque il ripristino con il tuo dataset reale.

Comprendere la Persistenza di Redis

La persistenza in Redis si riferisce alla capacità di salvare il dataset in memoria su disco, in modo che possa essere ricaricato dopo un riavvio o un crash del server. Senza persistenza, tutti i dati memorizzati in Redis andrebbero persi se il server si ferma o si blocca. Redis offre due metodi distinti per raggiungere questo obiettivo:

RDB (Redis Database): Uno snapshot puntuale del tuo dataset.
AOF (Append-Only File): Un registro di ogni operazione di scrittura eseguita dal server.

Entrambi i metodi hanno le loro caratteristiche e sono adatti a scenari diversi.

Redis Database (RDB)

La persistenza RDB esegue snapshot puntuali del tuo dataset Redis a intervalli specificati. Quando viene attivata un'operazione di salvataggio RDB, Redis crea un processo figlio. Il processo figlio scrive quindi l'intero dataset in un file RDB temporaneo. Una volta completato il file, il vecchio file RDB viene sostituito con quello nuovo.

Come Funziona RDB

Fork: Il server Redis crea un nuovo processo figlio.
Snapshot: Il processo figlio inizia a scrivere l'intero dataset in un file RDB temporaneo.
Completamento: Una volta che il processo figlio ha finito di scrivere, sostituisce il vecchio file RDB con quello temporaneo nuovo.
Pulizia: Il processo figlio termina.

Questo processo garantisce che Redis possa continuare a servire le richieste dei client mentre viene eseguito lo snapshot, poiché il processo padre rimane reattivo.

Vantaggi di RDB

Backup Compatti: I file RDB sono compressi in formato binario, offrendo una rappresentazione molto compatta del tuo dataset Redis. Questo li rende ideali per backup e disaster recovery.
Riavvii Veloci: Ricaricare un file RDB è significativamente più veloce che riprodurre un file AOF, specialmente per dataset di grandi dimensioni, poiché comporta il caricamento di un singolo file binario pre-formattato.
I/O su Disco Minimo: I salvataggi RDB avvengono solo a intervalli configurati, il che significa che Redis esegue un I/O su disco minimo quando non sta salvando. Questo può portare a prestazioni più elevate durante le operazioni normali.
Facile da Trasferire: Essendo un singolo file compatto, i backup RDB sono facili da trasferire a data center remoti per il disaster recovery o l'archiviazione.

Svantaggi di RDB

Potenziale Perdita di Dati: Lo svantaggio principale è la potenziale perdita di dati. Se Redis si blocca tra i punti di salvataggio, tutti i dati scritti dall'ultimo salvataggio RDB riuscito andranno persi.
Picco di Prestazioni durante il Fork: Per dataset molto grandi, l'operazione iniziale fork() può essere lenta e bloccare il server Redis per un breve periodo, specialmente se l'utilizzo della memoria è elevato.
Persistenza Non in Tempo Reale: RDB non è progettato per la persistenza dei dati in tempo reale. È più adatto per scenari in cui è accettabile perdere alcuni minuti di dati.

Configurazione RDB

La persistenza RDB è abilitata per impostazione predefinita in redis.conf usando la direttiva save. Puoi specificare più regole save:

# Salva il database ogni 900 secondi (15 minuti) se almeno 1 chiave è cambiata
save 900 1

# Salva il database ogni 300 secondi (5 minuti) se almeno 10 chiavi sono cambiate
save 300 10

# Salva il database ogni 60 secondi se almeno 10000 chiavi sono cambiate
save 60 10000

# Disabilita la persistenza RDB (commenta tutte le direttive save, o imposta esplicitamente quanto segue)
# save ""

Puoi anche attivare un salvataggio RDB manualmente usando i comandi SAVE (bloccante) o BGSAVE (non bloccante) in redis-cli.

Append-Only File (AOF)

La persistenza AOF registra ogni operazione di scrittura ricevuta dal server Redis. Invece di salvare l'intero dataset periodicamente, AOF registra i comandi che modificano il dataset. Quando Redis si riavvia, riesegue questi comandi nel file AOF per ricostruire il dataset originale.

Come Funziona AOF

Registrazione dei Comandi: Ogni comando di scrittura eseguito da Redis viene aggiunto al file AOF.
Politica fsync: Redis ha varie politiche fsync per controllare la frequenza con cui il buffer AOF viene sincronizzato su disco:
- appendfsync always: Sincronizza dopo ogni comando. Offre la massima durabilità ma è il più lento.
- appendfsync everysec: Sincronizza una volta al secondo. È un buon equilibrio tra durabilità e prestazioni (predefinito e consigliato).
- appendfsync no: Si affida al sistema operativo per svuotare il buffer AOF su disco. Offre le migliori prestazioni ma la minima durabilità.
Riscrittura AOF: Col tempo, il file AOF può diventare molto grande a causa di comandi ridondanti (ad esempio, aggiornare la stessa chiave più volte). La riscrittura AOF ottimizza il file AOF creando un nuovo file AOF più piccolo contenente solo i comandi necessari per ricostruire il dataset corrente. Questo processo è simile al meccanismo di fork di RDB.

Vantaggi di AOF

Migliore Durabilità: Con appendfsync always o everysec, AOF offre una durabilità più forte rispetto agli snapshot RDB periodici. Con everysec, Redis di solito limita la perdita a circa un secondo di scritture riconosciute, sebbene i guasti del sistema operativo o del disco possano ancora influenzare la durabilità.
Meno Perdita di Dati: In caso di crash, perdi significativamente meno dati, se non nessuno, a seconda della tua politica fsync.
Formato Ispezionabile: AOF memorizza i comandi del protocollo Redis, quindi può essere ispezionato e riparato con gli strumenti Redis più facilmente di un file RDB.

Svantaggi di AOF

Dimensione del File Maggiore: I file AOF sono generalmente molto più grandi dei file RDB per lo stesso dataset perché memorizzano comandi anziché dati compatti.
Ripristino Più Lento: Riprodurre un file AOF grande all'avvio può essere più lento che caricare un file RDB, poiché Redis deve eseguire ogni comando.
Impatto sulle Prestazioni: A seconda della politica fsync, AOF può introdurre più I/O su disco, potenzialmente influenzando le prestazioni di scrittura. appendfsync always è particolarmente impattante.
Overhead di Riscrittura AOF: Sebbene la riscrittura AOF aiuti a gestire la dimensione del file, il processo di riscrittura stesso consuma risorse CPU e I/O e può bloccare momentaneamente Redis se il dataset è molto grande, simile al fork di RDB.

Configurazione AOF

Per abilitare AOF, devi impostare appendonly yes nel tuo redis.conf:

# Abilita la persistenza AOF
appendonly yes

# Il nome del file append only (predefinito: "appendonly.aof")
appendfilename "appendonly.aof"

# Opzioni appendfsync: always, everysec, no
appendfsync everysec

# Riscrivi automaticamente il file AOF quando è due volte la dimensione della base ed è almeno 64MB
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

RDB vs. AOF: Una Panoramica Comparativa

Caratteristica	RDB (Backup del Database Redis)	AOF (Append-Only File)
Meccanismo	Snapshot puntuali (file binario)	Registro delle operazioni di scrittura in formato protocollo Redis
Perdita di Dati	Perdita potenziale tra i punti di salvataggio	Di solito circa un secondo con `everysec`; massima con `always`
Prestazioni	Maggiori prestazioni di scrittura durante le ops normali, potenziale blocco su `fork()`	Scritture più lente con `fsync` forte, I/O più costante
Dimensione File	File binari molto compatti	Generalmente più grande, cresce con le operazioni
Tempo di Ripristino	Più veloce per dataset grandi	Più lento per dataset grandi (riproduzione dei comandi)
Facilità di Backup	Singolo file compatto; facile per backup/disaster recovery	File più grande, potenzialmente più difficile da gestire senza riscrittura
Leggibilità	Non leggibile dall'uomo	Più ispezionabile di RDB
Predefinito in Redis	Sì (con direttive `save`)	No (`appendonly no` per impostazione predefinita)

L'Approccio Ibrido: RDB e AOF Insieme

Redis può utilizzare snapshot RDB e AOF insieme. Quando AOF è abilitato, Redis usa AOF per il ripristino all'avvio perché di solito è più aggiornato. Il Redis moderno può anche utilizzare un preambolo RDB all'interno dei file AOF riscritti quando aof-use-rdb-preamble yes è abilitato, il che accelera le riscritture e i riavvii.

Riscritture Più Veloci: La parte RDB dell'AOF ibrido fornisce uno snapshot iniziale molto più veloce per il processo di riscrittura.
Riavvii Più Veloci (Potenzialmente): Quando Redis si riavvia, carica prima la porzione RDB del file AOF, che è più veloce, e poi riproduce i successivi comandi AOF.
Migliore Durabilità: Beneficia comunque della minima perdita di dati di AOF.

Controlla la tua versione di Redis e la configurazione prima di presumere che l'AOF ibrido sia abilitato.

Scegliere la Giusta Strategia di Persistenza

La strategia di persistenza ideale dipende dai requisiti specifici della tua applicazione in termini di durabilità dei dati, prestazioni e tempo di ripristino.

1. Quando Usare Solo RDB

Caso d'Uso Principale: Cache / Dati Non Critici: Se Redis è usato principalmente come cache dove perdere alcuni dati in caso di crash è accettabile, o se i tuoi dati possono essere facilmente ricostruiti da un'altra fonte.
Requisiti di Alte Prestazioni: Quando le prestazioni di scrittura sono fondamentali e la perdita occasionale di dati è tollerabile.
Backup per Disaster Recovery: I file RDB sono eccellenti per creare snapshot periodici per l'archiviazione a lungo termine o il disaster recovery. Puoi programmare un BGSAVE con cron e poi spostare il file .rdb fuori sede.
Efficienza di Memoria: Se sei fortemente limitato dallo spazio su disco.

2. Quando Usare Solo AOF

Caso d'Uso Principale: Durabilità Assoluta: Quando ogni singola operazione di scrittura è critica e perdere anche solo pochi secondi di dati è inaccettabile (ad esempio, transazioni finanziarie, dati utente critici). In questo caso, appendfsync always potrebbe essere preso in considerazione, sebbene con un costo significativo in termini di prestazioni.
Debug/Audit: La natura leggibile dall'uomo di AOF può essere utile per comprendere le modifiche ai dati.

3. Quando Usare Sia RDB che AOF (Consigliato per le Applicazioni Più Critiche)

Durabilità e Ripristino Bilanciati: Questo è generalmente l'approccio consigliato per i sistemi di produzione dove la durabilità dei dati è importante, ma si desiderano anche riavvii e backup efficienti.
Robustezza: Fornisce un ulteriore livello di protezione. Se un metodo di persistenza si corrompe, potresti comunque essere in grado di recuperare con l'altro.
AOF Ibrido: Sfrutta il formato AOF con preambolo RDB dove supportato e abilitato.

Suggerimenti Pratici e Migliori Pratiche

Monitora l'Utilizzo del Disco: Sia RDB che AOF possono consumare spazio su disco significativo. Monitora l'utilizzo del disco per assicurarti di non rimanere senza spazio, specialmente prima delle riscritture AOF o dei salvataggi RDB.
Politica fsync: Per AOF, appendfsync everysec è la scelta più comune e consigliata, offrendo un buon equilibrio tra durabilità e prestazioni. Evita appendfsync no per dati critici.
Riscrittura AOF: Configura auto-aof-rewrite-percentage e auto-aof-rewrite-min-size attentamente per garantire che i file AOF siano ottimizzati regolarmente senza un consumo eccessivo di risorse.
Dischi/Luoghi Separati: Se possibile, memorizza i tuoi file di persistenza (AOF e RDB) su un disco o una partizione diversa dal tuo sistema operativo e dai log delle applicazioni per prevenire la contesa di I/O.
Backup Esterni: Indipendentemente dalla tua strategia di persistenza, esegui regolarmente il backup dei tuoi file RDB e AOF in una posizione fuori sede (ad esempio, S3, Google Cloud Storage) per un robusto disaster recovery.
Testa il Ripristino: Testa periodicamente il tuo processo di ripristino con la strategia di persistenza scelta per garantire che i dati possano essere ripristinati con successo.

Conclusione

Scegli la persistenza in base ai requisiti di ripristino, non per abitudine. Redis usato solo come cache può spesso utilizzare RDB o nessuna persistenza. Redis usato per sessioni, code o stato dell'applicazione di solito necessita di AOF, backup testati e un drill di riavvio che dimostri che i dati tornano abbastanza velocemente.