Die beste Redis-Persistenzstrategie wählen: RDB vs. AOF

Redis speichert Daten im Arbeitsspeicher, daher benötigst du eine Persistenzstrategie, bevor du dich darauf verlässt, wenn du etwas nicht einfach neu aufbauen kannst. Die Wahl zwischen RDB und AOF beeinflusst, wie viele Daten du verlieren kannst, wie schnell Redis neu startet und wie viel Festplatten-I/O deine Workload erzeugt.

Verwende RDB, wenn periodische Schnappschüsse ausreichen. Verwende AOF, wenn du eine höhere Haltbarkeit benötigst. Verwende beide, wenn du praktische Haltbarkeit plus einfachere Backups möchtest, aber teste die Wiederherstellung mit deinem echten Datensatz.

Redis-Persistenz verstehen

Persistenz in Redis bezieht sich auf die Fähigkeit, den In-Memory-Datensatz auf die Festplatte zu speichern, damit er nach einem Serverneustart oder -absturz neu geladen werden kann. Ohne Persistenz gehen alle in Redis gespeicherten Daten verloren, wenn der Server stoppt oder abstürzt. Redis bietet zwei verschiedene Methoden, um dies zu erreichen:

RDB (Redis Database): Ein punktgenauer Schnappschuss deines Datensatzes.
AOF (Append-Only File): Ein Protokoll aller Schreiboperationen, die vom Server ausgeführt werden.

Beide Methoden haben ihre eigenen Eigenschaften und sind für verschiedene Szenarien geeignet.

Redis Database (RDB)

RDB-Persistenz erstellt punktgenaue Schnappschüsse deines Redis-Datensatzes in bestimmten Intervallen. Wenn ein RDB-Speichervorgang ausgelöst wird, forkt Redis einen Kindprozess. Der Kindprozess schreibt dann den gesamten Datensatz in eine temporäre RDB-Datei. Sobald die Datei vollständig ist, wird die alte RDB-Datei durch die neue ersetzt.

Wie RDB funktioniert

Forking: Der Redis-Server forkt einen neuen Kindprozess.
Schnappschuss: Der Kindprozess beginnt, den gesamten Datensatz in eine temporäre RDB-Datei zu schreiben.
Abschluss: Sobald der Kindprozess das Schreiben beendet hat, ersetzt er die alte RDB-Datei durch die neue temporäre.
Bereinigung: Der Kindprozess wird beendet.

Dieser Prozess stellt sicher, dass Redis weiterhin Client-Anfragen bedienen kann, während der Schnappschuss erstellt wird, da der Elternprozess reaktionsfähig bleibt.

Vorteile von RDB

Kompakte Backups: RDB-Dateien sind binär komprimiert und bieten eine sehr kompakte Darstellung deines Redis-Datensatzes. Dies macht sie ideal für Backups und Notfallwiederherstellung.
Schnelle Neustarts: Das Laden einer RDB-Datei ist deutlich schneller als das Abspielen einer AOF-Datei, insbesondere bei großen Datensätzen, da es das Laden einer einzelnen, vorformatierten Binärdatei beinhaltet.
Minimale Festplatten-I/O: RDB-Speicherungen erfolgen nur in konfigurierten Intervallen, was bedeutet, dass Redis bei Nicht-Speicherung minimale Festplatten-I/O durchführt. Dies kann zu einer höheren Leistung während des normalen Betriebs führen.
Einfach zu übertragen: Als einzelne, kompakte Datei sind RDB-Backups einfach zu entfernten Rechenzentren für die Notfallwiederherstellung oder Archivierung zu übertragen.

Nachteile von RDB

Potentieller Datenverlust: Der Hauptnachteil ist das Potenzial für Datenverlust. Wenn Redis zwischen Speicherpunkten abstürzt, gehen alle Daten verloren, die seit dem letzten erfolgreichen RDB-Speichervorgang geschrieben wurden.
Leistungsspitze während des Fork: Bei sehr großen Datensätzen kann der anfängliche fork()-Vorgang langsam sein und den Redis-Server für kurze Zeit blockieren, insbesondere wenn die Speichernutzung hoch ist.
Keine Echtzeit-Persistenz: RDB ist nicht für die Echtzeit-Persistenz von Daten ausgelegt. Es eignet sich am besten für Szenarien, in denen der Verlust einiger Minuten Daten akzeptabel ist.

