Redis-Persistenz-Vollversion

Einführung in die Persistenz

RDB

AOF

Der Unterschied zwischen RDB und AOF

Persistenz-Anwendungsszenarien

Für die Persistenzfunktion ist es eigentlich sehr einfach und nicht so kompliziert

Demo-Umgebung

Centos7.0

Redis4.0

Redis-Speicherverzeichnis: /usr/local/ redis

redis.conf-Speicherverzeichnis: /usr/local/redis/data

1. Einführung in die Persistenz

Alle Daten in Redis werden im Speicher gespeichert. Wenn Redis abstürzt, gehen die Daten verloren. Redis-Persistenz besteht darin, Daten auf der Festplatte zu speichern. Der Arbeitsmechanismus, der permanente Speichermedien verwendet, um Datenprozesse zu speichern und die gespeicherten Daten zu einem bestimmten Zeitpunkt wiederherzustellen, wird als Persistenz bezeichnet.

Was wird im Persistenzprozess gespeichert?

Das erste Snapshot-Formular speichert Datenergebnisse und konzentriert sich auf die Daten, bei denen es sich um die RDB

handelt, die weiter unten besprochen wird

Der zweite Typ von Betriebsprozess, der Speicherbetriebsprozess, konzentriert sich auf den Datenbetriebsprozess, der AOF

2. RDB

unten

2-1 RDB-Startmethode – Befehl speichern

Das folgende Bild zeigt die Konfigurationsinformationen von redis.conf. Nach der Ausführung Nach dem Speichern wird eine dump.rdb-Datei generiert

Jetzt legen wir einen Wert fest und speichern ihn dann in /usr/local/ redis/data Es wird eine Datei dump6379.rdb

geben

2-2 So verwenden Sie die RDB-Speicherung

• dbfilename dump6379.rdb: Legen Sie den RDB-Dateinamen fest, der Standardwert ist dump.rdb
• dir: Der Pfad zum Speichern der RDB- oder AOF-Datei
• rdbcompression ja: Legen Sie fest, ob Komprimieren Sie die Daten beim Speichern. Die Standardeinstellung ist „Ja“, mit LZF-Komprimierung
• rdbchecksum ja: Legen Sie fest, ob eine RDB-Dateiformatüberprüfung durchgeführt werden soll. Dieser Überprüfungsprozess wird sowohl beim Schreiben als auch beim Lesen von Dateien durchgeführt

2-3 RDB-Datenwiederherstellung

Tatsächlich erfordert diese Datenwiederherstellung im Vergleich zu anderen relationalen Datenbankwiederherstellungen grundsätzlich keine Vorgänge. Starten Sie es einfach neu

2-4 RDB – So funktioniert der Speicherbefehl

Wenn Sie Beim Ausführen des Speicherns Anweisungen von anderen Clients, die Redis anfordern, warten, bis die Speicheranweisung abgeschlossen ist. Da die Speicheranweisung in einem einzelnen Thread ausgeführt wird, führt eine zu lange Ausführungszeit direkt dazu, dass andere Benutzer Daten nicht normal speichern können. Daher wird dieser Befehl standardmäßig aufgegeben. Anstelle von

wird der unten vorgestellte bgsave verwendet

2-5 RDB – So funktioniert der bgsave-Befehl

Wenn bgsave in Redis ausgeführt wird Gibt direkt eine gestartete Hintergrundspeicherung zurück

Zu diesem Zeitpunkt sehen wir uns die Protokolldatei an. Der Befehl bgsave ist für das Problem der Speicherblockierung optimiert

2-5 RDB – Automatischer Start der Konfigurationsdatei

以下配置是默认配置
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes

[Zeit] [Anzahl der Schlüsseländerungen] sparen

Mit anderen Worten, wenn sich 10 Schlüsselwerte in 300 Sekunden ändern, wird bgsave im Hintergrund ausgeführt

3 >

3-1 AOF-Konzept

AOF-Dateien speichern den Prozess der Ausführung von Befehlsoperationen, und die Datenwiederherstellung wird auch mithilfe des Operationsprozesses wiederhergestellt.

3-2 AOF-Datenschreibprozess

Führen Sie einen Redis-Befehl aus

Redis‘ AOF aktualisiert den Befehlspuffer

Dann synchronisieren Sie es mit der in redis.conf konfigurierten .aof-Datei gemäß einer bestimmten Methode

