Cum funcționează persistența în Redis (RDB vs AOF)?

Question

Accepted Answer

Deși Redis este în memorie, poate **persista date pe disc** pentru ca datele să supraviețuiască redemarrilor. Oferă două mecanisme — **RDB** (snapshot-uri punctuale în timp) și **AOF** (jurnal append-only de operații) — cu compromisuri diferite între durabilitate și performanță.

## RDB — snapshot-uri punctuale în timp

```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 salvează periodic întregul set de date într-un fișier compact — eficient și excelent pentru backup-uri, dar o cădere pierde modificările efectuate după ultimul snapshot.

## AOF — jurnal 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 înregistrează fiecare scriere, redând-o pentru a reconstrui datele la restart — mai durabil (mai puțină pierdere de date) dar cu fișiere mai mari și potențial performanță mai lentă/restarturi.

## RDB vs AOF — compromisul

```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)
```

## De ce contează

Înțelegerea persistenței Redis este importantă pentru **asigurarea durabilității corecte a datelor** atunci când Redis conține date care contează, deci este cunoaștere valoroasă pentru utilizarea corectă a Redis.

Deși Redis este în primul rând în memorie, faptul că **poate persista pe disc** (pentru ca datele să supraviețuiască redemarrilor și căderi) este important de înțeles, alături de cele două mecanisme și compromisurile lor. **RDB** (snapshot-uri punctuale în timp) oferă backup-uri compacte, restarturi rapide și impact scăzut asupra performanței, dar risca **pierderea datelor din ultimul snapshot** la o cădere — bun pentru backup-uri și acceptabil când o oarecare pierdere de date este tolerabilă. **AOF** (înregistrarea fiecărei operații de scriere, redată la restart) oferă **durabilitate mai bună** (pierdere minimă de date, configurabilă prin politici fsync) dar cu fișiere mai mari și potențial performanță mai lentă/restarturi.

Înțelegerea **compromisului** (RDB pentru performanță și backup-uri compacte vs AOF pentru durabilitate) și **cea mai bună practică comună de utilizare a ambelor împreună** (RDB pentru snapshot-uri/backup-uri plus AOF pentru durabilitate) reflectă judecată de configurare sănătoasă.

De asemenea, important este a recunoaște că pentru **utilizare pură de cache** (unde datele sunt recreabile din sursă), persistența poate fi dezactivată complet — Redis nu are întotdeauna nevoie de durabilitate.

Alegerea configurației de persistență corecte bazată pe cazul de utilizare (nevoie de durabilitate vs performanță, sau niciunul pentru pure cache) este abilitatea practică cheie.

Deoarece durabilitatea datelor contează atunci când Redis ține date importante (sesiuni, cozi, date primare), și deoarece înțelegerea RDB, AOF, compromisurile lor și cele mai bune practici (ambele împreună, sau niciunul pentru cache) este necesară pentru a configura Redis în mod corespunzător, înțelegerea persistenței Redis este cunoaștere valoroasă și practic relevantă pentru utilizarea responsabilă a Redis — asigurând nivelul corect de durabilitate pentru datele pe care le ține Redis, un subiect care reflectă înțelegere a Redis dincolo de simple caching.