1. Der Unterschied zwischen RDB AOF
RDB-Persistenz besteht darin, innerhalb eines bestimmten Zeitintervalls einen Snapshot des Datensatzes im Speicher auf die Festplatte zu schreiben, einen untergeordneten Prozess zu forken und zuerst den zu schreiben Datensatz: Schreiben Sie eine temporäre Datei. Ersetzen Sie nach erfolgreichem Schreiben die vorherige Datei und speichern Sie sie mit binärer Komprimierung.
Spezifischer Vorgang: Durchlaufen Sie die Hash-Tabelle, verwenden Sie die Kopie beim Schreiben und speichern Sie den gesamten Datenbank-Dump.
Speichern, Herunterfahren und Slave-Befehle lösen diesen Vorgang aus.
Funktionen: Die Granularität ist relativ groß. Wenn das Speichern, Herunterfahren oder der Slave zuvor abgestürzt ist, können die Zwischenvorgänge nicht wiederhergestellt werden.
AOF-Persistenz zeichnet alle vom Server verarbeiteten Schreib- und Löschvorgänge in Form eines Protokolls auf. Abfragevorgänge werden nicht aufgezeichnet, sondern in Textform. Sie können die Datei öffnen, um detaillierte Vorgangsaufzeichnungen anzuzeigen. Redis kann die AOF-Datei auch im Hintergrund neu schreiben, sodass die Größe der AOF-Datei nicht die tatsächliche Größe überschreitet, die zum Speichern des Datensatzstatus erforderlich ist. Redis kann auch gleichzeitig AOF-Persistenz und RDB-Persistenz verwenden. In diesem Fall wird beim Neustart von Redis der Verwendung der AOF-Datei zum Wiederherstellen des Datensatzes Vorrang eingeräumt, da der von der AOF-Datei gespeicherte Datensatz normalerweise vollständiger ist als der von der RDB-Datei gespeicherte Datensatz. Sie können die Persistenz sogar deaktivieren, sodass die Daten nur vorhanden sind, während der Server ausgeführt wird.
Funktionen: Geringere Granularität: Nach einem Absturz können nur Vorgänge nicht wiederhergestellt werden, die vor dem Absturz keine Zeit zum Protokollieren hatten.
Das Auswahlkriterium besteht darin, zu sehen, ob das System bereit ist, im Austausch für eine höhere Cache-Konsistenz (aof) etwas Leistung zu opfern, oder ob es bereit ist, bei häufigen Schreibvorgängen kein Backup im Austausch für eine höhere Leistung zu aktivieren und abzuwarten save wird manuell ausgeführt und anschließend ein Backup erstellt (rdb). RDB hat eine letztendlich konsistentere Bedeutung.
2. Vor- und Nachteile von AOF RDB
AOF:
Vorteile: Durch die Verwendung der AOF-Persistenz wird Redis wesentlich langlebiger: Sie können verschiedene Fsync-Strategien festlegen, z Befehl wird ausgeführt. Die Standardrichtlinie von AOF besteht darin, einmal pro Sekunde zu fsyncen. Unter dieser Konfiguration kann Redis immer noch eine gute Leistung aufrechterhalten, und selbst wenn ein Fehler auftritt, geht höchstens eine Sekunde an Daten verloren (fsync wird in einem Hintergrundthread ausgeführt). so Der Hauptthread kann weiterhin hart arbeiten und Befehlsanforderungen verarbeiten. Bei der AOF-Datei handelt es sich um eine Protokolldatei, die nur Anhängevorgänge durchführt (nur Protokoll anfügen), sodass beim Schreiben in die AOF-Datei keine Suche erforderlich ist, selbst wenn das Protokoll aus bestimmten Gründen unvollständige Befehle enthält (z. B. wenn das Schreiben auf die Festplatte voll ist, Wenn das Schreiben auf halbem Weg gestoppt wird usw.), kann das Tool redis-check-aof dieses Problem ebenfalls leicht beheben.
Redis kann die AOF automatisch im Hintergrund neu schreiben, wenn die AOF-Datei zu groß wird: Die neue AOF-Datei enthält nach dem Umschreiben den Mindestsatz an Befehlen, der zum Wiederherstellen des aktuellen Datensatzes erforderlich ist. Der gesamte Umschreibvorgang ist absolut sicher, da Redis während des Erstellungsprozesses einer neuen AOF-Datei weiterhin Befehle an die vorhandene AOF-Datei anhängt. Selbst wenn es während des Umschreibvorgangs zu einem Herunterfahren kommt, geht die vorhandene AOF-Datei nicht verloren. . Sobald die neue AOF-Datei erstellt wurde, wechselt Redis von der alten AOF-Datei zur neuen AOF-Datei und beginnt mit dem Anhängen an die neue AOF-Datei. Die AOF-Datei speichert alle in der Datenbank ausgeführten Schreibvorgänge geordnet. Diese Schreibvorgänge werden im Format des Redis-Protokolls gespeichert. Daher ist der Inhalt der AOF-Datei sehr einfach zu lesen und die Datei zu analysieren (analysieren). Auch das Exportieren (Exportieren) von AOF-Dateien ist sehr einfach: Wenn Sie beispielsweise versehentlich den FLUSHALL-Befehl ausführen, aber solange die AOF-Datei nicht überschrieben wurde, dann stoppen Sie einfach den Server und entfernen Sie den FLUSHALL-Befehl am Ende der AOF Datei und starten Sie Redis neu. Sie können den Datensatz in den Zustand vor der Ausführung von FLUSHALL zurückversetzen.
Nachteile:
Bei demselben Datensatz ist die Größe der AOF-Datei normalerweise größer als die Größe der RDB-Datei. Abhängig von der verwendeten Fsync-Strategie ist AOF möglicherweise langsamer als RDB. Unter normalen Umständen ist die Leistung von fsync pro Sekunde immer noch sehr hoch, und durch Deaktivieren von fsync kann AOF selbst unter hoher Last so schnell wie RDB werden. Allerdings kann RDB bei der Verarbeitung großer Schreiblasten eine garantiertere maximale Latenz bieten. Bei AOF gab es in der Vergangenheit einen solchen Fehler: Aufgrund einzelner Befehle konnte beim erneuten Laden der AOF-Datei der Datensatz beim Speichern nicht in den ursprünglichen Zustand zurückversetzt werden. (Zum Beispiel hat der Blockierungsbefehl BRPOPLPUSH einmal einen solchen Fehler verursacht.) Für diese Situation wurden der Testsuite Tests hinzugefügt: Sie generieren automatisch zufällige, komplexe Datensätze und laden diese Daten neu, um sicherzustellen, dass alles normal ist. Obwohl diese Art von Fehler in AOF-Dateien nicht häufig vorkommt, ist es im Vergleich dazu bei RDB fast unmöglich, einen solchen Fehler zu haben. Vorteile von
RDB:
RDB ist eine sehr kompakte Datei, die den Redis-Datensatz zu einem bestimmten Zeitpunkt speichert. Diese Art von Datei eignet sich sehr gut für die Sicherung: Sie können beispielsweise jede Stunde in den letzten 24 Stunden eine RDB-Datei sichern und auch jeden Tag im Monat eine RDB-Datei sichern. Auf diese Weise können Sie den Datensatz jederzeit in einer anderen Version wiederherstellen, selbst wenn ein Problem auftritt. RDB eignet sich hervorragend für die Notfallwiederherstellung: Es besteht aus nur einer Datei, der Inhalt ist sehr kompakt und kann (nach der Verschlüsselung) an andere Rechenzentren oder an Amazon S3 übertragen werden. RDB kann die Leistung von Redis maximieren: Das Einzige, was der übergeordnete Prozess beim Speichern der RDB-Datei tun muss, ist, einen untergeordneten Prozess auszulagern, und dann übernimmt der untergeordnete Prozess alle nachfolgenden Speicherarbeiten, der übergeordnete Prozess muss dies nicht tun Führen Sie alle Festplatten-E/A-Vorgänge aus. RDB ist beim Wiederherstellen großer Datensätze schneller als AOF.
Nachteile:
Wenn Sie einen Datenverlust bei einem Serverausfall vermeiden möchten, ist RDB nicht für Sie geeignet. Obwohl Sie mit Redis verschiedene Speicherpunkte festlegen können, um die Häufigkeit des Speicherns von RDB-Dateien zu steuern, ist dies kein einfacher Vorgang, da RDB-Dateien den Status des gesamten Datensatzes speichern müssen. Daher können Sie die RDB-Datei mindestens alle 5 Minuten speichern. In diesem Fall kann es bei einem Ausfall zu einem Datenverlust von mehreren Minuten kommen. Jedes Mal, wenn die RDB gespeichert wird, muss Redis einen untergeordneten Prozess forken(), und der untergeordnete Prozess führt die eigentliche Persistenzarbeit aus. Wenn der Datensatz groß ist, kann fork() sehr zeitaufwändig sein und dazu führen, dass der Server die Verarbeitung des Clients innerhalb einer bestimmten Millisekunde stoppt. Wenn der Datensatz sehr groß und die CPU-Zeit sehr knapp ist, kann diese Stoppzeit auftreten sogar eine ganze Sekunde länger sein. Obwohl das AOF-Umschreiben auch fork () erfordert, kommt es zu keinem Verlust an Datenhaltbarkeit, egal wie lang das Ausführungsintervall des AOF-Umschreibens ist.