Erfahren Sie in einem Artikel mehr über die RDB- und AOP-Persistenz in Redis

Dieser Artikel führt Sie durch die beiden Persistenzmechanismen (RDB und AOP) in redis. Ich hoffe, er wird Ihnen hilfreich sein!

redis ist eine In-Memory-Datenbank, und die Daten werden im Speicher gespeichert, aber wir alle wissen, dass sich die Daten im Speicher schnell ändern und anfällig für Verluste sind. Glücklicherweise stellt uns Redis auch Persistenzmechanismen zur Verfügung, nämlich RDB (Redis DataBase) und AOF (Append Only File). [Verwandte Empfehlungen: Redis-Video-Tutorial]

Hier wird davon ausgegangen, dass Sie die grundlegende Syntax von Redis bereits verstehen. Eine bestimmte Alphabet-Website verfügt über ein gutes Tutorial. Sie können es sich ansehen. Ich werde keine Artikel über die grundlegende Verwendung schreiben, es sind alles häufig verwendete Befehle.

Das Folgende ist eine Einführung in diese beiden Methoden. Von flach bis tief.

1. Persistenzprozess

Da Redis-Daten auf der Festplatte gespeichert werden können, wie sieht dieser Prozess aus?

Die folgenden fünf Prozesse sind erforderlich:

(1) Der Client sendet einen Schreibvorgang an den Server (die Daten befinden sich im Speicher des Clients).

(2) Der Datenbankserver empfängt die Daten der Schreibanforderung (die Daten befinden sich im Speicher des Servers).

(3) Der Server ruft den Schreibsystemaufruf auf, um die Daten auf die Festplatte zu schreiben (die Daten befinden sich im Puffer des Systemspeichers).

(4) Das Betriebssystem überträgt die Daten im Puffer an den Festplattencontroller (die Daten befinden sich im Festplatten-Cache).

(5) Der Festplattencontroller schreibt die Daten auf das physische Medium der Festplatte (die Daten fallen tatsächlich auf die Festplatte).

Diese 5 Prozesse sind unter idealen Bedingungen ein normaler Speichervorgang, aber in den meisten Fällen kommt es bei unseren Maschinen usw. zu verschiedenen Ausfällen:

(1) Wenn die Redis-Datenbank ausfällt, solange der dritte Wenn der obige Schritt abgeschlossen ist, kann er beibehalten und gespeichert werden, und das Betriebssystem führt die verbleibenden zwei Schritte für uns aus.

(2) Wenn das Betriebssystem ausfällt, müssen alle oben genannten 5 Schritte ausgeführt werden.

Hier berücksichtigen wir nur mögliche Fehler während des Speichervorgangs. Tatsächlich können die gespeicherten Daten auch beschädigt werden, was einen bestimmten Wiederherstellungsmechanismus erfordert, auf den hier jedoch nicht näher eingegangen wird. Die Hauptüberlegung besteht nun darin, wie Redis die oben genannten fünf Schritte zum Speichern von Datenträgern implementiert. Es bietet zwei Richtlinienmechanismen, nämlich RDB und AOF.

2. RDB-Mechanismus

RDB speichert Daten tatsächlich in Form von Snapshots auf der Festplatte. Was ist ein Schnappschuss? Man kann darunter verstehen, dass man die Daten im aktuellen Moment fotografiert und speichert.

RDB-Persistenz bezieht sich auf das Schreiben eines Snapshots des In-Memory-Datensatzes auf die Festplatte innerhalb eines bestimmten Zeitintervalls. Dies ist auch die Standard-Persistenzmethode. Diese Methode schreibt die Daten im Speicher in Form eines Snapshots. Der Standarddateiname lautet dump.rdb.

Nachdem wir Redis installiert haben, befinden sich alle Konfigurationen in der Datei redis.conf, in der verschiedene Konfigurationen der beiden Persistenzmechanismen RDB und AOF gespeichert sind.

Da der RDB-Mechanismus alle Daten zu einem bestimmten Zeitpunkt speichert, indem er einen Snapshot erstellt, sollte es einen Auslösemechanismus geben, um diesen Prozess zu implementieren. Für RDB stehen drei Mechanismen zur Verfügung: Speichern, BGSAVE und Automatisierung. Schauen wir uns jeden einzeln an

1. Speicherauslösemethode

Während der Ausführung des Speicherbefehls kann Redis keine anderen Befehle verarbeiten, bis der RDB-Prozess abgeschlossen ist. Der spezifische Prozess ist wie folgt:

