Heim >Backend-Entwicklung >C#.Net-Tutorial >Redis-Tutorial (10): Detaillierte Erklärung der Persistenz

Redis-Tutorial (10): Detaillierte Erklärung der Persistenz

黄舟
黄舟Original
2016-12-28 15:03:021324Durchsuche

1. Welche Persistenzmechanismen bietet Redis:

1). RDB-Persistenz:
Dieser Mechanismus bezieht sich auf das Schreiben eines Snapshots des Datensatzes im Speicher innerhalb eines bestimmten Zeitintervalls.
2) AOF-Persistenz:
Dieser Mechanismus zeichnet jeden vom Server verarbeiteten Schreibvorgang in Form eines Protokolls auf. Zu Beginn des Redis-Serverstarts wird die Datei gelesen, um den Neuaufbau der Datenbank sicherzustellen dass nach dem Start die Daten in der Datenbank vollständig sind.
3) Keine Persistenz:
Wir können die Persistenzfunktion des Redis-Servers durch Konfiguration deaktivieren, sodass wir Redis als erweiterte Version von Memcached behandeln können.
4) AOF und RDB gleichzeitig anwenden.

2. Vor- und Nachteile des RDB-Mechanismus:

Was sind die Vorteile von RDB?

1). Sobald diese Methode übernommen wird, enthält Ihre gesamte Redis-Datenbank nur noch eine Datei, was sich perfekt für die Dateisicherung eignet. Beispielsweise können Sie planen, die Daten der letzten 24 Stunden stündlich und auch die Daten der letzten 30 Tage jeden Tag zu archivieren. Durch eine solche Backup-Strategie können wir das System sehr einfach wiederherstellen, sobald ein katastrophaler Ausfall im System auftritt.
2) Für die Notfallwiederherstellung ist RDB eine sehr gute Wahl. Weil wir eine einzelne Datei problemlos komprimieren und dann auf andere Speichermedien übertragen können.
3). Maximieren Sie die Leistung. Wenn der Redis-Dienstprozess mit der Persistenz beginnt, muss er lediglich den untergeordneten Prozess auslagern, und dann wird der untergeordnete Prozess die Persistenzarbeit abschließen. Dadurch kann der Dienstprozess die Durchführung von E/A-Vorgängen erheblich vermeiden.
4) Im Vergleich zum AOF-Mechanismus ist die RDB-Starteffizienz höher, wenn der Datensatz groß ist.

Was sind die Nachteile von RDB?

1) Wenn Sie eine hohe Datenverfügbarkeit gewährleisten, also Datenverluste weitestgehend vermeiden möchten, ist RDB keine gute Wahl. Denn sobald das System vor der geplanten Persistenz abstürzt, gehen die Daten verloren, die nicht auf die Festplatte geschrieben werden konnten.
2) Da RDB die Datenpersistenz durch untergeordnete Fork-Prozesse unterstützt, kann es bei großen Datensätzen dazu kommen, dass der gesamte Server für Hunderte von Millisekunden oder sogar 1 Sekunde nicht mehr bedient wird.

3. Vor- und Nachteile des AOF-Mechanismus:

Was sind die Vorteile von AOF?

1). Dieser Mechanismus kann eine höhere Datensicherheit, also Datenpersistenz, bringen. Redis bietet drei Synchronisierungsstrategien: Synchronisierung jede Sekunde, Synchronisierung bei jeder Änderung und keine Synchronisierung. Tatsächlich wird auch jede zweite Synchronisierung asynchron durchgeführt, und die Effizienz ist ebenfalls sehr hoch. Der einzige Unterschied besteht darin, dass die in dieser Sekunde geänderten Daten verloren gehen, sobald das System ausfällt. Jedes Mal, wenn eine Änderung synchronisiert wird, können wir uns das als synchrone Persistenz vorstellen, das heißt, jede auftretende Datenänderung wird sofort auf der Festplatte aufgezeichnet. Es kann vorhergesagt werden, dass diese Methode die am wenigsten effiziente ist. Was keine Synchronisierung betrifft, muss ich nicht mehr sagen, ich denke, jeder kann es richtig verstehen.
2). Da dieser Mechanismus den Anhängemodus zum Schreiben von Protokolldateien verwendet, wird der vorhandene Inhalt in der Protokolldatei auch dann nicht zerstört, wenn es während des Schreibvorgangs zu einer Ausfallzeit kommt. Wenn wir bei diesem Vorgang jedoch nur die Hälfte der Daten schreiben und ein Systemabsturz auftritt, können wir vor dem nächsten Start von Redis das Tool redis-check-aof verwenden, um das Datenkonsistenzproblem zu lösen.
3) Wenn das Protokoll zu groß ist, kann Redis den Rewrite-Mechanismus automatisch aktivieren. Das heißt, Redis schreibt im Anhängemodus kontinuierlich geänderte Daten in die alte Festplattendatei. Gleichzeitig erstellt Redis auch eine neue Datei, um aufzuzeichnen, welche Änderungsbefehle in diesem Zeitraum ausgeführt wurden. Daher kann die Datensicherheit beim Umschreiben besser gewährleistet werden.
4) AOF enthält eine Protokolldatei mit einem klaren und leicht verständlichen Format zur Aufzeichnung aller Änderungsvorgänge. Tatsächlich können wir die Datenrekonstruktion auch über diese Datei durchführen.

