Methoden und Prinzipien von Redis-Persistenz-Snapshots

Die sogenannte Persistenz soll verhindern, dass unsere Daten verloren gehen, und die Daten werden normalerweise auf unserer Festplatte gespeichert. Es gibt zwei Persistenzmethoden in Redis, eine ist Snapshot-Persistenz und die andere ist AOF-Persistenz. Jede hat ihre eigenen Vor- und Nachteile. Im Projekt müssen wir die spezifische Persistenzmethode entsprechend der tatsächlichen Situation auswählen.

Empfohlen: Redis-Einführungs-Tutorial

Snapshot-Persistenz (RDB)

Es wird auch als RDB-Persistenzmethode bezeichnet durch Persistenz wird erreicht, indem Snapshots erstellt, Speicherdaten zu einem bestimmten Zeitpunkt in einer RDB-Datei gespeichert und die Daten in die Datei geladen werden, wenn der Redis-Dienst neu gestartet wird

Persistente Snapshots konfigurieren

Snapshot-Persistenz in Redis ist standardmäßig aktiviert und es gibt zugehörige Konfigurationsoptionen in der Konfigurationsdatei redis.conf

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1   #900秒内至少有1个key被更改就执行快照
save 300 10  #300内描述至少有10个key被更改就执行快照
save 60 10000  #60秒内至少有10000个key被更改就执行快照

# By default Redis will stop accepting writes if RDB snapshots are enabled
# (at least one save point) and the latest background save failed.
# This will make the user aware (in a hard way) that data is not persisting
# on disk properly, otherwise chances are that no one will notice and some
# disaster will happen.
#
# If the background saving process will start working again Redis will
# automatically allow writes again.
#
# However if you have setup your proper monitoring of the Redis server
# and persistence, you may want to disable this feature so that Redis will
# continue to work as usual even if there are problems with disk,
# permissions, and so forth.
stop-writes-on-bgsave-error yes #拍摄快照失败是否继续执行写命令

# Compress string objects using LZF when dump .rdb databases?
# For default that&#39;s set to &#39;yes&#39; as it&#39;s almost always a win.
# If you want to save some CPU in the saving child set it to &#39;no&#39; but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes #是否对快照文件进行压缩

# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
rdbchecksum yes #是否进行数据校验

# The filename where to dump the DB
dbfilename dump.rdb #快照文件存储的名称
# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the &#39;dbfilename&#39; configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir /opt/redis-5.0.3#快照文件存储的位置

Überprüfen Sie den Effekt

1. Geben Sie das Installationsverzeichnis ein und löschen Sie die Datei dump.db, falls vorhanden

2. Starten Sie Redis, fügen Sie dann ein paar Daten hinzu, schließen Sie Redis und beenden Sie

[root@root redis-5.0.3]# src/redis-cli 
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> set name aaa
OK
127.0.0.1:6379> set age 18
OK
127.0.0.1:6379> incr age
(integer) 19
127.0.0.1:6379> shutdown
not connected> exit

3. Eine dump.rdb-Datei wird in unserem Installationsverzeichnis generiert.

4. Starten Sie redis erneut und geben Sie ein, um das Original zu finden Die Daten sind immer noch vorhanden, da Redis beim Start die Daten in die Sicherungsdatei lädt.

[root@root redis-5.0.3]# src/redis-server redis.conf 
1211:C 13 Feb 2019 01:27:22.668 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1211:C 13 Feb 2019 01:27:22.668 # Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=1211, just started
1211:C 13 Feb 2019 01:27:22.668 # Configuration loaded
[root@root redis-5.0.3]# src/redis-cli 
127.0.0.1:6379> ping 
PONG
127.0.0.1:6379> get name
"aaa"
127.0.0.1:6379> get age
"19"
127.0.0.1:6379> keys *
1) "name"
2) "age"

5. Schließen und beenden

Nach dem Schließen und Beenden wird festgestellt, dass die Daten verschwunden sind

[root@root redis-5.0.3]# src/redis-server redis.conf 
1218:C 13 Feb 2019 01:29:01.336 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1218:C 13 Feb 2019 01:29:01.336 # Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=1218, just started
1218:C 13 Feb 2019 01:29:01.336 # Configuration loaded
[root@root redis-5.0.3]# src/redis-cli 
127.0.0.1:6379> ping 
PONG
127.0.0.1:6379> keys *
(empty list or set)

Prinzip der Snapshot-Persistenz

Speicherbefehl:

Während Redis ausgeführt wird, können wir explizit einen Speicherbefehl senden, um einen Snapshot zu erstellen. Der Speicherbefehl ist ein Blockierungsbefehl, d. h. wenn der Server einen Speicherbefehl empfängt, beginnt er mit der Erstellung von Snapshots. Während dieser Zeit werden keine anderen Anforderungen verarbeitet, bis die Sicherung abgeschlossen ist

bgsave-Befehl

Der bgsave-Befehl erstellt auch sofort einen Snapshot. Anders als der save-Befehl ist bgsave kein blockierender Befehl, sondern verzweigt einen Sub-Thread Dieser Unterthread ist für den Sicherungsvorgang verantwortlich. Der übergeordnete Prozess verarbeitet die Anfrage des Clients weiterhin, sodass es nicht zu einer Blockierung kommt.

127.0.0.1:6379> ping
PONG
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set name zhangsan
OK
127.0.0.1:6379> set age 20
OK
127.0.0.1:6379> bgsave
Background saving started

4. Befehl zum Herunterfahren

