Vergleich der Leistungskompromisse von AOF vs. RDB Persistenz

Redis-Persistenz ist ein Kompromiss zwischen der Menge an Daten, die Sie sich leisten können zu verlieren, und der Menge an Festplattenarbeit, die Ihr Server verkraften kann. Wenn jedoch die Persistenz aktiviert ist – um Daten für die Wiederherstellung nach einem Neustart auf der Festplatte zu speichern – müssen Entwickler einen Mechanismus wählen. Die beiden primären Persistenzmethoden in Redis sind Snapshotting (RDB) und die Append-Only File (AOF). Das Verständnis der Leistungsauswirkungen, Haltbarkeitseigenschaften und Konfigurationskompromisse jeder Methode ist entscheidend, um Redis für spezifische Anwendungsanforderungen hinsichtlich Geschwindigkeit versus Datensicherheit abzustimmen.

RDB-Snapshots sind kompakt und schnell zu laden. AOF protokolliert Schreibvorgänge häufiger und bietet in der Regel bessere Wiederherstellungspunkte, kostet jedoch mehr Festplatten-I/O.

Redis-Persistenz verstehen

Redis speichert seinen gesamten Datensatz im flüchtigen Arbeitsspeicher. Persistenzmechanismen sind notwendig, um diese Daten auf die Festplatte zu verschieben, damit Redis den Datensatz nach einem Neustart neu laden kann, um die Datenverfügbarkeit bei Dienstunterbrechungen oder Neustarts sicherzustellen. Sowohl RDB als auch AOF erreichen dieses Ziel durch grundlegend unterschiedliche Ansätze, die zu unterschiedlichen Leistungsprofilen führen.

1. Redis Database (RDB) Snapshotting

RDB erstellt einen kompakten, zeitpunktbezogenen Snapshot des gesamten Datensatzes in bestimmten Intervallen. Es speichert diese Daten in einer Binärdatei (dump.rdb).

Wie RDB funktioniert und seine Leistungsauswirkungen

RDB-Persistenz stützt sich stark auf den Befehl BGSAVE (Background Save). Wenn ein Speichern ausgelöst wird:

Forking: Redis forkt den Hauptprozess in einen Kindprozess.
Snapshotting: Der Kindprozess schreibt den gesamten Datensatz in die RDB-Datei auf der Festplatte.
Hauptthread unbeeinflusst (meistens): Der Haupt-Redis-Thread bedient weiterhin Client-Anfragen, ohne während des Schreibvorgangs blockiert zu werden, da der Kindprozess die Festplatten-I/O übernimmt.

Leistungsaspekte:

Schreiblatenz: Im Allgemeinen hat RDB während des Speichervorgangs minimale Auswirkungen auf die Schreiblatenz, da die Arbeit ausgelagert wird. Die primären Leistungskosten sind der CPU-Anstieg und der anfängliche I/O-Burst, der beim Fork und während des Schreibens der großen Datei auftritt.
Wiederherstellungszeit: RDB lädt beim Neustart sehr schnell, da es sich um eine einzelne, optimierte Datei handelt, was die Wiederherstellungslatenz minimiert.
Haltbarkeitskompromiss: Wenn Redis zwischen geplanten Speicherungen (z. B. alle 5 Minuten) abstürzt, gehen alle seit der letzten Speicherung erfolgten Schreibvorgänge verloren. Dies macht RDB weniger haltbar als AOF.

Konfigurieren von RDB-Speicherungen

RDB-Speicherungen werden mit der Direktive save in der Datei redis.conf konfiguriert, die Zeitintervalle und die Anzahl der Änderungen angibt:

save 900 1     # Speichern, wenn 1 Schlüssel in 900 Sekunden (15 Minuten) geändert wurde
save 300 10    # Speichern, wenn 10 Schlüssel in 300 Sekunden (5 Minuten) geändert wurden
save 60 10000  # Speichern, wenn 10000 Schlüssel in 60 Sekunden (1 Minute) geändert wurden

2. Append-Only File (AOF) Persistenz

AOF zeichnet jeden vom Redis-Server empfangenen Schreibvorgang in einer Append-Only-Logdatei auf. Wenn Redis neu startet, führt es diese Befehle nacheinander aus, um den Datensatz zu rekonstruieren.

Wie AOF funktioniert und seine Leistungsauswirkungen

Im Gegensatz zu RDB konzentriert sich AOF auf transaktionale Protokollierung. Das Leistungsprofil hängt stark von der fsync-Richtlinie ab, die festlegt, wie oft Redis das Betriebssystem zwingt, gepufferte Daten auf die physische Festplatte zu schreiben.

AOF Fsync-Richtlinien:

Richtlinie	`appendfsync`-Einstellung	Haltbarkeit	Leistungsauswirkung
Jede Sekunde	`everysec`	Gut im Normalbetrieb; ein Absturz kann etwa eine Sekunde bestätigter Schreibvorgänge verlieren	Gute Balance; häufige Produktionswahl.
Keine Synchronisation	`no`	Schlecht (verlässt sich auf den OS-Puffer)	Am schnellsten; maximales Risiko von Datenverlust bei OS-Absturz.
Immer	`always`	Stärkste AOF-Haltbarkeitsrichtlinie	Langsamste; signifikanter Latenzanstieg aufgrund von Festplattensynchronisation bei jedem Schreibvorgang.

Leistungsaspekte:

Schreiblatenz: Bei Verwendung von appendfsync always verursacht jeder Schreibbefehl die Latenz einer Festplattensynchronisation, was Operationen im Vergleich zu RDB oder In-Memory-Operationen erheblich verlangsamt. Die Verwendung von everysec mildert dies erheblich, indem fsyncs gebündelt werden.
Wiederherstellungszeit: AOF-Dateien können groß werden, und die Wiederholung von Millionen von Befehlen kann länger dauern als das Laden einer kompakten RDB-Datei, was zu einer höheren Wiederherstellungslatenz führt.
Dateigröße: AOF-Dateien sind typischerweise viel größer als RDB-Dateien, da sie Befehle (z. B. SET key value) speichern und nicht den endgültigen Zustand der Datenstruktur.

Aktivieren und Konfigurieren von AOF

AOF ist standardmäßig deaktiviert und wird durch Setzen von appendonly yes in redis.conf aktiviert. Die entscheidende Einstellung ist appendfsync:

appendonly yes
appendfilename "appendonly.aof"
# Empfohlene Einstellung für den Kompromiss zwischen Haltbarkeit und Geschwindigkeit
appendfsync everysec

Analyse der Leistungskompromisse: AOF vs. RDB

Die Wahl zwischen RDB und AOF erfordert die Priorisierung entweder der rohen Betriebsgeschwindigkeit (Latenz) oder der garantierten Datenwiederherstellung.

Latenz und Durchsatz

RDB (Am besten für rohe Geschwindigkeit): Da Schreibvorgänge von einem Hintergrundprozess bearbeitet werden, sieht der Haupt-Redis-Thread während der Speicherungen minimale direkte I/O-Auswirkungen. Dies führt im Allgemeinen zu einer geringeren Gesamtschreiblatenz, es sei denn, das System ist stark ausgelastet, wenn der BGSAVE-Fork auftritt.
AOF (always-Modus): Diese Konfiguration ist die langsamste, da die Festplattenlatenz direkt in jeden Client-Schreibbefehl eingeführt wird, was zu höheren p99-Latenzen führt.
AOF (everysec-Modus): Dies bietet für die meisten Operationen eine nahezu RDB-ähnliche Leistung, da fsync-Operationen gepuffert und weniger häufig sind.

Haltbarkeit und Datenverlustrisiko

