Come funziona la persistenza in Redis (RDB vs AOF)?

Question

Accepted Answer

Sebbene Redis sia in-memory, può **persistere i dati su disco** affinché i dati sopravvivano ai riavvii. Offre due meccanismi — **RDB** (snapshot point-in-time) e **AOF** (log append-only delle operazioni) — con diversi compromessi tra durabilità e performance.

## RDB — snapshot point-in-time

```text
RDB takes SNAPSHOTS of the dataset at intervals, saving a compact binary file.
  ✓ Compact single-file backups; fast restarts (load the snapshot)
  ✓ Good for backups and disaster recovery; less impact on performance
  ✗ You can LOSE data since the last snapshot (e.g. last few minutes) if Redis crashes
→ Configure save points: e.g. "save after 900s if ≥1 change, 300s if ≥10 changes"
```

RDB salva periodicamente l'intero dataset su un file compatto — efficiente e ottimo per i backup, ma un crash comporta la perdita delle modifiche apportate dopo l'ultimo snapshot.

## AOF — log append-only

```text
AOF logs EVERY write operation to a file; on restart, Redis replays the log to rebuild data.
  ✓ More DURABLE — less data loss (can fsync every second, or every write)
  ✓ The log can be rewritten/compacted to stay manageable
  ✗ Larger files; can be slower than RDB; restart (replay) can be slower
→ fsync policies: always (safest, slowest), everysec (good balance), no (fastest, riskiest)
```

AOF registra ogni write, ripetendo l'esecuzione per ricostruire i dati al riavvio — più durevole (meno perdita di dati) ma con file più grandi e potenzialmente performance/riavvii più lenti.

## RDB vs AOF — il compromesso

```text
RDB → better performance, compact backups, faster restart, BUT more potential data loss
AOF → better durability (minimal data loss), BUT larger files, slower

BEST PRACTICE: use BOTH together → RDB for backups + AOF for durability
  → Redis can use both; AOF for recovery, RDB for snapshots/backups
OR: pure cache use → you may DISABLE persistence entirely (data is recreatable)
```

## Perché è importante

Comprendere la persistenza di Redis è importante per **garantire una durabilità dei dati appropriata** quando Redis contiene dati rilevanti, quindi è una conoscenza preziosa per utilizzare Redis correttamente.

Sebbene Redis sia principalmente in-memory, il fatto che **possa persistere su disco** (affinché i dati sopravvivano a riavvii e crash) è importante da comprendere, insieme ai due meccanismi e ai loro compromessi. **RDB** (snapshot point-in-time) offre backup compatti, riavvii veloci e basso impatto sulle performance, ma comporta il rischio di **perdere i dati dall'ultimo snapshot** in caso di crash — ottimo per i backup e accettabile quando una certa perdita di dati è tollerabile. **AOF** (registrazione di ogni operazione di write, ripetute al riavvio) offre **migliore durabilità** (perdita minima di dati, configurabile tramite politiche fsync) ma con file più grandi e potenzialmente performance/riavvii più lenti.

Comprendere il **compromesso** (RDB per performance e backup compatti vs AOF per durabilità) e la **best practice comune di usare entrambi insieme** (RDB per snapshot/backup più AOF per durabilità) riflette un giudizio di configurazione consapevole.

È anche importante riconoscere che per un uso **puramente cache** (dove i dati sono ricreabili dalla fonte), la persistenza può essere disabilitata completamente — Redis non ha sempre bisogno di durabilità.

Scegliere la configurazione di persistenza corretta in base al caso d'uso (esigenze di durabilità vs performance, o nessuna per cache pura) è l'abilità pratica chiave.

Poiché la durabilità dei dati è importante quando Redis contiene dati rilevanti (sessioni, code, dati primari), e poiché comprendere RDB, AOF, i loro compromessi e le best practice (entrambi insieme, o nessuno per cache) è necessario per configurare Redis appropriatamente, comprendere la persistenza di Redis è una conoscenza preziosa e praticamente rilevante per utilizzare Redis responsabilmente — garantendo il giusto livello di durabilità per i dati che Redis contiene, un argomento che riflette la comprensione di Redis oltre il semplice caching.