Redis-Persistenzoptionen: RDB vs. AOF erklärt

Redis ist bekannt für seine Geschwindigkeit als In-Memory-Datenspeicher, der häufig als Cache oder Message Broker verwendet wird. Da Daten jedoch hauptsächlich im RAM gespeichert werden, um Geschwindigkeit zu gewährleisten, erfordern Produktionsbereitstellungen Mechanismen, um sicherzustellen, dass Daten Neustarts oder Abstürze überstehen. Hier kommt die Persistenz ins Spiel. Redis bietet zwei primäre integrierte Persistenzmechanismen: Redis Database Backup (RDB) und Append-Only File (AOF). Das Verständnis der Kompromisse zwischen diesen beiden ist entscheidend für die entsprechende Konfiguration von Redis für die Haltbarkeits- und Leistungsanforderungen Ihrer Anwendung.

Diese Anleitung erklärt ausführlich, wie RDB und AOF funktionieren, vergleicht ihre Vor- und Nachteile und gibt Anleitungen, wann jede Strategie eingesetzt werden sollte.

Redis-Persistenz verstehen

Persistenz in Redis bezieht sich auf den Prozess, den aktuellen Zustand des In-Memory-Datensatzes auf die Festplatte zu schreiben. Dies ermöglicht es Redis, die Daten beim Neustart des Servers neu zu laden. Ohne aktivierte Persistenz gehen beim Herunterfahren alle Daten verloren.

Redis unterstützt sowohl RDB als auch AOF gleichzeitig und bietet einen hybriden Ansatz, der die besten Funktionen beider kombiniert.

1. Redis Database Backup (RDB)

RDB (Redis Database Backup) ist der Standard-Persistenzmechanismus von Redis. Er führt periodisch Schnappschüsse Ihres gesamten Datensatzes in festgelegten Intervallen durch.

Wie RDB funktioniert

RDB arbeitet, indem der Haupt-Redis-Prozess geforkt wird, wodurch ein Kindprozess erstellt wird, der den aktuellen Speicherinhalt in eine komprimierte Binärdatei namens dump.rdb auf die Festplatte schreibt. Da dies ein Schnappschuss ist, erfasst er die Daten zu einem bestimmten Zeitpunkt.

Konfiguration und Snapshotting

RDB-Konfiguration wird über die save-Direktiven in der Datei redis.conf verwaltet. Diese Direktiven definieren die Bedingungen, unter denen eine automatische Speicherung erfolgt:

# Speichere die DB, wenn 1000 Schlüssel in 1 Minute geändert wurden
save 600 1000
# Speichere die DB, wenn 10 Schlüssel in 10 Minuten geändert wurden
save 300 10
# Speichere die DB, wenn 10000 Schlüssel in 1 Sekunde geändert wurden
save 1 10000

Um die RDB-Persistenz vollständig zu deaktivieren, können Sie alle save-Direktiven auskommentieren oder den Befehl SAVE nur manuell verwenden.

Vorteile von RDB

Kompakte Dateien: RDB-Dateien sind hoch optimiert, komprimiert und kompakt, was sie ideal für Backups und schnelle Übertragungen macht.
Schnelle Wiederherstellung: Da es sich um eine einzige Schnappschussdatei handelt, ist das Laden von Daten während des Neustarts sehr schnell.
Leistung: Speichervorgänge erfolgen asynchron durch Forking des Prozesses, was bedeutet, dass der Hauptthread während des Schreibvorgangs nicht blockiert wird (obwohl der Fork selbst geringfügige Latenzspitzen verursachen kann).

Nachteile von RDB

Datenverlustrisiko: Wenn Redis zwischen geplanten Speicherpunkten abstürzt, gehen alle Schreibvorgänge verloren, die nach dem letzten Schnappschuss aufgetreten sind.
Forking-Overhead: Bei sehr großen Datensätzen kann der Forking-Vorgang, der zur Erstellung des Schnappschusses erforderlich ist, erhebliche Systemressourcen verbrauchen und zu kurzen Latenzen führen.

2. Append-Only File (AOF)

AOF (Append-Only File) bietet ein höheres Maß an Datenhaltbarkeit. Anstatt Schnappschüsse zu erstellen, protokolliert AOF jede vom Server empfangene Schreiboperation im Append-Only-Format.

Wie AOF funktioniert

Wenn die Persistenz aktiviert ist, leitet Redis jeden Schreibbefehl (z. B. SET, LPUSH) an eine AOF-Datei auf der Festplatte um. Wenn Redis neu startet, spielt es diese Befehle sequenziell ab, um den Datensatz genau so wiederherzustellen, wie er vor dem Herunterfahren war.

AOF-Konfiguration

Die AOF-Persistenz ist standardmäßig deaktiviert und muss in redis.conf explizit aktiviert werden:

