Bewährte Methoden zur Vermeidung von Datenverlust: RDB- vs. AOF-Konfiguration

Redis-Persistenz ist leicht misszuverstehen, da Redis sich wie eine Datenbank anfühlt, sich aber zuerst wie ein Arbeitsspeicher verhält. Wenn Sie es ohne Persistenz neu starten, sind die Daten verloren. Wenn die Persistenz aktiviert, aber nachlässig eingestellt ist, können Sie trotzdem kürzliche Schreibvorgänge verlieren, Clients während der Festplattenbelastung blockieren oder bei einem Ausfall feststellen, dass die einzige Kopie Ihrer Daten auf demselben ausgefallenen Volume wie der Redis-Prozess lebt.

Die richtige Redis-Strategie gegen Datenverlust beginnt mit einer ehrlichen Frage: Was passiert, wenn die letzten Sekunden, Minuten oder Stunden an Schreibvorgängen verschwinden? Ein Cache von Produktseiten kann normalerweise neu aufgebaut werden. Ein Session-Store mag Benutzer verärgern, aber nicht das Geschäft zerstören. Eine Warteschlange, ein Rate-Limit-Ledger, ein Warenkorb-Speicher oder ein Feature-Flag-Speicher benötigen möglicherweise eine viel strengere Beständigkeit. RDB und AOF sind die beiden Werkzeuge, die Redis Ihnen gibt, und sie lösen verschiedene Teile dieses Problems.

Verständnis der Redis-Persistenzmechanismen

Redis hat zwei Hauptpersistenzmodi:

RDB-Snapshots

RDB schreibt einen Point-in-Time-Snapshot des Datensatzes auf die Festplatte, normalerweise als dump.rdb. Redis forkt einen Kindprozess, das Kind serialisiert den Datensatz, und der Elternteil bedient weiterhin Clients. Das macht RDB nützlich für Backups, Replikate und schnelle Neustarts, hat aber einen klaren Kompromiss: Alles, was nach dem letzten erfolgreichen Snapshot geschrieben wurde, kann verloren gehen, wenn der Prozess oder Host ausfällt.

Typische RDB-Einstellungen sehen so aus:

save 900 1       # Speichern nach 15 Minuten, wenn mindestens 1 Schlüssel geändert wurde
save 300 10      # Speichern nach 5 Minuten, wenn mindestens 10 Schlüssel geändert wurden
save 60 10000    # Speichern nach 1 Minute, wenn mindestens 10000 Schlüssel geändert wurden
dbfilename dump.rdb
dir /var/lib/redis

Diese save-Zeilen sind kein Versprechen, dass Redis genau nach diesem Zeitplan speichert. Sie sind Auslöserregeln: Wenn während des Intervalls genügend Schlüssel geändert wurden, startet Redis einen Hintergrundspeichervorgang. Wenn die Festplatte langsam ist, der Datensatz riesig ist oder der Host wenig Arbeitsspeicher hat, kann der Hintergrundspeichervorgang fehlschlagen oder durch Fork- und Copy-on-Write-Druck Latenz verursachen.

RDB ist am stärksten, wenn Sie kompakte Snapshots und schnelles Wiederherstellungsverhalten wünschen. Es ist am schwächsten, wenn Ihre Toleranz für kürzlichen Datenverlust gering ist.

AOF-Protokollierung

AOF (Append-Only File) Persistenz zeichnet Schreibbefehle auf, damit Redis sie beim Neustart wiedergeben kann. Es bietet normalerweise eine bessere Beständigkeit als RDB, da es Schreibvorgänge häufiger leeren kann als ein Snapshot-Zeitplan. Der Kompromiss ist mehr Festplatten-I/O, größere Dateien vor dem Rewrite und manchmal langsamere Startzeiten, wenn Redis ein großes Protokoll wiedergeben muss.

Die Kerneinstellungen sind:

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
aof-auto-rewrite-percentage 100
aof-auto-rewrite-min-size 64mb
aof-rewrite-incremental-fsync yes

