Welche zwei Möglichkeiten gibt es für Redis, bestehen zu bleiben?

1. Einführung in Redis

REmote Dictionary Server (Redis) ist ein von Salvatore Sanfilippo geschriebenes Schlüsselwertspeichersystem.

(Lernvideo-Sharing: Redis-Video-Tutorial)

Redis ist eine Open-Source-Schlüsselwertdatenbank vom Protokolltyp, die in ANSI C-Sprache geschrieben ist, dem BSD-Protokoll entspricht, das Netzwerk unterstützt und speicherbasiert sein kann persistent. Bietet APIs in mehreren Sprachen.

Er wird oft als Datenstrukturserver bezeichnet, da Werte Typen wie String, Hash, Liste, Mengen und sortierte Mengen sein können.

Es ähnelt Memcached, die Daten können jedoch beibehalten werden und unterstützen eine Vielzahl von Datentypen. Es gibt Zeichenfolgen, verknüpfte Listen, Mengen und sortierte Mengen. Es unterstützt die Berechnung der Vereinigung, Schnittmenge und Ergänzung (Differenz) von Mengen auf der Serverseite und unterstützt außerdem eine Vielzahl von Sortierfunktionen. Daher kann Redis auch als Datenstrukturserver betrachtet werden.

Alle Daten in Redis werden im Speicher gespeichert und dann von Zeit zu Zeit asynchron auf der Festplatte gespeichert (dies wird als „semi-persistenter Modus“ bezeichnet); Sie können jede Datenänderung auch in eine Nur-Anhänge-Datei (aof) schreiben (dies ist wird als „vollständiger Persistenzmodus“ bezeichnet).

Da Redis-Daten im Speicher gespeichert werden, gehen nach dem Neustart von Redis alle Daten verloren. Daher müssen Sie die Persistenzfunktion von Redis aktivieren, um die Daten nach dem Neustart von Redis zu speichern Beginnen Sie mit „Daten von der Festplatte wiederherstellen“. Redis bietet zwei Methoden für die Persistenz: eine ist die RDB-Persistenz (das Prinzip besteht darin, die Datenbankdatensätze von Reids regelmäßig im Speicher in die RDB-Persistenz auf der Festplatte zu übertragen) und die andere ist die AOF-Persistenz (nur Datei anhängen) (das Prinzip besteht darin, Reids‘ Persistenz zu schreiben). Betriebsprotokoll an die Datei anhängen). Was ist also der Unterschied zwischen diesen beiden Persistenzmethoden und wie wählt man sie aus? Die meisten Informationen, die ich im Internet lese, stellen die Konfiguration und Verwendung dieser beiden Methoden vor, erklären jedoch nicht den Unterschied zwischen den beiden und den Anwendungsszenarien, in denen sie verwendet werden.

2. Der Unterschied zwischen den beiden

RDB-Persistenz bezieht sich auf das Schreiben des Snapshots des Datensatzes im Speicher innerhalb eines bestimmten Zeitintervalls. Der eigentliche Vorgang besteht darin, einen untergeordneten Prozess zu forken und zuerst den Datensatz zu schreiben in eine temporäre Datei Nach erfolgreichem Schreiben wird die vorherige Datei ersetzt und mithilfe der Binärkomprimierung gespeichert.

3. Vor- und Nachteile der beiden

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 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 alle Daten verloren, die noch 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.

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 Umschreibemechanismus 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. RDB ist beim Wiederherstellen großer Datensätze schneller als AOF.

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.

Das Kriterium für die Wahl zwischen beiden besteht darin, zu sehen, ob das System bereit ist, im Austausch für eine höhere Cache-Konsistenz (aof) etwas Leistung zu opfern, oder ob es bereit ist, im Austausch für eine höhere Leistung bei häufigen Schreibvorgängen kein Backup zu aktivieren . Führen Sie „save“ manuell durch. RDB hat eine letztendlich konsistentere Bedeutung.

4. Allgemeine Konfigurationen

RDB-Persistenzkonfiguration

Redis speichert den Snapshot des Datensatzes in der Datei dump.rdb. Darüber hinaus können wir 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 #At 900 seconds (15 Minuten) Danach, 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 10000 Schlüssel geändert haben, wird der Speicherabriss gelöscht.

AOF-Persistenzkonfiguration

Es gibt drei Synchronisierungsmethoden in der Redis-Konfigurationsdatei:

appendfsync immer #Die AOF-Datei wird jedes Mal geschrieben, wenn eine Datenänderung 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. Referenzmaterialien

http://blog.csdn.net/jackpk/article/details/30073097
http://www.jb51.net/article/65264.htm

Verwandte Empfehlungen: Redis-Datenbank-Tutorial

Das obige ist der detaillierte Inhalt vonWelche zwei Möglichkeiten gibt es für Redis, bestehen zu bleiben?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!