Vergleich der Leistungsabwägungen zwischen AOF- und RDB-Persistenz

Redis ist bekannt für seine rasante Geschwindigkeit und erreicht oft Latenzen im Sub-Millisekundenbereich. Wenn jedoch Persistenz aktiviert ist – was das Speichern von Daten auf der Festplatte zur Wiederherstellung nach einem Neustart ermöglicht –, 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, der Haltbarkeitsmerkmale und der Konfigurationsabwägungen jeder Methode ist entscheidend für die Optimierung von Redis, um die spezifischen Anforderungen der Anwendung an Geschwindigkeit im Vergleich zur Datensicherheit zu erfüllen.

Diese Anleitung untersucht RDB und AOF eingehend, beschreibt, wie sie funktionieren, ihre jeweiligen Leistungseindrücke auf die Latenz und bietet praktische Einblicke für die Auswahl der richtigen Persistenzstrategie für Ihre Hochleistungs-Redis-Bereitstellungen.

Verständnis der Redis-Persistenz

Redis speichert seinen gesamten Datensatz im flüchtigen Speicher. Persistenzmechanismen sind erforderlich, um diese Daten auf die Festplatte zu verschieben, damit Redis den Datensatz beim Neustart neu laden kann, wodurch die Datenverfügbarkeit bei Dienstunterbrechungen oder Neustarts gewährleistet wird. 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 in festgelegten Intervallen einen kompakten Schnappschuss des gesamten Datensatzes zu einem bestimmten Zeitpunkt. Diese Daten werden in einer Binärdatei (dump.rdb) gespeichert.

Wie RDB funktioniert und seine Leistungsauswirkungen

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

Forking: Redis verzweigt den Hauptprozess in einen untergeordneten Prozess.
Snapshotting: Der untergeordnete Prozess schreibt den gesamten Datensatz in die RDB-Datei auf die Festplatte.
Hauptthread (meistens) unberührt: Der Haupt-Redis-Thread bedient weiterhin Client-Anfragen, ohne während des Schreibvorgangs blockiert zu werden, da die Festplatten-E/A vom untergeordneten Prozess übernommen wird.

Leistungsüberlegungen:

Schreibleistung (Latenz): Im Allgemeinen hat RDB während des Speichervorgangs minimale Auswirkungen auf die Schreibleistung, da die Arbeit ausgelagert wird. Die primären Leistungskosten sind der CPU-Spike und der anfängliche E/A-Burst, die beim Forken und während des Schreibens großer Dateien auftreten.
Wiederherstellungszeit: RDB wird beim Neustart sehr schnell geladen, da es sich um eine einzige, optimierte Datei handelt, was die Wiederherstellungslatenz minimiert.
Haltbarkeitsabwägung: Wenn Redis zwischen geplanten Speichervorgängen abstürzt (z. B. alle 5 Minuten), gehen alle seit dem letzten Speichervorgang erfolgten Schreibvorgänge verloren. Dies macht RDB weniger haltbar als AOF.

Konfigurieren von RDB-Speichervorgängen

RDB-Speichervorgänge werden in der Datei redis.conf mit der Direktive save konfiguriert, wobei Zeitintervalle und die Anzahl der Änderungen angegeben werden:

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 Schreibvorgang, den der Redis-Server empfängt, in einer nur angehängten Protokolldatei auf. Wenn Redis neu startet, spielt es diese Befehle sequenziell ab, um den Datensatz zu rekonstruieren.

Wie AOF funktioniert und seine Leistungsauswirkungen

Im Gegensatz zu RDB konzentriert sich AOF auf die Transaktionsprotokollierung. 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 (verliert ca. 1 Sekunde an Daten)	Gute Balance; geringer Mehraufwand. Empfohlener Standard.
Kein Sync	`no`	Schlecht (verlässt sich auf OS-Puffer)	Am schnellsten; maximales Risiko von Datenverlust bei OS-Absturz.
Immer	`always`	Ausgezeichnet (atomarer Schreibvorgang)	Am langsamsten; erhebliche Latenzerhöhung aufgrund des obligatorischen Festplatten-E/A bei jedem Schreibvorgang.

Leistungsüberlegungen:

Schreibleistung (Latenz): Bei Verwendung von appendfsync always verursacht jeder Schreibbefehl die Latenz eines Festplattensyncs, was die Vorgänge im Vergleich zu RDB oder In-Memory-Vorgängen erheblich verlangsamt. Die Verwendung von everysec mildert dies erheblich ab, indem fsyncs gebündelt werden.
Wiederherstellungszeit: AOF-Dateien können groß werden, und das Wiederabspielen 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 in der Regel viel größer als RDB-Dateien, da sie Befehle (z. B. SET key value) und nicht den endgültigen Zustand der Datenstruktur speichern.