Die wichtige Zeile ist appendfsync. Mit everysec bittet Redis das Betriebssystem, die AOF etwa einmal pro Sekunde zu leeren. Bei einem normalen Redis-Prozessabsturz begrenzt das den Verlust normalerweise auf etwa die letzte Sekunde der Schreibvorgänge. Bei einem vollständigen Host-Absturz oder Speicherfehler hängt der genaue Verlust vom Betriebssystem, Dateisystem, Festplattencache und Speicherverhalten ab, also beschreiben Sie es nicht als mathematische Garantie.

appendfsync always leert nach jedem Schreibvorgang und ist viel teurer. Es kann für eine kleine, kritische Redis-Bereitstellung mit bescheidenem Schreibvolumen geeignet sein, kann aber unter echtem Datenverkehr die Latenz stark beeinträchtigen. appendfsync no überlässt dem Betriebssystem die Entscheidung, wann es leert; es ist schnell, gibt Ihnen aber ein viel breiteres und weniger vorhersagbares Verlustfenster.

Bewährte Methoden zur Vermeidung von Datenverlust

Verwenden Sie beide nur, wenn Sie verstehen, welche Datei Redis lädt

Viele Produktions-Redis-Bereitstellungen aktivieren sowohl RDB als auch AOF. Das ist eine sinnvolle Standardeinstellung, wenn Redis Daten speichert, deren Wiederaufbau mühsam wäre. RDB gibt Ihnen kompakte Backup-Artefakte. AOF gibt Ihnen ein kleineres Fenster für kürzliche Verluste.

Verwenden Sie eine Konfiguration wie diese:

save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec

Ein Detail ist bei der Wiederherstellung wichtig: Wenn AOF aktiviert ist, lädt Redis normalerweise die AOF-Daten beim Start, da erwartet wird, dass sie vollständiger sind als der RDB-Snapshot. Gehen Sie nicht davon aus, dass Redis zuerst RDB lädt und auf AOF zurückfällt. Testen Sie den Wiederherstellungspfad für Ihre Redis-Version und Ihr Bereitstellungslayout, insbesondere bei Redis-Versionen, die das neuere Multi-Part-AOF-Format verwenden.

Wählen Sie appendfsync rückwärts vom Verlustfenster aus

Beginnen Sie mit den geschäftlichen Auswirkungen, nicht mit der Redis-Einstellung.

Wenn Redis ein Wegwerf-Cache ist, kann RDB allein ausreichen, oder sogar gar keine Persistenz, wenn Ihre Anwendung sicher neu befüllt. Wenn Redis Sitzungen enthält, ist appendfsync everysec oft ein praktischer Kompromiss. Wenn Redis Teil eines Workflows ist, bei dem der Verlust bestätigter Schreibvorgänge echten geschäftlichen Schaden verursacht, ist die Redis-Persistenz allein möglicherweise nicht die richtige Beständigkeitsgrenze. Sie benötigen möglicherweise eine primäre Datenbank, eine dauerhafte Warteschlange oder ein anwendungsebenenbasiertes Write-Ahead-Verhalten außerhalb von Redis.

Für die meisten operativen Redis-Verwendungen beginnen Sie mit:

appendonly yes
appendfsync everysec

Beobachten Sie dann Latenz, Festplattenschreibzeit, AOF-Rewrite-Verhalten und Neustartzeit, bevor Sie entscheiden, ob Sie sich in Richtung always oder von AOF wegbewegen.

Behalten Sie RDB-Snapshots, aber machen Sie sie nicht zu aggressiv

Häufige RDB-Speichervorgänge reduzieren die Datenmenge, die zwischen Snapshots verloren geht, aber sie erhöhen auch die Fork-Häufigkeit. Das Forken eines großen Redis-Prozesses kann teuer sein, und Schreibvorgänge während des Kind-Speichervorgangs erzeugen Copy-on-Write-Speicherdruck. Wenn Ihre Redis-Instanz einen 40 GB großen Datensatz hat und die Schreibrate hoch ist, kann das Speichern jede Minute die Zuverlässigkeit verschlechtern, weil der Host zu viel Zeit unter Speicher- und Festplattendruck verbringt.

Angemessene RDB-Speicherregeln hängen von der Schreibrate und den Wiederherstellungserwartungen ab. Ein kleiner Cache kann oft ohne Probleme Snapshots erstellen. Ein großer Session-Store benötigt möglicherweise weniger RDB-Snapshots plus AOF für aktuelle Beständigkeit. Beobachten Sie INFO persistence, Redis-Protokolle und Host-Speicher während BGSAVE, nicht nur die Redis-Konfigurationsdatei.

