Welche Persistenzstrategie eignet sich für Redis?

Redis bietet eine Vielzahl von Persistenzmethoden auf verschiedenen Ebenen:

RDB-Persistenz kann Datensätze innerhalb eines bestimmten Zeitintervalls generieren Zeitlicher Schnappschuss.

AOF zeichnet dauerhaft alle vom Server ausgeführten Schreiboperationsbefehle auf und stellt den Datensatz wieder her, indem diese Befehle beim Serverstart erneut ausgeführt werden. Alle Befehle in der AOF-Datei werden im Redis-Protokollformat gespeichert und neue Befehle werden am Ende der Datei angehängt. 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 läuft.

RDB-Wissenspunkte

Vorteile von RDB

RDB ist eine sehr kompakte Datei, die Redis-Datensätze an einem bestimmten Ort speichert Zeitpunkt. Dieser Dateityp ist ideal für Sicherungszwecke: Sie könnten beispielsweise eine RDB-Datei in den letzten 24 Stunden jede Stunde 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 sehr gut für die Notfallwiederherstellung: Es enthält nur eine Datei, der Inhalt ist sehr kompakt und kann (nach 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 keine Festplatten-E/A-Vorgänge ausführen.

RDB ist beim Wiederherstellen großer Datensätze schneller als AOF.

Nachteile von RDB

Wenn Sie den Datenverlust im Falle eines Serverausfalls minimieren müssen, ist RDB nichts für Sie. 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.

AOF-Wissenspunkte

Vorteile von AOF

Die Verwendung von AOF-Persistenz macht Redis sehr langlebig (viel langlebiger): Sie können verschiedene fsync-Strategien festlegen, z. B. kein fsync, fsync einmal pro Sekunde oder fsync jedes Mal, wenn ein Schreibbefehl ausgeführt wird. 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 daran arbeiten, Befehlsanfragen zu verarbeiten.

Bei der AOF-Datei handelt es sich um eine Protokolldatei, die nur zum Anhängen verwendet werden kann. Das Schreiben in die AOF-Datei erfordert daher keine Suche, auch wenn das Protokoll aus bestimmten Gründen unvollständige Befehle enthält (z. B. wenn die Festplatte beim Schreiben 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 neu geschriebene AOF-Datei enthält 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 in geordneter Weise. Diese Schreibvorgänge werden im Format des Redis-Protokolls gespeichert, sodass der Inhalt der AOF-Datei sehr einfach zu lesen und zu analysieren ist Datei (Parse) ist auch sehr einfach. 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 von AOF

Bei demselben Datensatz ist die Größe von AOF-Dateien normalerweise größer als die von RDB-Dateien.

AOF kann je nach verwendeter Fsync-Strategie langsamer als RDB sein. Unter normalen Umständen ist die Fsync-Leistung 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 bestimmter Befehle konnte beim erneuten Laden der AOF-Datei der Datensatz nicht in den ursprünglichen Zustand beim Speichern 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.

Weitere technische Artikel zum Thema Redis finden Sie in der Spalte Redis-Tutorial, um mehr darüber zu erfahren!

Das obige ist der detaillierte Inhalt vonWelche Persistenzstrategie eignet sich für Redis?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!