Was sind die Nachteile von AOF?
1). Bei gleicher Anzahl an Datensätzen sind AOF-Dateien normalerweise größer als RDB-Dateien.
2) Abhängig von der Synchronisationsstrategie ist AOF in Bezug auf die Betriebseffizienz oft langsamer als RDB. Kurz gesagt, die Effizienz der Synchronisationsstrategie pro Sekunde ist relativ hoch und die Effizienz der Synchronisationsdeaktivierungsstrategie ist genauso effizient wie bei RDB.

4. Andere:

1. Snapshotting:

Standardmäßig speichert Redis den Snapshot des Datensatzes in der Datei dump.rdb. Darüber hinaus können wir auch die Häufigkeit der Redis-Server-Dump-Snapshots über die Konfigurationsdatei ändern. Nachdem wir die Datei 6379.conf geöffnet haben, suchen wir nach „save“ und können die folgenden Konfigurationsinformationen sehen:
save 900 1 #In 900 Sekunden ( 15 Minuten), wenn sich mindestens 1 Schlüssel ändert, den Speicher-Snapshot sichern.
save 300 10 #Wenn sich nach 300 Sekunden (5 Minuten) mindestens 10 Schlüssel geändert haben, löschen Sie den Speicher-Snapshot.
save 60 10000 #Wenn sich nach 60 Sekunden (1 Minute) mindestens 10.000 Schlüssel geändert haben, wird der Speicher-Snapshot gelöscht.

2. Dump-Snapshot-Mechanismus:

1).
2) Der untergeordnete Prozess schreibt die Snapshot-Daten in die temporäre RDB-Datei.
3) Wenn der untergeordnete Prozess den Datenschreibvorgang abschließt, ersetzen Sie die alte Datei durch eine temporäre Datei.

3. AOF-Datei:

Wie bereits mehrfach erwähnt, kann der Snapshot-geplante Dump-Mechanismus von RDB keine gute Datenhaltbarkeit garantieren. Wenn sich unsere Anwendung diesbezüglich wirklich Sorgen macht, können wir die Verwendung des AOF-Mechanismus in Redis in Betracht ziehen. Für den Redis-Server ist RDB der Standardmechanismus. Wenn Sie AOF verwenden müssen, müssen Sie die folgenden Einträge in der Konfigurationsdatei ändern:
Ändern Sie appendonly no in appendonly yes
Von nun an wird Redis alle ausgeführt Zeit Nach Erhalt des Datenänderungsbefehls wird dieser an die AOF-Datei angehängt. Beim nächsten Neustart von Redis müssen die Informationen in der AOF-Datei geladen werden, um die neuesten Daten in den Speicher einzubauen.

4. AOF-Konfiguration:

Es gibt drei Synchronisierungsmethoden in der Redis-Konfigurationsdatei:
appendfsync immer #Written jedes Mal, wenn eine Datenänderung in der AOF-Datei auftritt.
appendfsync everysec #Synchronize einmal pro Sekunde Diese Strategie ist die Standardstrategie von AOF.
appendfsync no #Nie synchronisieren. Effizient, aber die Daten werden nicht gespeichert.

5. So reparieren Sie beschädigte AOF-Dateien:

1).
2). Führen Sie den Befehl „redis-check-aof --fix “ aus, um die beschädigte AOF-Datei zu reparieren.
3) Starten Sie den Redis-Server mit der reparierten AOF-Datei neu.

6. Redis-Datensicherung:

In Redis können wir laufende Redis-Datendateien online durch Kopieren sichern. Dies liegt daran, dass die RDB-Datei nach der Generierung nicht mehr geändert wird. Redis speichert jedes Mal die neuesten Daten in einer temporären Datei und verwendet dann die Umbenennungsfunktion, um die temporäre Datei atomar in den ursprünglichen Datendateinamen umzubenennen. Daher können wir sagen, dass das Kopieren von Datendateien jederzeit sicher und konsistent ist. Vor diesem Hintergrund können wir die Redis-Datendateien regelmäßig sichern, indem wir einen Cron-Job erstellen und die Sicherungsdateien auf ein sicheres Festplattenmedium kopieren.

Das Obige ist der Inhalt des Redis-Tutorials (10): Detaillierte Erklärung der Persistenz Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn)!


Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn