Es gibt zwei Optionen zur dauerhaften Speicherung von Daten in Redis: AOF (Append-Only File) und RDB (Redis Database Snapshot). In Produktionsumgebungen werden normalerweise beide Optionen zusammen eingestellt, aber viele Entwickler haben möglicherweise folgende Fragen:
"Wenn AOF die Daten in Echtzeit aufzeichnet, macht es dann einen Sinn, RDB einzustellen?" "Da AOF für die Wiederherstellung Vorrang hat, ist RDB dann nicht überflüssig?"
In einer echten Produktionsumgebung ist jedoch RDB unbedingt erforderlich. Lassen Sie uns die Gründe dafür untersuchen.
1. AOF-Dateien können beschädigt werden
Obwohl AOF alle Änderungen protokolliert, besteht ein Risiko der Dateibeschädigung. Bei Festplattendefekten, Ausfällen während des Betriebs oder unsachgemäßen Datei-Uploads kann die AOF-Datei beschädigt werden, was die Wiederherstellung erschwert.
redis-server --appendonly yes
Wenn die AOF-Datei beim Neustart von Redis beschädigt ist, kann es unmöglich sein, die Daten wiederherzustellen. In solchen Fällen kann eine RDB-Sicherung helfen, zumindest einige Daten wiederherzustellen.
✅ Was, wenn nur AOF verwendet wird und die Datei beschädigt ist? Erhöhtes Risiko eines Datenverlusts
✅ Was ist, wenn RDB vorhanden ist? Mindestens einige Daten können wiederhergestellt werden
2. AOF-Wiederherstellung ist langsam
Die Wiederherstellung von AOF erfordert, dass alle Änderungen nacheinander erneut ausgeführt werden. Je mehr Daten vorhanden sind, desto länger kann die Wiederherstellungszeit beim Neustart von Redis dauern.
Wenn die AOF-Datei beispielsweise 2 GB beträgt, muss Redis Millionen von SET-Befehlen ausführen. Im Gegensatz dazu lädt RDB einfach die Dump-Datei, sodass die Wiederherstellung viel schneller erfolgt.
✅ Was passiert, wenn nur AOF verwendet wird? Es besteht die Gefahr, dass die Wiederherstellungszeit verlängert wird
✅ Was passiert, wenn RDB zusammen verwendet wird? Schnelle Wiederherstellung möglich
3. RDB ist vorteilhaft für Backups und Server-Migrationen
Bei der Datensicherung in Produktionsumgebungen ist AOF aufgrund seiner großen Dateigröße und des Log-Formats schwer zu handhaben. Im Gegensatz dazu hat RDB eine kleinere Dateigröße und kann Daten zu einem bestimmten Zeitpunkt beibehalten, was die Sicherung erheblich erleichtert.
✔ Beispiel für ein Backup mit RDB:
cp /var/lib/redis/dump.rdb /backup/dump-2025-02-17.rdb
✔ Beispiel für die Datenmigration zu einem anderen Server:
scp /var/lib/redis/dump.rdb new-server:/var/lib/redis/
✅ Je mehr Daten in AOF, desto schwieriger die Sicherung
✅ RDB ist vorteilhaft für schnelle Backups und Wiederherstellungen der Daten zu einem bestimmten Zeitpunkt
4. Reduziert die I/O-Belastung der Festplatte
Da AOF alle Änderungen auf die Festplatte schreiben muss, ist die I/O-Belastung auf der Festplatte hoch. RDB hingegen speichert nur einmal in festgelegten Intervallen, wodurch die Festplattenbelastung geringer ist.
✅ Was passiert, wenn nur AOF verwendet wird? Wahrscheinlich erhöhte Festplattenbelastung
✅ Was passiert, wenn RDB parallel verwendet wird? Möglichkeit zur Leistungsoptimierung
5. Empfohlene RDB + AOF-Einstellungen in Produktionsumgebungen
In Produktionsumgebungen empfehlen wir die folgenden Einstellungen.
# RDB Snapshot-Einstellungen (Daten werden auf der Festplatte gespeichert, wenn die Bedingungen erfüllt sind)
# save <seconds> <changes> [<seconds> <changes> ...]
save 900 1 300 10 60 10000
# Speichern, wenn während 900 Sekunden (15 Minuten) mehr als 1 Schlüssel geändert wurde, oder während 300 Sekunden (5 Minuten) mehr als 10 Schlüssel geändert wurden, oder während 60 Sekunden (1 Minute) mehr als 10.000 Schlüssel geändert wurden
# Aktiviere AOF
appendonly yes
appendfsync everysec # Auf die Festplatte schreiben, um ein Gleichgewicht zwischen Leistung und Stabilität zu halten
# Automatische Optimierung der AOF-Dateigröße (Rewrite)
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
🔍 Wie werden mehrere save-Bedingungen bewertet?
In Redis funktionieren alle save-Bedingungen als ODER-Bedingungen. Das bedeutet, dass bereits eine erfüllte Bedingung ausreicht, um einen Snapshot zu speichern.
✔ Beispiel 1: Wenn save 900 1 und save 60 10000 eingestellt sind - Ein oder mehrere Schlüsseländerungen in 900 Sekunden - Oder über 10.000 Änderungen in 60 Sekunden - speichern den RDB-Snapshot.
✔ Beispiel 2: Wenn die Bedingung save 300 10 hinzugefügt wird - Mehr als 10 Schlüsseländerungen in 300 Sekunden - Oder mehr als 1 Änderung in 900 Sekunden - Oder mehr als 10.000 Änderungen in 60 Sekunden - speichern den RDB-Snapshot.
✅ Alle save-Optionen werden als ODER-Bedingungen bewertet
✅ Wenn auch nur eine Bedingung erfüllt ist, wird RDB sofort gespeichert
Fazit: RDB ist trotz AOF unbedingt erforderlich
✅ AOF alleine bietet keinen perfekten Datenschutz
✅ Wenn AOF beschädigt ist, übernimmt RDB die letzte Backup-Rolle
✅ Da die Wiederherstellung von AOF langsam sein kann, ermöglicht RDB eine schnellere Wiederherstellung
✅ RDB ist vorteilhaft für Backups und Server-Migrationen
✅ Es ist möglich, die I/O-Belastung der Festplatte zu reduzieren und die Leistung zu optimieren
✅ save-Einstellungen arbeiten als ODER-Bedingungen, sodass bei Erfüllung eine RDB gespeichert wird
Daher ist es in Produktionsumgebungen am sichersten und optimalsten, RDB + AOF zusammen einzustellen.
Probieren Sie die Suchfunktion rechts aus, um nach `Redis` zu suchen! Es sind weitere Beiträge zu Redis vorbereitet.
Überprüfen Sie auch den vorherigen Beitrag, der eine Analyse der AOF Rewrite-Funktion enthält.
Add a New Comment