RDB-Konfiguration

RDB-Persistenz ist standardmäßig in redis.conf mit der save-Direktive aktiviert. Du kannst mehrere save-Regeln angeben:

# Speichere die Datenbank alle 900 Sekunden (15 Minuten), wenn mindestens 1 Schlüssel geändert wurde
save 900 1

# Speichere die Datenbank alle 300 Sekunden (5 Minuten), wenn mindestens 10 Schlüssel geändert wurden
save 300 10

# Speichere die Datenbank alle 60 Sekunden, wenn mindestens 10000 Schlüssel geändert wurden
save 60 10000

# Deaktiviere RDB-Persistenz (alle save-Direktiven auskommentieren oder explizit unten setzen)
# save ""

Du kannst auch manuell einen RDB-Speichervorgang mit den Befehlen SAVE (blockierend) oder BGSAVE (nicht blockierend) in der redis-cli auslösen.

Append-Only File (AOF)

AOF-Persistenz protokolliert jeden Schreibvorgang, den der Redis-Server empfängt. Anstatt den gesamten Datensatz periodisch zu speichern, zeichnet AOF die Befehle auf, die den Datensatz ändern. Wenn Redis neu startet, führt es diese Befehle in der AOF-Datei erneut aus, um den ursprünglichen Datensatz zu rekonstruieren.

Wie AOF funktioniert

Befehlsprotokollierung: Jeder von Redis ausgeführte Schreibbefehl wird an die AOF-Datei angehängt.
fsync-Richtlinie: Redis hat verschiedene fsync-Richtlinien, um zu steuern, wie oft der AOF-Puffer auf die Festplatte synchronisiert wird:
- appendfsync always: Synchronisiert nach jedem Befehl. Dies bietet die beste Haltbarkeit, ist aber am langsamsten.
- appendfsync everysec: Synchronisiert einmal pro Sekunde. Dies ist ein guter Kompromiss zwischen Haltbarkeit und Leistung (Standard und empfohlen).
- appendfsync no: Verlässt sich auf das Betriebssystem, um den AOF-Puffer auf die Festplatte zu leeren. Bietet die beste Leistung, aber die geringste Haltbarkeit.
AOF-Neuschreiben: Im Laufe der Zeit kann die AOF-Datei aufgrund redundanter Befehle (z.B. mehrmaliges Aktualisieren desselben Schlüssels) sehr groß werden. Das AOF-Neuschreiben optimiert die AOF-Datei, indem es eine neue, kleinere AOF-Datei erstellt, die nur die notwendigen Befehle zur Rekonstruktion des aktuellen Datensatzes enthält. Dieser Prozess ähnelt dem Forking-Mechanismus von RDB.

Vorteile von AOF

Bessere Haltbarkeit: Mit appendfsync always oder everysec bietet AOF eine stärkere Haltbarkeit als periodische RDB-Schnappschüsse. Mit everysec begrenzt Redis den Verlust normalerweise auf etwa eine Sekunde bestätigter Schreibvorgänge, obwohl Betriebssystem- oder Festplattenfehler die Haltbarkeit immer noch beeinträchtigen können.
Weniger Datenverlust: Im Falle eines Absturzes verlierst du deutlich weniger Daten, wenn überhaupt, abhängig von deiner fsync-Richtlinie.
Überprüfbares Format: AOF speichert Redis-Protokollbefehle, sodass es mit Redis-Tools einfacher überprüft und repariert werden kann als eine RDB-Datei.

Nachteile von AOF

