Wie funktioniert Redis-Persistenz (RDB vs AOF)?

Question

Accepted Answer

Obwohl Redis ein In-Memory-Datenstore ist, kann es **Daten auf die Festplatte persistieren**, sodass Daten Neustarts überstehen. Es bietet zwei Mechanismen — **RDB** (Point-in-Time-Snapshots) und **AOF** (Append-Only-Log von Operationen) — mit unterschiedlichen Dauerhaftigkeits-/Leistungs-Kompromissen.

## RDB — Point-in-Time-Snapshots

```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 speichert regelmäßig den gesamten Datensatz in einer kompakten Datei — effizient und großartig für Backups, aber ein Absturz verliert Änderungen seit dem letzten Snapshot.

## AOF — Append-Only-Log

```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 zeichnet jeden Schreibvorgang auf und spielt ihn beim Neustart ab, um Daten wiederherzustellen — dauerhafter (weniger Datenverlust), aber mit größeren Dateien und potenziell langsamerer Leistung/Neustarts.

## RDB vs AOF — der Kompromiss

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

## Warum es wichtig ist

Das Verständnis von Redis-Persistenz ist wichtig für die **Sicherstellung angemessener Datendauerhaftigkeit**, wenn Redis Daten hält, die wichtig sind, sodass es wertvoll ist, Redis korrekt zu nutzen.

Obwohl Redis hauptsächlich In-Memory ist, ist es wichtig zu verstehen, dass es **auf die Festplatte persistieren kann** (sodass Daten Neustarts und Abstürze überstehen) sowie die beiden Mechanismen und ihre Kompromisse. **RDB** (Point-in-Time-Snapshots) bietet kompakte Backups, schnelle Neustarts und geringe Leistungsauswirkungen, aber riskiert **Datenverlust seit dem letzten Snapshot** bei einem Absturz — gut für Backups und akzeptabel, wenn ein gewisser Datenverlust tolerierbar ist. **AOF** (Protokollierung jeder Schreiboperation, Wiederherstellung beim Neustart) bietet **bessere Dauerhaftigkeit** (minimaler Datenverlust, konfigurierbar über fsync-Richtlinien), aber mit größeren Dateien und potenziell langsamerer Leistung/Neustarts.

Das Verständnis des **Kompromisses** (RDB für Leistung und kompakte Backups vs AOF für Dauerhaftigkeit) und der häufigen **Best Practice, beide zusammen zu verwenden** (RDB für Snapshots/Backups plus AOF für Dauerhaftigkeit) spiegelt solides Konfigurationsurteilsvermögen wider.

Auch wichtig ist zu erkennen, dass für **reine Cache-Nutzung** (wo Daten aus der Quelle rekonstruierbar sind) die Persistierung vollständig deaktiviert werden kann — Redis benötigt nicht immer Dauerhaftigkeit.

Die richtige Persistierungskonfiguration basierend auf dem Use Case (Dauerhaftigkeitsanforderungen vs Leistung oder keine für reine Caches) zu wählen, ist die wichtigste praktische Fähigkeit.

Da Datendauerhaftigkeit wichtig ist, wenn Redis wichtige Daten hält (Sessions, Queues, primäre Daten), und da das Verständnis von RDB, AOF, ihren Kompromissen und Best Practices (beide zusammen oder keine für Caching) notwendig ist, um Redis angemessen zu konfigurieren, ist das Verständnis von Redis-Persistenz wertvoll, praktisch relevantes Wissen für die verantwortungsvolle Nutzung von Redis — um die richtige Dauerhaftigkeitsstufe für die Daten zu gewährleisten, die Redis hält, ein Thema, das Verständnis von Redis über einfaches Caching hinaus widerspiegelt.