Opzioni di persistenza di Redis: RDB vs AOF spiegati

Redis è rinomato per la sua velocità come archivio di strutture dati in memoria, spesso utilizzato come cache o message broker. Tuttavia, mentre i dati risiedono principalmente nella RAM per la velocità, le distribuzioni di produzione richiedono meccanismi per garantire che i dati sopravvivano a riavvii o crash. È qui che entra in gioco la persistenza. Redis offre due meccanismi di persistenza integrati principali: Redis Database Backup (RDB) e Append-Only File (AOF). La comprensione dei compromessi tra questi due è fondamentale per configurare Redis in modo appropriato per le esigenze di durabilità e prestazioni della tua applicazione.

Questa guida spiegherà in modo approfondito come funzionano RDB e AOF, confronterà i loro vantaggi e svantaggi e fornirà indicazioni su quando utilizzare ciascuna strategia.

Comprensione della persistenza di Redis

La persistenza in Redis si riferisce al processo di scrittura dello stato corrente del set di dati in memoria su disco. Ciò consente a Redis di ricaricare i dati quando il server viene riavviato. Senza la persistenza abilitata, tutti i dati vengono persi alla chiusura.

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

1. Redis Database Backup (RDB)

RDB (Redis Database Backup) è il meccanismo di persistenza predefinito di Redis. Esegue snapshot periodici dell'intero set di dati a intervalli specificati.

Come funziona RDB

RDB opera creando un fork del processo Redis principale, generando un processo figlio che scrive i contenuti correnti della memoria in un file binario compresso denominato dump.rdb sul disco. Poiché si tratta di uno snapshot, cattura i dati in un momento specifico.

Configurazione e Snapshotting

La configurazione RDB è gestita tramite le direttive save nel file redis.conf. Queste direttive definiscono le condizioni in cui avviene un salvataggio 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 completamente la persistenza RDB, puoi commentare tutte le direttive save o utilizzare il comando SAVE solo manualmente.

Vantaggi di RDB

File compatti: i file RDB sono altamente ottimizzati, compressi e compatti, rendendoli ideali per backup e trasferimenti veloci.
Recupero veloce: Poiché si tratta di un singolo file snapshot, il caricamento dei dati durante il riavvio è molto rapido.
Prestazioni: i salvataggi avvengono in modo asincrono tramite il fork del processo, il che significa che il thread principale non viene bloccato durante l'operazione di scrittura (sebbene il fork stesso possa causare brevi picchi di latenza).

Svantaggi di RDB

Rischio di perdita dati: se Redis si blocca tra i punti di salvataggio programmati, tutte le scritture avvenute dopo l'ultimo snapshot andranno perse.
Overhead del fork: su set di dati molto grandi, l'operazione di fork necessaria per creare lo snapshot può consumare risorse significative del sistema e causare una breve latenza.

2. Append-Only File (AOF)

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

Come funziona AOF

Quando la persistenza è abilitata, Redis reindirizza ogni comando di scrittura (ad es. SET, LPUSH) a un file AOF su disco. Quando Redis viene riavviato, riproduce questi comandi sequenzialmente per ricostruire il set di dati esattamente come era prima della chiusura.

Configurazione AOF

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

appendonly yes

Fondamentalmente, AOF consente la configurazione della policy di fsync, che determina la frequenza con cui le scritture vengono forzate su disco:

Policy di fsync	Descrizione	Durabilità vs Prestazioni
`no`	Il sistema operativo gestisce la sincronizzazione (meno frequente).	Più veloce, rischio di perdita maggiore.
`everysec`	Sincronizza una volta al secondo (predefinito e consigliato).	Buon equilibrio. Al massimo, si perde 1 secondo di dati.
`always`	Sincronizza dopo ogni comando.	Durabilità massima, potenziale impatto significativo sulle prestazioni.

Vantaggi di AOF

Elevata durabilità: impostando fsync su always, puoi ottenere una perdita di dati quasi nulla.
Riproduzione del log: il file AOF contiene un log cronologico delle operazioni, rendendo più semplice il debug di potenziali corruzioni dei dati.

Svantaggi di AOF

File più grandi: i file AOF sono tipicamente molto più grandi dei corrispondenti file RDB perché memorizzano comandi anziché lo stato finale dei dati.
Riavvio più lento: la riproduzione di migliaia di comandi durante l'avvio richiede più tempo rispetto al caricamento di un singolo snapshot RDB.
Amplificazione di scrittura: i comandi vengono registrati individualmente, il che può portare a un overhead di scrittura leggermente superiore rispetto allo snapshotting RDB.

Riscrittura AOF

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

RDB vs AOF: Confronto diretto

La scelta tra RDB, AOF o entrambi dipende interamente dai requisiti della tua applicazione in termini di tempo di recupero e tolleranza alla perdita di dati.

Caratteristica	RDB (Snapshotting)	AOF (Append-Only File)
Durabilità/Perdita dati	Potenziale perdita dati maggiore (dall'ultimo salvataggio).	Perdita 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 rapido dello snapshot.	Più lento, richiede la riproduzione dei comandi.
Complessità	Semplice, configurato tramite intervalli di tempo.	Richiede un'attenta configurazione della policy `fsync`.
Caso d'uso	Backup, recupero da disastri in cui la perdita di dati recenti è tollerabile.	Meccanismo di persistenza primario che richiede un'elevata durabilità.

Migliore pratica: combinare RDB e AOF

Per la maggior parte delle distribuzioni di produzione moderne, l'approccio consigliato è abilitare contemporaneamente la persistenza RDB e AOF.

Quando entrambi sono abilitati:
1. AOF fornisce il log primario ad alta durabilità.
2. RDB fornisce un backup snapshot veloce e compatto.

Al riavvio, Redis preferirà caricare il file AOF per una durabilità completa. Se il file AOF è mancante o corrotto, ripiegherà sul caricamento del file RDB. Inoltre, il processo di riscrittura AOF utilizza spesso il file RDB come punto di partenza efficiente, unendo i vantaggi di entrambi i metodi.

Come abilitare entrambi

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

# Abilita AOF
appendonly yes

# Mantieni la configurazione RDB (ad es. salvataggio automatico ogni ora)
save 3600 1

# Policy fsync consigliata per AOF
appendfsync everysec

Suggerimento sulla riscrittura AOF: puoi attivare manualmente una riscrittura AOF in qualsiasi momento utilizzando il comando BGREWRITEAOF. Questo è particolarmente utile dopo caricamenti di dati in blocco di grandi dimensioni o operazioni di pulizia significative per ridurre immediatamente le dimensioni del file AOF.