AOF (Am besten für Haltbarkeit): Bietet die höchste Haltbarkeit, insbesondere mit appendfsync always. Selbst mit everysec ist der Datenverlust auf eine Sekunde begrenzt.
RDB (Am schlechtesten für Haltbarkeit): Datenverlust kann Minuten oder Stunden umfassen, abhängig vom Speicherplan.

Wiederherstellungszeit

RDB (Schnelle Wiederherstellung): Schnellere Neustartzeiten aufgrund des optimierten, kompakten Binärformats.
AOF (Langsamere Wiederherstellung): Die Wiederholung eines großen Befehlsprotokolls kann länger dauern als das Laden eines Snapshots, was die Ausfallzeit während Neustarts erhöht.

Best Practice: Verwendung beider Persistenzmethoden

Für Umgebungen, die sowohl hohe Leistung als auch starke Haltbarkeitsgarantien erfordern, ist der empfohlene Ansatz, sowohl RDB- als auch AOF-Persistenz gleichzeitig zu aktivieren.

Wenn beide aktiviert sind, verwendet Redis die AOF-Datei für die Wiedergabe beim Start, um maximale Datenkonsistenz zu erreichen. Es erzeugt weiterhin periodisch RDB-Snapshots.

Warum beide verwenden?

Bessere Wiederherstellungsoptionen: Redis lädt normalerweise zuerst AOF, wenn beide aktiviert sind, da es in der Regel vollständiger ist. Die Beibehaltung von RDB bietet ein zusätzliches Fallback-Artefakt für Backups und Notfallwiederherstellung.
Betriebliche Flexibilität: RDB ist kompakt und leicht zu archivieren, während AOF das Datenverlustfenster verkleinert. Zusammen decken sie verschiedene Fehlermodi ab.

Konfigurationsausschnitt für beide:

# 1. RDB aktivieren
save 900 1

# 2. AOF mit 'everysec'-Synchronisation aktivieren
appendonly yes
appendfsync everysec

Verwalten der AOF-Dateigröße (Rewriting)

Ein bedeutendes betriebliches Problem bei AOF ist das Wachstum der Dateigröße. Im Laufe der Zeit kann die AOF-Datei massiv werden, da sie jede Änderung protokolliert, selbst solche, die vorherige Werte überschreiben. Um dem entgegenzuwirken, bietet Redis AOF-Rewriting an.

AOF-Rewriting erzeugt eine neue, optimierte AOF-Datei, die nur den minimalen Satz von Befehlen enthält, die zur Rekonstruktion des aktuellen Zustands des Datensatzes erforderlich sind. Dieser Prozess wird automatisch ausgelöst, wenn die Größe der aktuellen AOF-Datei über ein bestimmtes Vielfaches der Basisgröße hinauswächst.

auto-aof-rewrite-percentage 100  # Neu schreiben, wenn die AOF-Datei 100% größer als die Basisgröße ist
auto-aof-rewrite-min-size 64mb    # Nicht neu schreiben, es sei denn, die Datei ist mindestens 64 MB groß

Warnung zum Rewriting: Wie beim RDB-Speichern beinhaltet das AOF-Rewriting das Forken des Prozesses. Wenn Ihr System speicherbegrenzt ist, kann diese vorübergehende Verdoppelung der Speichernutzung (die Live-Instanz plus die Kopie, die neu geschrieben wird) zu Instabilität oder Swapping führen.

Fazit

Verwenden Sie RDB, wenn schnelle Neustarts, kompakte Backups und geringer Schreibaufwand wichtiger sind als der Verlust kürzlicher Schreibvorgänge. Verwenden Sie AOF mit appendfsync everysec, wenn Sie ein engeres Wiederherstellungsfenster benötigen, ohne jeden Schreibvorgang zu synchronisieren. Für viele Produktionssysteme bietet die Aktivierung beider eine praktische Mischung aus Haltbarkeit, Backup-Komfort und Wiederherstellungsoptionen.