Größere Dateigröße: AOF-Dateien sind im Allgemeinen viel größer als RDB-Dateien für denselben Datensatz, da sie Befehle anstelle von kompakten Daten speichern.
Langsamere Wiederherstellung: Das Abspielen einer großen AOF-Datei beim Start kann langsamer sein als das Laden einer RDB-Datei, da Redis jeden Befehl ausführen muss.
Leistungsauswirkungen: Abhängig von der fsync-Richtlinie kann AOF mehr Festplatten-I/O verursachen, was die Schreibleistung potenziell beeinträchtigt. appendfsync always ist besonders wirkungsvoll.
Overhead beim AOF-Neuschreiben: Während das AOF-Neuschreiben hilft, die Dateigröße zu verwalten, verbraucht der Neuschreibprozess selbst CPU- und I/O-Ressourcen und kann Redis vorübergehend blockieren, wenn der Datensatz sehr groß ist, ähnlich wie beim RDB-Forking.

AOF-Konfiguration

Um AOF zu aktivieren, musst du appendonly yes in deiner redis.conf setzen:

# Aktiviere AOF-Persistenz
appendonly yes

# Der Name der Append-Only-Datei (Standard: "appendonly.aof")
appendfilename "appendonly.aof"

# appendfsync-Optionen: always, everysec, no
appendfsync everysec

# Automatisches Neuschreiben der AOF-Datei, wenn sie doppelt so groß wie die Basis ist und mindestens 64 MB beträgt
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

RDB vs. AOF: Ein vergleichender Überblick

Merkmal	RDB (Redis Database Backup)	AOF (Append-Only File)
Mechanismus	Punktgenaue Schnappschüsse (Binärdatei)	Protokoll der Schreiboperationen im Redis-Protokollformat
Datenverlust	Potenzieller Verlust zwischen Speicherpunkten	Normalerweise etwa eine Sekunde mit `everysec`; am stärksten mit `always`
Leistung	Höhere Schreibleistung während normalem Betrieb, potenzielle Blockierung bei `fork()`	Langsamere Schreibvorgänge mit starkem `fsync`, konsistentere I/O
Dateigröße	Sehr kompakte Binärdateien	Im Allgemeinen größer, wächst mit den Operationen
Wiederherstellungszeit	Schneller für große Datensätze	Langsamer für große Datensätze (Abspielen von Befehlen)
Backup-Einfachheit	Einzelne, kompakte Datei; einfach für Backups/Notfallwiederherstellung	Größere Datei, potenziell schwieriger zu verwalten ohne Neuschreiben
Lesbarkeit	Nicht für Menschen lesbar	Besser überprüfbar als RDB
Standard in Redis	Ja (mit `save`-Direktiven)	Nein (`appendonly no` standardmäßig)

Der hybride Ansatz: RDB und AOF zusammen

Redis kann RDB-Schnappschüsse und AOF zusammen verwenden. Wenn AOF aktiviert ist, verwendet Redis AOF für die Startwiederherstellung, da es normalerweise aktueller ist. Modernes Redis kann auch eine RDB-Präambel innerhalb neu geschriebener AOF-Dateien verwenden, wenn aof-use-rdb-preamble yes aktiviert ist, was Neuschreibvorgänge und Neustarts beschleunigt.

Schnellere Neuschreibvorgänge: Der RDB-Teil des hybriden AOF bietet einen viel schnelleren anfänglichen Schnappschuss für den Neuschreibprozess.
Schnellere Neustarts (potenziell): Wenn Redis neu startet, lädt es zuerst den RDB-Teil der AOF-Datei, was schneller ist, und spielt dann die nachfolgenden AOF-Befehle ab.
Bessere Haltbarkeit: Profitiert immer noch vom minimalen Datenverlust von AOF.

Überprüfe deine Redis-Version und -Konfiguration, bevor du annimmst, dass hybrides AOF aktiviert ist.

Die richtige Persistenzstrategie wählen

Die ideale Persistenzstrategie hängt von den spezifischen Anforderungen deiner Anwendung an Datenhaltbarkeit, Leistung und Wiederherstellungszeit ab.

1. Wann nur RDB verwenden