appendonly yes

Entscheidend ist, dass AOF die Konfiguration der fsync-Richtlinie ermöglicht, die bestimmt, wie häufig Schreibvorgänge auf die Festplatte erzwungen werden:

fsync-Richtlinie	Beschreibung	Haltbarkeit vs. Leistung
`no`	Das Betriebssystem übernimmt die Synchronisierung (am seltensten).	Schnellste, höchstes Verlustrisiko.
`everysec`	Synchronisierung einmal pro Sekunde (Standard und empfohlen).	Gute Balance. Maximal 1 Sekunde Datenverlust.
`always`	Synchronisierung nach jedem Befehl.	Höchste Haltbarkeit, möglicherweise erhebliche Leistungseinbußen.

Vorteile von AOF

Hohe Haltbarkeit: Durch Setzen von fsync auf always können Sie nahezu keinen Datenverlust erzielen.
Protokollwiedergabe: Die AOF-Datei enthält ein chronologisches Protokoll von Operationen, wodurch die Fehlerbehebung bei potenzieller Datenbeschädigung erleichtert wird.

Nachteile von AOF

Größere Dateien: AOF-Dateien sind typischerweise viel größer als entsprechende RDB-Dateien, da sie Befehle und nicht den endgültigen Datenstatus speichern.
Langsamerer Neustart: Das Abspielen potenziell Tausender von Befehlen während des Starts dauert länger als das Laden eines einzelnen RDB-Schnappschusses.
Schreibverstärkung: Befehle werden einzeln protokolliert, was im Vergleich zum RDB-Snapshotting zu einem etwas höheren Schreibaufwand führen kann.

AOF-Neuschreibung

Um das Wachstum der Dateigröße zu bekämpfen, implementiert Redis die AOF-Neuschreibung. Dieser Prozess erstellt asynchron eine neue, optimierte AOF-Datei, die nur die Befehle enthält, die zur Erreichung des aktuellen Zustands erforderlich sind, und verwirft effektiv redundante oder veraltete Befehle (wie mehrere Aktualisierungen desselben Schlüssels).

RDB vs. AOF: Direkter Vergleich

Die Wahl zwischen RDB, AOF oder beidem hängt vollständig von den Anforderungen Ihrer Anwendung an die Wiederherstellungszeit und die Toleranz für Datenverlust ab.

Merkmal	RDB (Snapshotting)	AOF (Append-Only File)
Haltbarkeit/Datenverlust	Höherer potenzieller Datenverlust (seit letzter Speicherung).	Minimaler Datenverlust (bis zu 1 Sekunde oder null mit `fsync=always`).
Dateigröße	Sehr kompakt und optimiert.	Größer aufgrund der Protokollierung von Befehlen.
Neustartzeit	Sehr schnelles Laden des Schnappschusses.	Langsamer, erfordert Wiedergabe von Befehlen.
Komplexität	Einfach, konfiguriert nach Zeitintervallen.	Erfordert sorgfältige Konfiguration der `fsync`-Richtlinie.
Anwendungsfall	Backups, Notfallwiederherstellung, bei der jüngste Datenverluste tolerierbar sind.	Primärer Persistenzmechanismus, der hohe Haltbarkeit erfordert.

Best Practice: Kombination von RDB und AOF

Für die meisten modernen Produktionsbereitstellungen wird empfohlen, sowohl RDB- als auch AOF-Persistenz gleichzeitig zu aktivieren.

Wenn beide aktiviert sind:
1. AOF stellt das primäre, hochgradig haltbare Protokoll bereit.
2. RDB stellt einen schnellen, kompakten Backup-Schnappschuss bereit.

Beim Neustart wird Redis bevorzugt die AOF-Datei laden, um die volle Haltbarkeit zu gewährleisten. Wenn die AOF-Datei fehlt oder beschädigt ist, greift Redis auf das Laden der RDB-Datei zurück. Darüber hinaus verwendet der AOF-Neuschreibungsprozess oft die RDB-Datei als effizienten Ausgangspunkt und vereint so die Vorteile beider Methoden.

Aktivierung beider Methoden

Stellen Sie sicher, dass beide Konfigurationen in redis.conf gesetzt sind:

# AOF aktivieren
appendonly yes

# RDB-Konfiguration beibehalten (z. B. automatische Speicherung stündlich)
save 3600 1

# Empfohlene fsync-Richtlinie für AOF
appendfsync everysec

Tipp zur AOF-Neuschreibung: Sie können eine AOF-Neuschreibung jederzeit manuell auslösen, indem Sie den Befehl BGREWRITEAOF verwenden. Dies ist besonders nützlich nach großen Stapeldatenladungen oder erheblichen Bereinigungsoperationen, um die Größe der AOF-Datei sofort zu verringern.