Wenn nach Abschluss der Ausführung eine alte RDB-Datei vorhanden ist, ersetzen Sie die alte durch die neue. Unsere Kunden können Zehntausende oder Hunderttausende sein, daher ist dieser Ansatz offensichtlich nicht ratsam.

2. bgsave-Auslösemethode

Wenn dieser Befehl ausgeführt wird, führt Redis Snapshot-Vorgänge asynchron im Hintergrund aus und der Snapshot kann auch auf Client-Anfragen reagieren. Der spezifische Prozess ist wie folgt:

Der spezifische Vorgang besteht darin, dass der Redis-Prozess eine Fork-Operation ausführt, um einen untergeordneten Prozess zu erstellen. Der RDB-Persistenzprozess ist für den untergeordneten Prozess verantwortlich und endet automatisch nach Abschluss. Die Blockierung erfolgt nur während der Fork-Phase und ist im Allgemeinen nur von kurzer Dauer. Grundsätzlich verwenden alle RDB-Vorgänge in Redis den Befehl bgsave.

3. Automatische Auslösung

Die automatische Auslösung erfolgt durch unsere Konfigurationsdatei. In der Konfigurationsdatei redis.conf gibt es die folgenden Konfigurationen, die wir festlegen können:

①Speichern: Dies wird verwendet, um die RDB-Persistenzbedingungen zu konfigurieren, die Redis auslösen, d. h. wann die Daten im Speicher auf der Festplatte gespeichert werden sollen Scheibe. Zum Beispiel „m n speichern“. Gibt an, dass bgsave automatisch ausgelöst wird, wenn der Datensatz innerhalb von m Sekunden n-mal geändert wird.

Die Standardkonfiguration ist wie folgt:

# bedeutet, dass 900 gespeichert werden, wenn sich innerhalb von 900 Sekunden mindestens 1 Schlüsselwert ändert. 1# bedeutet, dass 300 gespeichert werden, wenn sich innerhalb von 300 Sekunden mindestens 10 Schlüsselwerte ändern. 10# bedeutet, dass sich innerhalb von 60 Sekunden mindestens 10.000 Schlüsselwerte ändern Eine Schlüsseländerung, Speichern von 60 10000

erfordert keine Persistenz. Anschließend können Sie alle Speicherzeilen auskommentieren, um die Speicherfunktion zu deaktivieren.

②stop-writes-on-bgsave-error: Der Standardwert ist „yes“. Wenn RDB aktiviert ist und die letzte Datenspeicherung im Hintergrund fehlschlägt, wird angezeigt, ob Redis keine Daten mehr empfängt. Dadurch würde der Benutzer darauf aufmerksam gemacht, dass die Daten nicht ordnungsgemäß auf der Festplatte gespeichert wurden, andernfalls würde niemand bemerken, dass eine Katastrophe aufgetreten ist. Wenn Redis neu gestartet wird, kann es wieder Daten empfangen

③rdbcompression; der Standardwert ist „yes“. Für auf der Festplatte gespeicherte Snapshots können Sie festlegen, ob diese zur Speicherung komprimiert werden sollen.

④rdbchecksum: Der Standardwert ist ja. Nach dem Speichern des Snapshots können wir Redis auch den CRC64-Algorithmus zur Datenüberprüfung verwenden lassen, dies erhöht jedoch den Leistungsverbrauch um etwa 10 %. Wenn Sie die maximale Leistungsverbesserung erzielen möchten, können Sie diese Funktion deaktivieren.

⑤dbfilename: Legen Sie den Dateinamen des Snapshots fest. Der Standardwert ist dump.rdb.

⑥dir: Legen Sie den Speicherpfad der Snapshot-Datei fest. Dieses Konfigurationselement muss ein Verzeichnis und kein Dateiname sein.

Wir können diese Konfigurationen ändern, um die gewünschten Effekte zu erzielen. Da die dritte Methode konfiguriert ist, vergleichen wir die ersten beiden:

4. Vor- und Nachteile von RDB

①, Vorteile

(1) Die RDB-Datei ist kompakt und vollständig gesichert. Ideal für Backup und Disaster Recovery.

(2) Beim Generieren einer RDB-Datei gibt der Redis-Hauptprozess einen Unterprozess ab (), der alle Speicherarbeiten erledigt. Der Hauptprozess muss keine Festplatten-E/A-Vorgänge ausführen.

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

② Nachteile

