RDB ist eine Persistenzmethode, die den Status der Datenbank durch Speichern von Schlüssel-Wert-Paaren in der Datenbank aufzeichnen kann. AOF ist eine Persistenzmethode, die den Datenbankstatus speichert, indem sie vom Redis-Server ausgeführte Schreibbefehle aufzeichnet.
Zum Beispiel für den folgenden Befehl:
Die RDB-Persistenzmethode besteht darin, die drei Schlüssel-Wert-Paare str1, str2 und str3 in der RDB-Datei zu speichern, während die AOF-Persistenz darin besteht, den Satz auszuführen. Die drei Befehle sadd und lpush werden in der AOF-Datei gespeichert.
Unter APPEND ONLY MODE in der redis.conf-Konfigurationsdatei:
①, appendonly: Der Standardwert ist no, was bedeutet, dass Redis standardmäßig die RDB-Persistenz verwendet AOF-Persistenz, Sie müssen appendonly in „yes“ ändern.
②, appendfilename: aof-Dateiname, der Standardwert ist „appendonly.aof“
③, appendfsync: aof-Persistenzstrategiekonfiguration;
no bedeutet, dass fsync nicht ausgeführt wird, und das Betriebssystem stellt sicher, dass die Daten werden mit der Festplatte synchronisiert, was am schnellsten ist, aber nicht sehr sicher;
Immer wird fsync für jeden Schreibvorgang ausgeführt, um sicherzustellen, dass die Daten mit der Festplatte synchronisiert werden, was sehr ineffizient ist Wenn fsync einmal pro Sekunde ausgeführt wird, kann dies dazu führen, dass die Daten innerhalb einer Sekunde verloren gehen. Wählen Sie normalerweise „Everysec“, um Sicherheit und Effizienz in Einklang zu bringen.
④, no-appendfsync-on-rewrite: Wenn aof neu geschrieben oder in eine RDB-Datei geschrieben wird, wird eine große Menge an E/A ausgeführt. Zu diesem Zeitpunkt führt die Ausführung von fsync für a Lange Zeit. Das Feld „no-appendfsync-on-rewrite“ ist standardmäßig auf „no“ gesetzt. Wenn die Anwendung hohe Latenzanforderungen hat, kann dieses Feld auf „Ja“ gesetzt werden, andernfalls wird es auf „Nein“ gesetzt, was eine sicherere Wahl für die Persistenzfunktion ist. Die Einstellung „Ja“ bedeutet, dass neue Schreibvorgänge während des Neuschreibens nicht fsyncd werden, sondern vorübergehend im Speicher gespeichert und nach Abschluss des Neuschreibens geschrieben werden. Die Standardeinstellung ist „Nein“, und „Ja“ wird empfohlen. Die Standard-Fsync-Richtlinie von Linux beträgt 30 Sekunden. Es können 30 Sekunden Daten verloren gehen. Der Standardwert ist nein.
Der Standardwert für Auto-Aof-Rewrite-Prozentsatz ist 100. Wenn die aktuelle AOF-Dateigröße den Prozentsatz der zuletzt neu geschriebenen AOF-Dateigröße überschreitet, wird sie neu geschrieben. Das heißt, wenn die AOF-Datei eine bestimmte Größe erreicht, kann Redis bgrewriteaof aufrufen, um die Protokolldatei neu zu schreiben. Wenn die Größe der AOF-Datei das Doppelte der Größe des letzten Protokollumschreibens erreicht (auf 100 eingestellt), wird automatisch ein neuer Protokollumschreibvorgang gestartet.
auto-aof-rewrite-min-size ist auf 64 MB eingestellt. Um zu vermeiden, dass bei Erreichen des vereinbarten Prozentsatzes neu geschrieben werden muss, können Sie eine Mindestdateigröße festlegen.
⑦, aof-load-truncated: Die AOF-Datei ist am Ende möglicherweise unvollständig. Wenn Redis startet, werden die Daten der AOF-Datei in den Speicher geladen. Der Neustart kann erfolgen, nachdem das Host-Betriebssystem, auf dem sich Redis befindet, ausgefallen ist, insbesondere wenn das ext4-Dateisystem die Option „data=ordered“ nicht hinzufügt. Dieses Phänomen führt nicht dazu, dass das Ende unvollständig ist Sie können Redis beenden lassen oder so viele Daten wie möglich importieren. Sobald die Option „Ja“ ausgewählt ist, wird automatisch ein Protokoll an den Client gesendet und geladen, wenn die verkürzte AOF-Datei importiert wird. Wenn die Antwort „Nein“ lautet, muss der Benutzer den Befehl redis-check-aof manuell ausführen, um die AOF-Datei zu reparieren. Der Standardwert ist ja.
3. Aktivieren Sie AOF
Der Speicherort, an dem AOF Dateien speichert, ist derselbe, an dem RDB Dateien speichert. Sie werden über das Verzeichnis der redis.conf-Konfigurationsdatei konfiguriert:
Sie können den gespeicherten Pfad über den Befehl config get dir abrufen .
4. AOF-Dateiwiederherstellung
Ausnahmereparaturbefehl: redis-check-aof --fix zum Reparieren
5. AOF-Rewriting: Da AOF-Persistenz darin besteht, dass Redis kontinuierlich Schreibbefehle in der AOF-Datei aufzeichnet, wird AOF Die Datei wird Je größer die Datei, desto mehr Serverspeicher wird belegt und desto länger dauert die AOF-Wiederherstellung. Um dieses Problem zu lösen, hat Redis einen neuen Umschreibemechanismus hinzugefügt. Wenn die Größe der AOF-Datei den festgelegten Schwellenwert überschreitet, startet Redis die Inhaltskomprimierung der AOF-Datei und behält dabei nur den minimalen Befehlssatz bei, der die Daten wiederherstellen kann. Sie können den Befehl bgrewriteaof verwenden, um es neu zu schreiben.
Wenn die AOF-Datei nicht neu geschrieben wird, speichert die AOF-Datei vier SADD-Befehle. Wenn AOF-Neuschreiben verwendet wird, bleibt nur der folgende Befehl in der AOF-Datei erhalten:
1 |
|
Das heißt, beim Umschreiben der AOF-Datei wird die Originaldatei nicht neu organisiert, sondern die vorhandenen Schlüssel-Wert-Paare des Servers werden direkt gelesen und dann ein Befehl verwendet Um die mehreren Befehle zu ersetzen, die zuvor dieses Schlüssel-Wert-Paar aufgezeichnet haben, generieren Sie eine neue Datei und ersetzen Sie die ursprüngliche AOF-Datei.
Auslösemechanismus für das Umschreiben von AOF-Dateien: über Auto-aof-rewrite-percentage in der Konfigurationsdatei redis.conf: Der Standardwert ist 100 und die Konfiguration auto-aof-rewrite-min-size: 64 MB, was die Standardkonfiguration von Redis bedeutet Die AOF-Größe zum Zeitpunkt des letzten Neuschreibens wird aufgezeichnet. Die Standardkonfiguration besteht darin, auszulösen, wenn die AOF-Dateigröße doppelt so groß ist wie nach dem letzten Neuschreiben und die Datei größer als 64 MB ist.
Lassen Sie es mich noch einmal erwähnen: Wir wissen, dass Redis ein Single-Thread-Job ist. Wenn das Umschreiben von AOF lange dauert, kann Redis während des Umschreibens von AOF lange Zeit keine anderen Befehle verarbeiten , was offensichtlich unerträglich ist. Um dieses Problem zu lösen, besteht die Lösung von Redis darin, das AOF-Umschreibprogramm in eine Unterroutine zu integrieren. Dies hat zwei Vorteile: ① Während des AOF-Umschreibens des untergeordneten Prozesses kann der Serverprozess (übergeordneter Prozess) weiterhin andere Befehle verarbeiten . .
Die Verwendung von untergeordneten Prozessen anstelle von Threads kann die Verwendung von Sperren vermeiden und die Datensicherheit gewährleisten, da der untergeordnete Prozess über eine Kopie der Daten des übergeordneten Prozesses verfügt.
Die Verwendung von Unterprozessen löst das oben genannte Problem, es treten jedoch auch neue Probleme auf: Da der Serverprozess während des AOF-Umschreibens des Unterprozesses noch andere Befehle verarbeitet, kann dieser neue Befehl auch die Datenbank ändern. Dadurch wird die aktuelle Datenbank geändert Der Status und der Status der neu geschriebenen AOF-Datei sind inkonsistent.
Um das Problem des inkonsistenten Datenstatus zu lösen, richtet der Redis-Server einen AOF-Rewrite-Puffer ein. Dieser Puffer wird verwendet, wenn der Redis-Server einen Schreibbefehl ausführt AOF-Rewrite-Puffer. Wenn der untergeordnete Prozess das AOF-Umschreiben abschließt, sendet er ein Signal an den übergeordneten Prozess. Nachdem der übergeordnete Prozess das Signal empfangen hat, ruft er eine Funktion auf, um den Inhalt des AOF-Umschreibpuffers in die neue AOF-Datei zu schreiben.
Dadurch werden die Auswirkungen des AOF-Umschreibens auf den Server minimiert.
6. Vor- und Nachteile von AOF
① Selbst wenn die Standardsynchronisierungsfrequenz einmal pro Sekunde verwendet wird, verliert Redis nur 1 Sekunde an Daten am meisten. .
② Die AOF-Datei wird mit dem Redis-Befehlsanhängen erstellt. Selbst wenn Redis nur Befehlsfragmente in die AOF-Datei schreiben kann, ist es einfach, die AOF-Datei mit dem Redis-Check-Aof-Tool zu korrigieren.
Das Format von AOF-Dateien ist einfach zu lesen, was Benutzern eine flexiblere Verarbeitung ermöglicht. Wenn wir beispielsweise versehentlich den FLUSHALL-Befehl verwenden, können wir vor dem Neuschreiben den letzten FLUSHALL-Befehl manuell entfernen und dann AOF verwenden, um die Daten wiederherzustellen.
Nachteile:
① Bei Redis mit denselben Daten sind AOF-Dateien normalerweise größer als RDF-Dateien.
Die standardmäßige Synchronisierungsfrequenz von AOF von einmal pro Sekunde bietet eine Vielzahl von Optionen für die Synchronisierungsfrequenz, die Leistung ist jedoch immer noch hoch. Bei hoher Redis-Last bietet RDB bessere Leistungsgarantien als AOF.
③ RDB verwendet Snapshots, um die gesamten Redis-Daten beizubehalten, während AOF nur jeden ausgeführten Befehl an die AOF-Datei anhängt. Daher ist RDB theoretisch robuster als AOF. Der offiziellen Dokumentation zufolge weist AOF einige Fehler auf, die RDB nicht aufweist.
Wie sollten wir also zwischen den beiden Persistenzmethoden AOF und RDB wählen?
Wenn Sie den Verlust von Daten innerhalb eines kurzen Zeitraums tolerieren können, besteht kein Zweifel daran, dass die regelmäßige Generierung von RDB-Snapshots für die Datenbanksicherung sehr praktisch ist, und die Geschwindigkeit der RDB-Wiederherstellung von Datensätzen ist ebenfalls sehr praktisch schneller als die AOF-Wiederherstellung. Es sollte schnell sein, und die Verwendung von RDB kann auch einige versteckte Fehler von AOF vermeiden. Es wird jedoch im Allgemeinen empfohlen, einen bestimmten Persistenzmechanismus nicht allein zu verwenden, sondern beide zusammen zu verwenden. In diesem Fall wird beim Neustart von Redis zuerst die AOF-Datei geladen, um die Originaldaten wiederherzustellen, da der Datensatz unter normalen Umständen gespeichert wird in der AOF-Datei ist vollständiger als der in der RDB-Datei gespeicherte Datensatz. Möglicherweise werden Redis-Beamte in Zukunft die beiden Persistenzmethoden in einem Persistenzmodus zusammenführen.
Das obige ist der detaillierte Inhalt vonBeispielanalyse der AOF-Persistenz in Redis. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!