Hauptanwendungsfall: Cache / Nicht-kritische Daten: Wenn Redis hauptsächlich als Cache verwendet wird, bei dem der Verlust einiger Daten bei einem Absturz akzeptabel ist, oder wenn deine Daten leicht aus einer anderen Quelle rekonstruiert werden können.
Hohe Leistungsanforderungen: Wenn die Schreibleistung von größter Bedeutung ist und gelegentlicher Datenverlust tolerierbar ist.
Notfallwiederherstellungs-Backups: RDB-Dateien eignen sich hervorragend zum Erstellen periodischer Schnappschüsse für die langfristige Archivierung oder Notfallwiederherstellung. Du kannst einen BGSAVE per cron ausführen und dann die .rdb-Datei extern verschieben.
Speichereffizienz: Wenn du stark durch Festplattenspeicher eingeschränkt bist.

2. Wann nur AOF verwenden

Hauptanwendungsfall: Absolute Haltbarkeit: Wenn jeder einzelne Schreibvorgang kritisch ist und der Verlust selbst weniger Sekunden Daten inakzeptabel ist (z.B. Finanztransaktionen, kritische Benutzerdaten). In diesem Fall könnte appendfsync always in Betracht gezogen werden, allerdings mit erheblichen Leistungskosten.
Debugging/Prüfung: Die für Menschen lesbare Natur von AOF kann für das Verständnis von Datenänderungen vorteilhaft sein.

3. Wann sowohl RDB als auch AOF verwenden (Empfohlen für die meisten kritischen Anwendungen)

Ausgewogene Haltbarkeit und Wiederherstellung: Dies ist im Allgemeinen der empfohlene Ansatz für Produktionssysteme, bei denen Datenhaltbarkeit wichtig ist, du aber auch effiziente Neustarts und Backups wünschst.
Robustheit: Bietet eine zusätzliche Schutzschicht. Wenn eine Persistenzmethode beschädigt wird, kannst du möglicherweise immer noch mit der anderen wiederherstellen.
Hybrides AOF: Nutze das AOF-Format mit RDB-Präambel, wo unterstützt und aktiviert.

Praktische Tipps und bewährte Verfahren

Überwache die Festplattennutzung: Sowohl RDB als auch AOF können erheblichen Festplattenspeicher verbrauchen. Überwache deine Festplattennutzung, um sicherzustellen, dass dir nicht der Speicherplatz ausgeht, insbesondere vor AOF-Neuschreibvorgängen oder RDB-Speicherungen.
fsync-Richtlinie: Für AOF ist appendfsync everysec die häufigste und empfohlene Wahl und bietet einen guten Kompromiss zwischen Haltbarkeit und Leistung. Vermeide appendfsync no für kritische Daten.
AOF-Neuschreiben: Konfiguriere auto-aof-rewrite-percentage und auto-aof-rewrite-min-size sorgfältig, um sicherzustellen, dass AOF-Dateien regelmäßig optimiert werden, ohne übermäßige Ressourcen zu verbrauchen.
Separate Festplatten/Standorte: Wenn möglich, speichere deine Persistenzdateien (AOF und RDB) auf einer anderen Festplatte oder Partition als dein Betriebssystem und Anwendungsprotokolle, um I/O-Konflikte zu vermeiden.
Externe Backups: Erstelle unabhängig von deiner Persistenzstrategie regelmäßig Backups deiner RDB- und AOF-Dateien an einem externen Standort (z.B. S3, Google Cloud Storage) für eine robuste Notfallwiederherstellung.
Wiederherstellung testen: Teste regelmäßig deinen Wiederherstellungsprozess mit deiner gewählten Persistenzstrategie, um sicherzustellen, dass Daten erfolgreich wiederhergestellt werden können.

Fazit

Wähle die Persistenz basierend auf den Wiederherstellungsanforderungen, nicht aus Gewohnheit. Cache-only Redis kann oft RDB oder keine Persistenz verwenden. Redis, das für Sitzungen, Warteschlangen oder Anwendungszustand verwendet wird, benötigt normalerweise AOF, getestete Backups und eine Neustart-Übung, die beweist, dass die Daten schnell genug zurückkommen.