Opzioni di Persistenza Redis: RDB vs. AOF Spiegati

La persistenza di Redis determina quanti dati il tuo server Redis può recuperare dopo un riavvio o un crash. Le due opzioni principali sono gli snapshot RDB e i log AOF, e la scelta giusta dipende da quanti dati recenti la tua applicazione può permettersi di perdere.

Redis mantiene i dati in memoria per la velocità. La persistenza scrive abbastanza stato su disco in modo che Redis possa ricostruire quei dati in seguito. Puoi usare RDB, AOF, entrambi o nessuno, ma i sistemi di produzione dovrebbero fare questa scelta deliberatamente.

Comprendere la Persistenza di Redis

La persistenza in Redis si riferisce al processo di scrittura dello stato corrente del dataset in memoria su disco. Questo permette a Redis di ricaricare i dati quando il server si riavvia. Senza persistenza abilitata, tutti i dati vengono persi allo spegnimento.

Redis supporta sia RDB che AOF simultaneamente, offrendo un approccio ibrido che combina le migliori caratteristiche di entrambi.

Snapshot RDB

RDB crea snapshot puntuali del tuo dataset e li scrive in un file binario compatto, comunemente chiamato dump.rdb.

Come Funziona RDB

RDB normalmente funziona creando un fork del processo Redis. Il processo figlio scrive il dataset su disco mentre il genitore continua a servire i client. Poiché RDB è uno snapshot, cattura i dati come esistevano in un momento specifico.

Configurazione e Snapshotting

La configurazione RDB è gestita con direttive save in redis.conf. Queste direttive definiscono quando Redis dovrebbe creare uno snapshot automatico:

# Salva il DB se 1000 chiavi sono cambiate in 1 minuto
save 600 1000
# Salva il DB se 10 chiavi sono cambiate in 10 minuti
save 300 10
# Salva il DB se 10000 chiavi sono cambiate in 1 secondo
save 1 10000

Per disabilitare gli snapshot RDB automatici, rimuovi le direttive save o imposta:

save ""

Puoi comunque attivare uno snapshot manuale in background con BGSAVE quando ne hai bisogno.

Vantaggi di RDB

File compatti: I file RDB sono efficienti per backup, copie e archivi di disaster recovery.
Recupero veloce: Caricare uno snapshot è di solito più veloce che riprodurre un lungo log di comandi.
Minore overhead di scrittura costante: Redis non scrive ogni comando nel file di persistenza.

Svantaggi di RDB

Rischio di perdita dati: Se Redis si blocca tra uno snapshot e l'altro, le scritture dopo l'ultimo snapshot riuscito vengono perse.
Overhead del fork: Dataset grandi possono rendere fork() costoso e causare picchi di latenza.
Non un log di audit completo: RDB memorizza lo stato finale, non ogni scrittura che lo ha portato.

Log AOF

AOF (Append-Only File) offre un livello più alto di durabilità dei dati. Invece di snapshot, AOF registra ogni operazione di scrittura ricevuta dal server in un formato append-only.

Come Funziona AOF

Quando AOF è abilitato, Redis registra comandi di scrittura come SET, HSET e LPUSH in un file append-only. Al riavvio, Redis riproduce quel file per ricostruire il dataset.

Configurazione AOF

La persistenza AOF è disabilitata per impostazione predefinita e deve essere esplicitamente abilitata in redis.conf:

appendonly yes

Fondamentalmente, AOF permette la configurazione della politica fsync, determinando quanto frequentemente le scritture vengono forzate su disco:

Politica fsync	Descrizione	Durabilità vs. Prestazioni
`no`	Il sistema operativo gestisce la sincronizzazione (meno frequente).	Più veloce, rischio più alto di perdita.
`everysec`	Sincronizza circa una volta al secondo.	Buon equilibrio. Di solito limita la perdita a circa un secondo durante un crash del server.
`always`	Sincronizza dopo ogni comando.	Massima durabilità, potenziale impatto significativo sulle prestazioni.

Vantaggi di AOF

Maggiore durabilità: appendfsync everysec è un comune equilibrio di produzione; always è più rigoroso ma più lento.
Intento leggibile: AOF memorizza comandi di scrittura, quindi può essere più facile da ispezionare rispetto a un file binario RDB.
Compattazione automatica: La riscrittura AOF può ridurre un grande log ai comandi minimi necessari per ricostruire lo stato corrente.

Svantaggi di AOF

File più grandi: I file AOF sono spesso più grandi degli snapshot RDB perché memorizzano comandi.
Riavvio più lento: Riprodurre un lungo AOF può richiedere più tempo che caricare uno snapshot RDB.
Maggiore overhead di scrittura: Redis deve aggiungere comandi di scrittura e sincronizzarli secondo la tua impostazione appendfsync.

Riscrittura AOF

Per combattere la crescita delle dimensioni dei file, Redis implementa la riscrittura AOF. Questo processo crea asincronicamente un nuovo file AOF ottimizzato contenente solo i comandi necessari per raggiungere lo stato corrente, scartando efficacemente comandi ridondanti o obsoleti (come aggiornamenti multipli alla stessa chiave).

RDB vs. AOF: Confronto Diretto

Scegliere tra RDB, AOF o entrambi dipende interamente dai requisiti della tua applicazione per il tempo di recupero e la tolleranza alla perdita di dati.

Caratteristica	RDB (Snapshotting)	AOF (Append-Only File)
Durabilità/Perdita Dati	Maggiore potenziale perdita di dati (dall'ultimo salvataggio).	Perdita di dati minima (fino a 1 secondo, o zero con `fsync=always`).
Dimensione File	Molto compatto e ottimizzato.	Più grande a causa della registrazione dei comandi.
Tempo di Riavvio	Caricamento molto veloce dello snapshot.	Più lento, richiede la riproduzione dei comandi.
Complessità	Semplice, configurato per intervalli di tempo.	Richiede una configurazione attenta della politica `fsync`.
Caso d'Uso	Backup, disaster recovery dove la perdita di dati recenti è tollerabile.	Meccanismo di persistenza primario che richiede alta durabilità.

Migliore Pratica: Combinare RDB e AOF

Per molte implementazioni di produzione, abilitare sia RDB che AOF ti dà una rete di sicurezza utile.

Quando entrambi sono abilitati:

AOF fornisce il log primario ad alta durabilità.
RDB fornisce uno snapshot di backup veloce e compatto.

Quando entrambi sono abilitati, Redis carica l'AOF al riavvio perché è di solito più completo dell'ultimo snapshot RDB. RDB ti dà comunque file di backup compatti facili da copiare, testare e archiviare.

Come Abilitare Entrambi

Assicurati che entrambe le configurazioni siano impostate in redis.conf:

# Abilita AOF
appendonly yes

# Mantieni la configurazione RDB (es., autosalvataggio ogni ora)
save 3600 1

# Politica fsync raccomandata per AOF
appendfsync everysec

Suggerimento sulla Riscrittura AOF: Puoi attivare manualmente una riscrittura AOF in qualsiasi momento usando il comando BGREWRITEAOF. Questo è particolarmente utile dopo grandi carichi di dati in blocco o operazioni di eliminazione significative per ridurre immediatamente la dimensione del file AOF.

Conclusione

Usa RDB quando vuoi backup compatti e puoi tollerare la perdita di scritture recenti dall'ultimo snapshot. Usa AOF quando Redis contiene dati che dovrebbero sopravvivere ai crash con una perdita minima. Per dati di produzione importanti, abilita AOF con appendfsync everysec, mantieni gli snapshot RDB per il backup e testa il tempo di ripristino prima che un'emergenza ponga la domanda.