AOF aktivieren und konfigurieren

AOF ist standardmäßig deaktiviert und wird aktiviert, indem appendonly yes in redis.conf gesetzt wird. Die entscheidende Einstellung ist appendfsync:

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

Analyse der Leistungsabwägung: AOF vs. RDB

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

Latenz und Durchsatz

RDB (Am besten für reine Geschwindigkeit): Da Schreibvorgänge von einem Hintergrundprozess gehandhabt werden, erfährt der Haupt-Redis-Thread während der Speichervorgänge nur minimale direkte E/A-Auswirkungen. Dies führt im Allgemeinen zu einer geringeren Gesamt-Schreibleistungslatenz, 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 Vorgänge eine nahezu RDB-ähnliche Leistung, da fsync-Vorgänge gepuffert und seltener durchgeführt werden.

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): Der Datenverlust kann Minuten oder Stunden umfassen, abhängig vom Speicherplan.

Wiederherstellungszeit

RDB (Schnelle Wiederherstellung): Schnellere Neustartzeiten dank des optimierten, kompakten Binärformats.
AOF (Langsamere Wiederherstellung): Das Wiederabspielen eines großen Befehlslogs kann länger dauern als das Laden eines Schnappschusses, was die Ausfallzeiten bei Neustarts erhöht.

Best Practice: Verwendung beider Persistenzmethoden

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

Wenn beide aktiviert sind, verwendet Redis die AOF-Datei zur Wiederholung beim Start, um maximale Datenkonsistenz zu erreichen. Es wird weiterhin in regelmäßigen Abständen RDB-Schnappschüsse generiert.

Warum beides verwenden?

Schnellere Wiederherstellung: Wenn die AOF-Datei beschädigt wird oder extrem groß wird, kann Redis den neuesten RDB-Schnappschuss als Ausgangspunkt verwenden, was den anschließenden AOF-Wiederholungsprozess erheblich beschleunigt.
Effizienz der AOF-Neuschreibung: Redis kann automatisch einen AOF-Neuschreibvorgang auslösen (der eine neue, kompakte AOF-Datei erstellt, indem redundante Befehle verworfen werden), basierend auf dem neuesten RDB-Schnappschuss, was oft effizienter ist als das Überschreiben ausschließlich aus dem vorhandenen AOF-Log.

Konfigurationsausschnitt für beides:

# 1. RDB aktivieren
save 900 1

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

Verwaltung der AOF-Dateigröße (Neuschreibung)

Ein wesentliches 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 frühere Werte überschreiben. Um dies zu bekämpfen, bietet Redis die AOF-Neuschreibung.

AOF-Neuschreibung erzeugt eine neue, optimierte AOF-Datei, die nur die minimale Befehlsmenge enthält, die erforderlich ist, um den aktuellen Zustand des Datensatzes zu rekonstruieren. Dieser Vorgang wird automatisch ausgelöst, wenn die Größe der aktuellen AOF-Datei über ein bestimmtes Vielfaches der Basisgröße hinaus wächst.

auto-aof-rewrite-percentage 100  # Neuschreiben, 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 bezüglich der Neuschreibung: Ähnlich wie beim RDB-Speichern beinhaltet die AOF-Neuschreibung das Forken des Prozesses. Wenn Ihr System speicherbegrenzt ist, kann diese vorübergehende Verdoppelung der Speichernutzung (die laufende Instanz plus die neu zu schreibende Kopie) zu Instabilität oder Swapping führen.

Fazit

Die Entscheidungen zur Redis-Persistenz sind ein direkter Balanceakt zwischen Latenz und Haltbarkeit. RDB glänzt durch schnelle Wiederherstellung und minimalen Schreibaufwand, birgt aber das Risiko von Datenverlust. AOF bietet überlegene Datensicherheit, kann aber je nach fsync-Richtlinie zu Schreiblatenzen führen.

Für die meisten Produktions-Workloads, bei denen hoher Durchsatz bei angemessener Sicherheit im Vordergrund steht, ist das Aktivieren von AOF mit appendfsync everysec die Standardempfehlung. Für geschäftskritische Systeme, die nahezu keinen Datenverlust erfordern, bietet das Aktivieren beider, RDB und AOF, die beste betriebliche Ausfallsicherheit und Flexibilität bei der Leistungsabstimmung.