Wenn wir nur den Befehl herunterfahren möchten. Der Server sendet automatisch einen Speicherbefehl, um den Snapshot-Vorgang abzuschließen. Und fahren Sie den Server herunter, nachdem der Sicherungsvorgang abgeschlossen ist. Wenn unser Betrieb die vorherigen drei Situationen nicht erfüllt, gehen unsere Daten nach dem Herunterfahren des Servers nicht verloren, wenn wir ihn erneut öffnen.

5. Synchronisierungsbefehl

In einer Master-Slave-Umgebung sendet der Slave-Knoten einen Synchronisierungsbefehl, um eine Replikation zu entwickeln, wenn er die Daten des Master-Knotens synchronisieren möchte. Zu diesem Zeitpunkt sendet der Master-Knoten einen BGSAVE-Befehl, um einen neuen Thread zu forken, um den Snapshot abzuschließen, und sendet die Snapshot-Datei an den Slave-Knoten, nachdem der BGSAVE-Befehlsvorgang abgeschlossen ist, um die Datensynchronisierung des Master- und Slave-Knotens abzuschließen.

Vorteile und Nachteile

Vorteile

RDB-Dateien speichern Redis-Daten zu einem bestimmten Zeitpunkt und eignen sich für die Sicherung. Sie können einen Punkt festlegen RDB-Dateien werden rechtzeitig archiviert, sodass die Daten bei Bedarf problemlos in einer anderen Version wiederhergestellt werden können. RDB eignet sich sehr gut für die Notfallwiederherstellung. Eine einzelne Datei kann problemlos auf einen Remote-Server übertragen werden. Wenn die Datenmenge relativ groß ist, startet RDB schnell.

Nachteile

RDB kann leicht zu Datenverlust führen, wenn Redis für einige nicht ordnungsgemäß funktioniert Grund, dann Die Daten zwischen dem letzten Snapshot und dem Problem mit Redis gehen verloren.

So deaktivieren Sie die Snapshot-Persistenz

1. Kommentieren Sie alle Speicherkonfigurationen in der Konfigurationsdatei redis.conf aus. 2. Fügen Sie den Befehl eat zur letzten Speicherkonfiguration hinzu

save ""

AOF-Persistenz

Im Gegensatz zur Snapshot-Persistenz durch direktes Speichern von Redis-Schlüssel-Wert-Paardaten zeichnet die AOF-Persistenz Redis-Speicherdaten auf, indem sie von Redis ausgeführte Schreibbefehle speichert. Theoretisch können wir den Speicherstatus von Redis wiederherstellen, solange wir alle Befehle speichern, die die Redis-Speicherdaten ändern können (d. h. Schreibbefehle), basierend auf diesen gespeicherten Schreibbefehlen. AOF-Persistenz nutzt dieses Prinzip, um Datenpersistenz und Datenwiederherstellung zu erreichen

Aktivieren Sie AOF

In Redis ist aof standardmäßig deaktiviert. Wir müssen die Konfigurationsdatei ändern, um aof zu aktivieren

appendonly yes
appendfilename "appendonly.aof"
# If unsure, use "everysec".
# appendfsync always
appendfsync everysec
# appendfsync no
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

Snapshot-Persistenz deaktivieren

save ""
#save 900 1
#save 300 10
#save 60 10000

Überprüfen Sie den Dienst und starten Sie ihn neu

Durch Ausführen einer einfachen Befehlsoperation können wir sehen, dass der in der Datei append.aof gespeicherte Inhalt der von uns ausgeführte Befehl ist

Hinweise zur dauerhaften AOF-Sicherung

1.appendfsync hat drei Werte, nämlich everysec, always und no Hier empfehlen wir die Verwendung von everysec , Always is nicht empfohlen. Denn immer wird die Leistung des Servers ernsthaft beeinträchtigt. 2. Im schlimmsten Fall verliert jede Sekunde nur 1 Sekunde an Daten, und die Auswirkungen liegen in einem kontrollierbaren Bereich.

Vorteile und Nachteile

Vorteile

Die AOF-Persistenzmethode bietet eine Vielzahl von Synchronisierungsfrequenzen, selbst wenn die Standardsynchronisierungsfrequenz einmal pro Sekunde synchronisiert wird Es geht höchstens 1 Sekunde Daten verloren. Das Format von AOF-Dateien ist gut lesbar, was den Benutzern auch eine flexiblere Verarbeitungsmethode bietet. 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

Obwohl AOF mehrere Synchronisationsfrequenzen bereitstellt, bietet die Synchronisationsfrequenz einmal pro Sekunde standardmäßig auch eine höhere Leistung. Wenn die Auslastung von Redis jedoch hoch ist, bietet RDB eine bessere Leistungsgarantie 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. Theoretisch ist RDB also robuster als die AOF-Methode

Persistenz Einige Verwendungsvorschläge

1. Wenn Redis nur als Cache-Server verwendet wird, können wir keine Persistenz verwenden.

2. Unter normalen Umständen aktivieren wir beide Persistenzmethoden. Redis lädt zuerst AOF-Dateien, um Daten zu antworten. Der Vorteil von RDB ist, dass es schnell ist.

3. Im Master-Slave-Knoten dient RDB als unsere Backup-Daten und wird nur auf dem Salve (Slave-Knoten) gestartet, so dass nur diese Regel übrig bleibt (save 900 1). . Das ist es.

Verwandte Empfehlungen:

MySQL-Video-Tutorial: https://www.php.cn/course/list/51.html

Das obige ist der detaillierte Inhalt vonMethoden und Prinzipien von Redis-Persistenz-Snapshots. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!