Wie Redis die Persistenzlösung implementiert (von RDB und AOF verwendet)

1. Die Rolle der Persistenz

1. Was ist Persistenz

Alle von redis gespeicherten Daten Speicher, Aktualisierungen der Daten werden asynchron auf der Festplatte gespeichert

2. So implementieren Sie Persistenz

Snapshot: eine Vervollständigung der Daten zu einem bestimmten Zeitpunkt Backup – Dump von MySQL – RDB-Schreibprotokoll von Redis: Um die Daten wiederherzustellen, gehen Sie einfach noch einmal das Protokoll durch – Binlog von MySQL – HLog von Hhase – AOF von Redis

2. RDB

1. Was ist RDB

2 - Hauptsächlich drei Methoden

Die erste: Speichern (Synchronisation)

1 Der Client gibt den Speicherbefehl ein ----"redis server----"Synchronisierte Erstellung der RDB-Binärdatei Datei

2 führt zu einer Redis-Blockierung (wenn die Datenmenge sehr groß ist)

3 Dateistrategie: Wenn die alte RDB vorhanden ist, ersetzt sie die alte

4 Komplexität o(n)

Zweiter Typ: bgsave (asynchron, Hintergrundspeicherung gestartet)

1 Der Client gibt den Speicherbefehl ein----"redis server----"asynchronous Create eine RDB-Binärdatei (die Fork-Funktion generiert einen untergeordneten Prozess (Fork blockiert Reids), führt createRDB aus, wenn die Ausführung erfolgreich ist, kehrt zur Reids-Nachricht zurück)

2 Wenn zu diesem Zeitpunkt auf Redis zugegriffen wird, wird der Client dies tun reagiere normal

3 Dateistrategie: Gleich wie beim Speichern, wenn die alte RDB vorhanden ist, wird sie die alte ersetzen

4 Komplexität o(n)

Die dritte Methode: (allgemeine Methode) (** ****) Automatisch (über Konfigurationsdatei)
Konfigurationssekundenänderungen
speichern 900 1speichern 300 10speichern 60 10000 Wenn 1w Datenelemente in 60s geändert werden, wird automatisch RDB generiert
Wenn 10 Daten in 300 Sekunden geändert werden, wird automatisch eine RDB generiert.
Wenn 1 Daten in 900 Sekunden geändert wird, wird automatisch eine RDB generiert.

Wenn eine der oben genannten drei Bedingungen erfüllt ist, wird die RDB automatisch generiert wird automatisch generiert und verwendet intern bgsave

#Konfiguration:

900 speichern 1 #Eins konfigurieren

300 speichern 10 #Eins konfigurieren

save 60 10000 #Konfigurieren Sie einen

dbfilename dump.rdb #Der Name der RDB-Datei, der Standardwert ist dump.rdb

dir ./ #Die rdb-Datei existiert im aktuellen Verzeichnis

stop-writes-on-bgsave-error ja #Wenn in bgsave ein Fehler auftritt, ob das Schreiben gestoppt werden soll, ist die Standardeinstellung ja

rdbcompression ja #Komprimierungsformat verwenden

rdbchecksum ja #Ob die RDB-Datei überprüft werden soll

#Beste Konfiguration

900 speichern 1

300 speichern 10

60 speichern 10000 dbfilename dump-${port}.rdb

#Mit port Als Dateiname können auf einem Rechner viele Reids vorhanden sein, sodass es nicht zu Verwirrung kommt /bigdiskpath #Legen Sie den Speicherpfad in ein großes Festplattenspeicherverzeichnis

stop-writes-on-bgsave-error ja

# Stoppen, wenn ein Fehler auftritt

rdbcompression ja #Komprimierung

rdbchecksum ja #Überprüfung

Der RDB-Triggermechanismus verwendet im Allgemeinen die erste. Es gibt drei Möglichkeiten, aber diese Methode weist auch Mängel auf. Wenn die Anzahl der geänderten Elemente nicht innerhalb des Einstellungsbereichs liegt, wird sie nicht ausgelöst, was dazu führt, dass viele Daten nicht beibehalten werden. Daher verwenden wir im Allgemeinen die folgende Methode: AOF.

Wenn Sie unwichtige Daten speichern möchten, können Sie RDB verwenden (z. B. Cache-Daten). Wenn Sie sehr wichtige Daten speichern möchten, sollten Sie AOF verwenden, es können jedoch auch beide Methoden verwendet werden zur gleichen Zeit.

3. AOF

1. RDB-Problem

Zeitaufwändig und leistungsintensiv. Unkontrollierbar, Daten können verloren gehen.

2. AOF-Einführung

Jedes Mal, wenn ein Befehl vom Client geschrieben wird, wird ein Protokoll aufgezeichnet und in der Protokolldatei abgelegt vollständig wiederhergestellt