RDB-Snapshot ist ein vollständiges Backup, das die binär serialisierte Form von Speicherdaten speichert und sehr kompakt im Speicher ist. Wenn die Snapshot-Persistenz ausgeführt wird, wird ein untergeordneter Prozess gestartet, der speziell für die Snapshot-Persistenz verantwortlich ist. Der untergeordnete Prozess besitzt die Speicherdaten des übergeordneten Prozesses. Änderungen am Speicher durch den untergeordneten Prozess werden daher nicht widergespiegelt Während der Snapshot-Persistenz geänderte Daten werden nicht gespeichert und können verloren gehen.

3. AOF-Mechanismus

Eine vollständige Sicherung ist immer zeitaufwändig. Der Arbeitsmechanismus von Redis ist sehr einfach. Das gängige Verständnis ist Protokollierung.

1. Persistenzprinzip

Sehen Sie sich das Bild unten an:

Immer wenn ein Schreibbefehl kommt, wird er direkt in unserer AOF-Datei gespeichert.

2. Prinzip des Dateiumschreibens

Die AOF-Methode bringt auch ein weiteres Problem mit sich. Persistenzdateien werden immer größer. Um die persistente Datei von aof zu komprimieren. Redis stellt den Befehl bgrewriteaof bereit. Speichern Sie die Daten im Speicher in Form eines Befehls in einer temporären Datei und forcieren Sie gleichzeitig einen neuen Prozess, um die Datei neu zu schreiben.

Der Vorgang des Umschreibens der AOF-Datei liest nicht die alte AOF-Datei, sondern schreibt den gesamten Datenbankinhalt im Speicher mithilfe von Befehlen in eine neue AOF-Datei um. Dies ähnelt in gewisser Weise einem Snapshot.

3. AOF verfügt außerdem über drei Auslösemechanismen: (1) Synchronisierung bei jeder Änderung: Bei jeder Datenänderung wird diese sofort auf der Festplatte aufgezeichnet Die Datenintegrität ist besser

(1) AOF kann Um Daten besser vor Verlust zu schützen, führt AOF im Allgemeinen alle 1 Sekunde einen Fsync-Vorgang über einen Hintergrundthread aus, wobei maximal 1 Sekunde Daten verloren gehen. (2) AOF-Protokolldateien haben keinen Festplattenadressierungsaufwand, die Schreibleistung ist sehr hoch und die Dateien werden nicht leicht beschädigt.

(3) Selbst wenn die AOF-Protokolldatei zu groß ist, haben Umschreibvorgänge im Hintergrund keinen Einfluss auf das Lesen und Schreiben des Clients.

(4) Die Befehle der AOF-Protokolldatei werden auf sehr lesbare Weise aufgezeichnet. Diese Funktion eignet sich sehr gut für die Notfallwiederherstellung nach einem katastrophalen versehentlichen Löschen. Beispielsweise löscht jemand versehentlich alle Daten mit dem Befehl „flushall“ Solange das Umschreiben im Hintergrund zu diesem Zeitpunkt noch nicht erfolgt ist, kann die AOF-Datei sofort kopiert werden, der letzte Befehl „flushall“ wird gelöscht und die AOF-Datei wird dann zurückgesetzt. Alle Daten automatisch über den Wiederherstellungsmechanismus wiederherstellen

5 Nachteile

(1) Für die gleichen Daten sind AOF-Protokolldateien normalerweise größer als RDB-Daten-Snapshot-Dateien

(2) Nachdem AOF aktiviert wurde, ist die unterstützte Schreib-QPS niedriger als die von RDB unterstützte Schreib-QPS, da AOF dies im Allgemeinen tut Konfigurieren Sie die Protokolldatei einmal pro Sekunde, und die Leistung ist natürlich immer noch sehr hoch

(3) Bei der Datenwiederherstellung ist in AOF zuvor ein Fehler aufgetreten Genau die gleichen Daten wurden nicht wiederhergestellt.

4. So wählen Sie zwischen RDB und AOF

Wenn Sie sich entscheiden, sind die beiden zusammen besser. Da Sie die beiden Persistenzmechanismen verstehen, hängt der Rest von Ihren eigenen Anforderungen ab. Möglicherweise wählen Sie einen aufgrund unterschiedlicher Anforderungen aus, sie werden jedoch normalerweise in Kombination verwendet. Zur Zusammenfassung gibt es ein Bild:

Nach dem Vergleich dieser Funktionen liegt der Rest bei Ihnen.

Weitere Kenntnisse zum Thema Programmierung finden Sie unter: Programmiervideos! !

Das obige ist der detaillierte Inhalt vonErfahren Sie in einem Artikel mehr über die RDB- und AOP-Persistenz in Redis. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!