3-3 AOF-Schreibdaten Drei Strategien

• immer: Ausgeführte Befehle werden in AOF-Dateien gespeichert, ohne Datenfehler und mit geringer Leistung. Die Verwendung von
• wird nicht empfohlen everysec: Synchronisiert die Anweisungen im Puffer jede Sekunde mit der AOF-Datei. Dies bietet eine höhere Datengenauigkeit und eine höhere Leistung. Dies wird empfohlen und ist auch die Standardkonfiguration. Wenn das System jedoch plötzlich herunterfährt, gehen die Daten innerhalb von 1 Sekunde verloren
• Nein: Das Betriebssystem steuert den Zyklus jeder Synchronisierung mit der AOF-Datei und der Gesamtprozess ist unkontrollierbar

3-4 AOF-Funktion aktiviert

• Konfiguration: appendonly yes|no
• Funktion: Ob die AOF-Persistenzfunktion aktiviert werden soll, die standardmäßig nicht aktiviert ist
• Konfiguration: appendfsync always| everysec | no
• Funktion: AOF-Schreibdatenstrategie
• Konfiguration: appenfilename Dateiname
• Funktion: AOF persistenter Dateiname, der Standardname ist appendonly.aof

Dann starten Sie den Redis-Dienst neu und Sie können die Datei appendonly.aof im Verzeichnis usr/local/redis/data

sehen

Dann führen wir einen Befehl auf dem Redis-Client aus und überprüfen ihn. Sie können sehen, dass die Daten in der Datei appendonly.aof gespeichert werden.

3-5 Probleme beim AOF-Schreiben von Daten

Schauen wir uns zunächst einen Fall an, nachdem wir den Namensschlüssel wiederholt festgelegt haben. Wir können sehen, dass es drei Vorgänge gibt, die jedoch alle durch einen Schlüssel geändert werden. Können wir nicht nur den letzten Schlüssel speichern? Mit dieser Frage schauen wir weiter nach unten

3-6 AOF-Umschreibung

Zum Beispiel haben wir oben den Befehl „set name“ dreimal ausgeführt, aber am Ende benötigen wir nur die Aufzeichnung der letzten Ausführung. Das heißt, wir benötigen nur den letzten Ausführungsdatensatz. Weitere Datensätze sind nicht erforderlich und die komprimierten Daten werden in die AOF-Datei neu geschrieben.

Unsere Festplattenauslastung hat sich nach dem Neuschreiben verbessert

Außerdem wird die Geschwindigkeit der Datenwiederherstellung schneller sein

Gleichzeitig wird auch die Effizienz der Persistenz verbessert

3-7 AOF-Umschreiberegeln

• Die im Prozess abgelaufenen Daten werden nicht mehr in die Datei geschrieben
• Löschanweisungen wie del ignorieren , hdel，srem. Es gibt auch das in 3-5 erwähnte Problem. Kontinuierliche Operationen auf einer Taste
• führen mehrere Schreibdatensätze derselben Daten zu einem Datensatz zusammen: Beispielsweise kann lpush list a lpush lsit b lpush list c in lpush list a b c umgewandelt werden.

3-8 AOF Manuelles Umschreiben

Befehl: bgrewriteaof

Im Anschluss an unsere Fragen 3–5 führen wir den Befehl bgrewriteaof in der Befehlszeile aus und zeigen dann die Datei appendonly.aof an

Wenn die Die Ausführung ist abgeschlossen. Sie werden feststellen, dass die Datei kleiner geworden ist und nur eine Anweisung in der Datei enthalten ist

3-9 Arbeitsprinzip des manuellen Umschreibens von AOF

3-10 AOF automatisches Neuschreiben

Konfiguration:auto-aof-rewrite-percentage 100 | auto-aof-rewrite-min-size 64mb

Trigger-Vergleichsparameter: aof_current_size | aof_base_size

Wenn aof_current_size > auto-aof-rewrite-min-size 64mb mit dem Neuschreiben beginnt

Dieses Bild kommt aus dem Internet

3-11 AOF-Workflow und Umschreibefluss = Prozess

4. Zusammenfassung

Das Obige dreht sich alles um Redis-Persistenz.

Das obige ist der detaillierte Inhalt vonRedis-Persistenz-Vollversion. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!