Drei Strategien von AOF

Das Protokoll wird nicht direkt auf die Festplatte geschrieben, sondern zunächst in den Puffer geschrieben nach einigen Strategien

#Der erste Typ: immer: redis--》Befehlsaktualisierungspuffer schreiben---》Fsync jeden Befehl auf der Festplatte---》AOF-Datei

#Die zweiter Typ: everysec (Standardwert): redis——》Schreiben Sie den durch den Befehl aktualisierten Puffer---》fsyncen Sie den Puffer jede Sekunde auf die Festplatte--》AOF-Datei

#Der dritte Typ: nein :redis——》Schreiben Sie den Aktualisierungsbefehl Buffer ---》Vom Betriebssystem festgelegt, fsyncen Sie den Puffer auf die Festplatte--》AOF-Datei

命令	always	everysec	no
优点	不丢失数据	每秒一次fsync，丢失1秒数据	不用管
缺点	IO开销大，一般的sata盘只有几百TPS	丢1秒数据	不可控

4. AOF-Umschreiben

Wenn Befehle nach und nach geschrieben werden und der Grad der Parallelität zunimmt, wird die AOF-Datei immer größer. Dieses Problem kann durch AOF-Umschreiben gelöst werden

原生AOF	AOF重写
set hello world set hello java set hello hehe incr counter ncr counter rpush mylist a rpush mylist b rpush mylist c 过期数据	set hello hehe set counter 2 rpush mylist a b c

Native AOF

AOF rewrite

set hello world

set hello java

set Hallo hehe

incr counter

ncr counter

rpush mylist a

rpush mylist b

rpush mylist c

Abgelaufene Daten

Hallo hehe setzen
Zähler 2 setzen

rpush mylist a b c

命令	rdb	aof
启动优先级	低	高(挂掉重启，会加载aof的数据)
体积	小	大
恢复速度	快	慢
数据安全性	丢数据	根据策略决定
轻重	重	轻

Das Wesentliche besteht darin, abgelaufene, nutzlose, wiederholte Befehle zu platzieren, die optimiert werden können, und diese zu optimieren, um sie zu reduzieren Festplattennutzung und Beschleunigung der Wiederherstellung Implementierungsmethodebgrewriteaof: Der Client sendet den Befehl bgrewriteaof an den Server und der Server startet einen Fork-Prozess, um das AOF-Rewrite abzuschließen AOF-Rewrite-Konfiguration: Rewrite-Prozess AOF-Konfigurationsdatei (*** ***)appendonly ja #Setzen Sie diese Option auf „Ja, öffnen Sie appendfilename „appendonly-${port}.aof“ #Der Name der gespeicherten Datei appendfsync everysec #Übernehmen Sie die zweite Strategie dir /bigdiskpath #Storage Der Pfad no-appendfsync- on-rewrite ja #Ob beim Neuschreiben von aof der Anhängevorgang von aof durchgeführt werden soll, da das erneute Schreiben von aof Leistung und Festplattenverbrauch verbraucht. Beim normalen Schreiben von aof auf die Festplatte treten bestimmte Konflikte auf, sodass die Daten während dieses Zeitraums verloren gehen können 4. Auswahl von RDB und AOF1. Vergleich von rdb und aof大

Befehl	rdb	aof
Startpriorität td>	Niedrig	Hoch (wenn Sie auflegen und neu starten, werden die AOF-Daten geladen)
Größe	Klein
Erholungsgeschwindigkeit	Schnell	Langsam
Datensicherheit	Verlorene Daten	Entschieden nach Strategie
Schweregrad	Schwer	Leicht

2.rdb beste Strategie

Rdb ist ausgeschaltet, Master-Slave-Betrieb wird verwendet
Zentralisierte Verwaltung: Datensicherung nach Tag, stündlich
Master-Slave-Konfiguration, Slave-Knoten ist eingeschaltet

3.aof beste Strategie

Ein: Cache und Speicher, in den meisten Fällen geöffnet,
aof zentralisierte Verwaltung neu schreiben
jede Sekunde: Strategie wird jede Sekunde aktualisiert

4. Beste Strategie

Kleines Sharding: Der maximale Speicher jedes Redis beträgt 4g
Cache oder Speicher: Je nach Eigenschaften unterschiedliche Strategien verwenden
Überwachen Sie die Festplatte jederzeit , Speicher, Netzwerk laden usw.
Genug Speicher vorhanden

Das Obige ist der gesamte Inhalt von Redis (4) – Persistenzlösung (von RDB und AOF verwendet).

Verwandte Referenzen: PHP chinesische Website

Das obige ist der detaillierte Inhalt vonWie Redis die Persistenzlösung implementiert (von RDB und AOF verwendet). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!