Behandeln Sie AOF-Rewrite als normale Wartung, nicht als Notfall

AOF-Dateien wachsen, weil sie Schreibvorgänge aufzeichnen. Redis schreibt sie im Hintergrund in eine kompakte Darstellung um. Die Standardeinstellungen sind oft ein anständiger Ausgangspunkt:

aof-auto-rewrite-percentage 100
aof-auto-rewrite-min-size 64mb

Das bedeutet, dass Redis ein Rewrite in Betracht zieht, wenn die AOF im Vergleich zur Größe nach dem vorherigen Rewrite erheblich gewachsen ist, sobald sie mindestens die Mindestgröße erreicht hat. Wenn Rewrites ständig stattfinden, erhöhen Sie die Mindestgröße oder untersuchen Sie ein lautes Schreibmuster. Wenn die AOF lange Zeit ohne Rewrite wächst, überprüfen Sie Protokolle, Festplattenspeicher und INFO persistence.

Sie können ein Rewrite manuell auslösen:

redis-cli BGREWRITEAOF

Tun Sie das wenn möglich während einer ruhigen Periode. Ein Rewrite ist sicherer, als die Datei ewig wachsen zu lassen, verbraucht aber dennoch CPU, Festplattenbandbreite und Copy-on-Write-Speicher.

Sichern Sie die Persistenzdateien an einem anderen Ort

Persistenz ist kein Backup. Persistenzdateien auf demselben Host schützen Sie vor einem Neustart des Redis-Prozesses. Sie schützen Sie nicht vor einer verlorenen Festplatte, versehentlichem Löschen, einer fehlerhaften Bereitstellung, die das Datenverzeichnis überschreibt, oder einem Bedienerfehler, der FLUSHALL ausführt.

Kopieren Sie RDB- und AOF-Dateien auf separaten Speicher. Wenn Sie Dateisystem-Snapshots oder Cloud-Volume-Snapshots verwenden, testen Sie die Wiederherstellung auf einer separaten Instanz. Für RDB-Kopien bevorzugen Sie das Kopieren einer abgeschlossenen Snapshot-Datei anstelle einer Datei, die gerade geschrieben wird. Für AOF verstehen Sie das Dateilayout für Ihre Redis-Version, bevor Sie Backup-Skripte um Dateinamen herum erstellen.

Beobachten Sie die Signale, die Datenverlust vorhersagen

Der nützliche Befehl während eines Vorfalls ist:

redis-cli INFO persistence

Achten Sie auf fehlgeschlagene Hintergrundspeichervorgänge, AOF-Rewrite-Status, letzte Speicherzeit und verzögerte Fsync-Indikatoren. Kombinieren Sie das mit Host-Metriken: Festplattenlatenz, freier Festplattenspeicher, Speicherreserven und Kernel-OOM-Ereignisse. Wenn BGSAVE stundenlang fehlschlägt und niemand es bemerkt, kann die Redis-Konfiguration sicher aussehen, während der tatsächliche Wiederherstellungspunkt immer älter wird.

Verwenden Sie Replikation oder Sentinel für Verfügbarkeit, nicht als Ihr einziges Backup

Replikate, Redis Sentinel und Redis Cluster helfen bei der Verfügbarkeit. Sie lösen nicht automatisch jedes Datenverlustproblem. Ein schlechter Schreibvorgang, versehentliches Löschen oder ein Anwendungsfehler können sich schnell replizieren. Ein Failover kann auch ein Replikat befördern, dem bei Replikationsverzögerung kürzliche Schreibvorgänge fehlen. Behalten Sie Persistenz, Backups und Wiederherstellungstests im Design.

Der praktische Aufbau für viele Teams ist AOF mit appendfsync everysec, RDB-Snapshots in einem angemessenen Rhythmus, externe Backups, Überwachung auf Persistenzfehler und ein getestetes Wiederherstellungs-Runbook. Redis kann in dieser Form zuverlässig sein, aber nur, wenn Sie Persistenz als operatives System behandeln und nicht als anzukreuzendes Kästchen.