Ausführliche Anleitung zu Redis-Persistenzmechanismen

AOF-Persistenz

Redis ist speicherbasiert. Wenn der Redis-Server abstürzt, gehen Daten verloren. Um Datenverluste zu verhindern, bietet Redis zwei Persistenzmechanismen: RDB und AOF. Beginnen wir mit AOF.

AOF (Append Only File) speichert jede Schreiboperation in einer nur-anhängenden Weise am Ende einer AOF-Datei. Standardmäßig ist AOF in Redis deaktiviert. Beim Neustart führt Redis die Befehle in der AOF-Datei erneut aus, um die Daten wiederherzustellen. Dies behebt hauptsächlich das Problem der Echtzeit-Datenpersistenz.

AOF-Protokolle werden erst nach Ausführung eines Befehls geschrieben. Warum wird der Befehl nicht zuerst protokolliert und dann ausgeführt? Dies liegt daran, dass bei Schreibvorgängen in das AOF-Protokoll keine Syntaxprüfungen von Redis durchgeführt werden. Wenn zuerst der Befehl protokolliert und dann ausgeführt wird, besteht das Risiko, dass ungültige Befehle protokolliert werden, was zu Fehlern führen kann, wenn Redis versucht, Daten aus dem AOF-Protokoll wiederherzustellen.

Da die Protokollierung nach der Befehlsausführung erfolgt, blockiert sie die aktuelle Schreiboperation nicht. Es bestehen jedoch zwei Risiken:

Wenn das System nach der Ausführung des Befehls, aber vor dem Schreiben des Protokolls abstürzt, gehen Daten verloren.
AOF blockiert zwar nicht den aktuellen Befehl, kann aber die nächste Operation blockieren.

Die beste Möglichkeit, diese Risiken zu mindern, ist die Verwendung der drei AOF-Schreibstrategien, die von der Einstellung appendfsync bereitgestellt werden:

always: synchroner Writeback. Nach jeder Befehlsausführung wird das Protokoll sofort auf die Festplatte geschrieben.
everysec: Nach jedem Befehl wird das Protokoll in den AOF-Speicherpuffer geschrieben und jede Sekunde mit der Festplatte synchronisiert.
no: Das Protokoll wird nur in den AOF-Speicherpuffer geschrieben, und das Betriebssystem entscheidet, wann es auf die Festplatte geschrieben wird.

Die Strategie always gewährleistet minimalen Datenverlust, hat aber eine geringere Leistung. Die Strategie no bietet eine bessere Leistung, birgt aber das Risiko eines größeren Datenverlusts. Im Allgemeinen ist everysec ein guter Kompromiss.

Wenn im Laufe der Zeit mehr Befehle empfangen werden, wächst die AOF-Datei immer weiter, was zu Leistungsproblemen führen kann. Was passiert, wenn die Protokolldatei zu groß wird? Hier kommt AOF-Rewrite ins Spiel! Im Laufe der Zeit sammelt die AOF-Datei redundante Befehle, z. B. ungültige oder abgelaufene. Der AOF-Rewrite-Mechanismus führt diese zu einem einzigen Befehl zusammen (wie ein Batch-Befehl), um die Dateigröße zu reduzieren und zu komprimieren.

Verursacht das AOF-Rewriting eine Blockierung? Das AOF-Protokoll wird vom Hauptthread geschrieben, aber das Rewriting ist anders – es wird von einem Hintergrund-Subprozess namens bgrewriteaof durchgeführt.

Vorteile von AOF: höhere Datenkonsistenz und -integrität, wobei der Datenverlust auf Sekunden begrenzt ist.
Nachteile: Bei derselben Datenmenge sind die AOF-Dateien größer als die RDB-Dateien. Auch die Wiederherstellung ist langsamer.

RDB-Persistenz

Da die AOF-Persistenz bei vielen Operationsprotokollen zu einer sehr langsamen Wiederherstellung führen kann, gibt es eine schnellere Möglichkeit, nach einem Absturz wiederherzustellen? Ja – RDB!

RDB speichert In-Memory-Daten in Form von Snapshots auf der Festplatte. Im Gegensatz zu AOF, das jede Operation aufzeichnet, speichert RDB den Datenstatus zu einem bestimmten Zeitpunkt.

Was ist ein Snapshot? Man kann sich das wie ein Foto der aktuellen Daten vorstellen, das gespeichert wird.

RDB-Persistenz bedeutet, dass Redis in bestimmten Intervallen und nach einer bestimmten Anzahl von Schreiboperationen einen Snapshot des Datensatzes im Speicher auf die Festplatte schreibt. Dies ist die Standard-Persistenzmethode von Redis. Nach Abschluss des Vorgangs wird eine dump.rdb-Datei im angegebenen Verzeichnis generiert. Wenn Redis neu startet, lädt es die Datei dump.rdb, um die Daten wiederherzustellen. RDB kann auf verschiedene Arten ausgelöst werden:

save: manuell ausgelöst, synchrones Speichern, blockiert den aktuellen Redis-Server.
bgsave: manuell ausgelöst, asynchrones Speichern – der Redis-Prozess forkt einen Kindprozess.
save m n: wird automatisch ausgelöst – wenn der Datensatz innerhalb von m Sekunden n Mal geändert wird, wird automatisch bgsave ausgelöst.

Durch die Ausführung vollständiger Snapshots mit dem Befehl bgsave vermeidet Redis die Blockierung des Hauptthreads. Der Befehl bgsave forkt einen Kindprozess, um die RDB-Datei zu erstellen, während der Serverprozess weiterhin Befehle verarbeitet.

Können Daten während des Snapshots noch geändert werden? Redis verwendet den Copy-On-Write (COW)-Mechanismus des Betriebssystems, sodass es die Schreibvorgänge während der Aufnahme des Snapshots weiter verarbeiten kann.

Obwohl bgsave den Hauptthread nicht blockiert, verursachen häufige vollständige Snapshots immer noch Leistungseinbußen. Beispielsweise ist das Erstellen eines Kindprozesses über fork erforderlich, was den Hauptthread während der Erstellung blockiert. In diesem Fall könnten inkrementelle Snapshots ein besserer Ansatz sein.

Vorteile von RDB: Im Vergleich zu AOF ermöglicht es eine schnellere Wiederherstellung großer Datensätze und eignet sich für groß angelegte Datenwiederherstellungsszenarien wie z. B. Backups und vollständige Replikation.
Nachteile: Es kann keine Echtzeit- oder Second-Level-Persistenz erreicht werden.

Ab Redis 4.0 wird die hybride Persistenz von RDB und AOF unterstützt – in regelmäßigen Abständen werden Speicher-Snapshots erstellt, und zwischen den Snapshots werden alle Befehlsvorgänge mit AOF aufgezeichnet.

Wie man zwischen RDB und AOF wählt

Wenn Datenverluste inakzeptabel sind, verwenden Sie eine Kombination aus RDB und AOF.
Wenn Redis nur als Cache verwendet wird und ein paar Minuten Datenverlust toleriert werden können, reicht die Verwendung von nur RDB aus.
Wenn Sie sich für die ausschließliche Verwendung von AOF entscheiden, wird die Verwendung der Writeback-Strategie everysec empfohlen.