Durch Clustering löst Redis das Problem, dass Schreibvorgänge nicht lastverteilt werden können und die Speicherkapazität durch eine einzelne Maschine begrenzt ist, wodurch eine relativ vollständige Hochverfügbarkeitslösung erreicht wird. |
|
2. Redis-Persistenzfunktion
Redis ist eine In-Memory-Datenbank und Daten werden im Speicher gespeichert, um einen dauerhaften Datenverlust nach einem abnormalen Beenden des Redis-Prozesses aufgrund von Serverausfällen zu vermeiden Aus Gründen ist eine regelmäßige Wartung erforderlich. Speichern Sie die Daten in Redis in irgendeiner Form (Daten oder Befehl) auf der Festplatte. Verwenden Sie beim nächsten Neustart von Redis die persistente Datei, um eine Datenwiederherstellung zu erreichen. Darüber hinaus können persistente Dateien für Notfallsicherungszwecke an einen Remote-Standort kopiert werden.
2. Zwei Arten der Redis-Persistenz
RDB-Persistenz Das Prinzip besteht darin, die Datenbankdatensätze von Redis regelmäßig im Speicher auf der Festplatte zu speichern. -
AOF-Persistenz (nur Datei anhängen) Das Prinzip besteht darin, das Redis-Vorgangsprotokoll anhängend in die Datei zu schreiben, ähnlich dem Binlog von MySQL. - Da die AOF-Persistenz eine bessere Echtzeitleistung aufweist, d. h. weniger Daten verloren gehen, wenn der Prozess unerwartet beendet wird, ist AOF derzeit die gängige Persistenzmethode, aber die RDB-Persistenz hat immer noch ihren Platz.
3. RDB-Persistenz
RDB-Persistenz bezieht sich auf die Erstellung eines Snapshots der Daten im aktuellen Prozess im Speicher und deren Speicherung auf der Festplatte innerhalb eines bestimmten Zeitintervalls (daher wird es auch Snapshot-Persistenz genannt) mithilfe binärer Komprimierung zum Speichern und Speichern Das Dateisuffix ist rdb; beim Neustart von Redis kann die Snapshot-Datei gelesen werden, um Daten wiederherzustellen.
3.1 Triggerbedingungen
Die Auslösung der RDB-Persistenz ist in zwei Typen unterteilt: manuelle Auslösung und automatische Auslösung.
3.1.1 Durch manuelles Auslösen sowohl des
save-Befehls als auch des bgsave-Befehls können RDB-Dateien generiert werden. Der Befehl
- save blockiert den Redis-Serverprozess, bis die RDB-Datei erstellt wird. Während der Redis-Server blockiert ist, kann der Server keine Befehlsanfragen verarbeiten.
- Der Befehl bgsave fork() einen untergeordneten Prozess. Der untergeordnete Prozess ist für die Erstellung der RDB-Datei verantwortlich, und der übergeordnete Prozess (dh der Redis-Hauptprozess) verarbeitet weiterhin Anforderungen.
- Während der Ausführung des bgsave-Befehls blockiert nur der untergeordnete Fork-Prozess den Server, während beim save-Befehl der gesamte Prozess den Server blockiert. Daher wurde save grundsätzlich aufgegeben und die Verwendung von save muss eliminiert werden im Online-Umfeld.
- 3.1.2 Automatische Auslösung
Wenn die RDB-Persistenz automatisch ausgelöst wird, wählt Redis auch „bgsave“ anstelle von „save“ für die Persistenz. 3.2 Konfigurationsmethode ausgelöst.
Zusätzlich zum Speichern von m n gibt es einige andere Situationen, die bgsave auslösen:
- Wenn im Master-Slave-Replikationsszenario der Slave-Knoten einen vollständigen Kopiervorgang durchführt, wird der Master Der Knoten führt den Befehl bgsave aus und sendet die RDB-Datei an den Slave-Knoten.
- Beim Ausführen des Shutdown-Befehls wird die RDB-Persistenz automatisch durchgeführt.
3.4 Ausführungsprozess
- Der übergeordnete Redis-Prozess bestimmt zunächst, ob er gerade den Speichervorgang ausführt, oder ob der untergeordnete Prozess von bgsave/bgrewriteaof ausgeführt wird, und der Befehl bgsave kehrt direkt zurück. Die Unterprozesse von bgsave/bgrewriteaof können nicht gleichzeitig ausgeführt werden, hauptsächlich aus Leistungsgründen. Zwei gleichzeitige Unterprozesse führen gleichzeitig eine große Anzahl von Festplattenschreibvorgängen aus, was zu schwerwiegenden Leistungsproblemen führen kann.
- Der übergeordnete Prozess führt eine Fork-Operation durch, um einen untergeordneten Prozess zu erstellen. Während dieses Prozesses ist der übergeordnete Prozess blockiert und Redis kann keine Befehle vom Client ausführen.
Nach der Verzweigung des übergeordneten Prozesses gibt der Befehl bgsave die Meldung „Hintergrundspeicherung gestartet“ zurück und blockiert den übergeordneten Prozess nicht mehr und kann auf andere Befehle reagieren.
Der untergeordnete Prozess erstellt eine RDB-Datei und generiert eine temporäre Snapshot-Datei Nach Abschluss wird der ursprüngliche Prozess gespeichert. Es gibt eine Datei zum atomaren Ersetzen. Der untergeordnete Prozess sendet ein Signal an den übergeordneten Prozess, um den Abschluss anzuzeigen, und der übergeordnete Prozess aktualisiert die Statistiken 3.5 Laden beim Start
Das Laden von RDB-Dateien wird automatisch durchgeführt, wenn der Server startet, und es gibt keine spezielle Reihenfolge. Da AOF jedoch eine höhere Priorität hat, gibt Redis dem Laden der AOF-Datei zur Wiederherstellung von Daten nur dann Priorität, wenn AOF deaktiviert ist. Die RDB-Datei wird beim Start des Redis-Servers erkannt und automatisch geladen. Der Server wird beim Laden der RDB-Datei blockiert, bis der Ladevorgang abgeschlossen ist. Wenn Redis eine RDB-Datei lädt, wird die RDB-Datei überprüft. Wenn die Datei beschädigt ist, wird ein Fehler im Protokoll gedruckt und Redis kann nicht gestartet werden. - 4. AOF-Persistenz
- RDB-Persistenz schreibt Prozessdaten in Dateien, während AOF-Persistenz jeden von Redis ausgeführten Schreib- und Löschbefehl in einer separaten Protokolldatei aufzeichnet und Abfragevorgänge nicht aufgezeichnet werden Öffnen Sie die AOF-Datei erneut, um die Daten wiederherzustellen.
- Im Vergleich zu RDB weist AOF eine bessere Echtzeitleistung auf und ist daher zu einer Mainstream-Persistenzlösung geworden.
- 4.1 AOF aktivieren
- Der Redis-Server aktiviert RDB standardmäßig und deaktiviert AOF; um AOF zu aktivieren, müssen Sie es in der Konfigurationsdatei konfigurieren
[root@localhost ~]# vim /etc/redis/6379.conf ##700行，修改，开启AOFappendonly yes##704行，指定AOF文件名称appendfilename "appendonly.aof"##796行，是否忽略最后一条可能存在问题的指令aof-load-truncated yes[root@localhost ~]# /etc/init.d/redis_6379 restartStopping ...
Redis stopped
Starting Redis server...
4.2 AusführungsprozessDa jeder Schreibbefehl von Redis dies tun muss aufgezeichnet werden, muss AOF nicht ausgelöst werden. Im Folgenden wird der Ausführungsprozess von AOF beschrieben.
Der Ausführungsprozess von AOF umfasst:
- Befehl anhängen (append): Hängen Sie den Redis-Schreibbefehl an den Puffer aof_buf an.
- Dateischreiben (schreiben) und Dateisynchronisierung (synchronisieren): Synchronisieren Sie den Inhalt in aof_buf gemäß verschiedenen Synchronisierungsstrategien Umschreiben (Umschreiben): Schreiben Sie AOF-Dateien regelmäßig neu, um eine Komprimierung zu erreichen.
- 4.2.1 Befehl anhängen (anhängen)
Redis hängt den Befehl zuerst an den Puffer an, anstatt ihn direkt in die Datei zu schreiben. Dies dient hauptsächlich dazu, zu vermeiden, dass der Befehl jedes Mal, wenn ein Schreibbefehl vorliegt, direkt auf die Festplatte geschrieben wird Dies führt dazu, dass die Festplatten-E/A als Redis-Ladeengpass bezeichnet wird.
Das Format des Befehlsanhangs ist das vom Redis-Befehl angeforderte Protokollformat. Es ist ein Nur-Text-Format und bietet die Vorteile einer guten Kompatibilität, einer guten Lesbarkeit, einer einfachen Verarbeitung, einer einfachen Bedienung und der Vermeidung von sekundärem Overhead. In der AOF-Datei handelt es sich bei den anderen, mit Ausnahme des von Redis hinzugefügten Auswahlbefehls zum Angeben der Datenbank (z. B. „Auswählen 0 zum Auswählen der Datenbank Nr. 0“), um vom Client gesendete Schreibbefehle.
4.2.2 Dateischreiben (Schreiben) und Dateisynchronisierung (Synchronisierung)
Redis bietet verschiedene Synchronisierungsdateistrategien für den AOF-Pufferbereich. Die Strategien umfassen die Schreib- und Fsync-Funktionen des Betriebssystems :
Um die Effizienz beim Schreiben von Dateien zu verbessern, speichert das Betriebssystem die Daten normalerweise vorübergehend in einem Speicherpuffer, wenn er die Schreibfunktion aufruft angegebenen Zeitlimit. Erst dann werden die Daten im Puffer tatsächlich auf die Festplatte geschrieben. Obwohl ein solcher Vorgang die Effizienz verbessert, bringt er auch Sicherheitsprobleme mit sich: Wenn der Computer herunterfährt, gehen die Daten im Speicherpuffer verloren. Daher stellt das System auch Synchronisierungsfunktionen wie fsync und fdatasync bereit, die das Betriebssystem dazu zwingen können Speichern Sie die Daten sofort im Puffer. Die Daten werden auf die Festplatte geschrieben, um die Datensicherheit zu gewährleisten.
4.2.3 Drei Synchronisationsmethoden
Die Synchronisationsdateistrategie des AOF-Cache-Bereichs verfügt über drei Synchronisationsmethoden, die durch Ändern von Zeile 729 von /etc/redis/6379.conf konfiguriert werden.
4.2.3.1 appendfsync immer
Der Befehl ruft sofort den System-fsync-Vorgang auf, um die AOF-Datei nach dem Schreiben in aof_buf zu synchronisieren. Der Thread kehrt zurück, nachdem fsync abgeschlossen ist. In diesem Fall muss jeder Schreibbefehl mit der AOF-Datei synchronisiert werden, und die Festplatten-E/A wird zu einem Leistungsengpass. Redis kann nur etwa ein paar hundert TPS-Schreibvorgänge unterstützen, was die Leistung von Redis selbst bei Verwendung eines Solid-State-Laufwerks erheblich beeinträchtigt. SSD) kann nur Zehntausende Befehle pro Sekunde verarbeiten und verkürzt die Lebensdauer der SSD erheblich.
4.2.3.2 appendfsync no
Der Befehl ruft nach dem Schreiben in aof_buf den Systemschreibvorgang auf und führt keine fsync-Synchronisierung für die AOF-Datei durch. Die Synchronisierung wird vom Betriebssystem geladen und der Synchronisierungszeitraum beträgt normalerweise 30 Sekunden. In diesem Fall kann die Dateisynchronisierungszeit nicht kontrolliert werden, und im Puffer sammeln sich viele Daten an, und die Datensicherheit kann nicht garantiert werden.
4.2.3.3 appendfsync everysec (empfohlen)
Der Systemschreibvorgang wird aufgerufen, nachdem der Befehl in aof_buf geschrieben wurde. Nach Abschluss des Schreibvorgangs kehrt der Thread zurück: Der fsync-Synchronisierungsdateivorgang wird einmal pro Sekunde von einem dedizierten Thread aufgerufen. everysec ist ein Kompromiss zwischen den beiden oben genannten Strategien, ein Gleichgewicht zwischen Leistung und Datensicherheit. Es ist die Standardkonfiguration von Redis und unsere empfohlene Konfiguration.
4.2.4 Dateiumschreibung (Umschreiben)
Mit der Zeit führt der Redis-Server immer mehr Schreibbefehle aus und die AOF-Datei wird immer größer; eine zu große AOF-Datei wirkt sich nicht nur auf den normalen Betrieb aus server führt auch dazu, dass die Datenwiederherstellung zu lange dauert.
Beim Umschreiben von Dateien handelt es sich um das regelmäßige Umschreiben von AOF-Dateien, um die Größe der AOF-Dateien zu reduzieren. Es ist zu beachten, dass beim AOF-Rewriting die Daten im Redis-Prozess in Schreibbefehle umgewandelt und mit der neuen AOF-Datei synchronisiert werden. Es werden keine Lese- oder Schreibvorgänge für die alte AOF-Datei ausgeführt. Ein weiterer zu beachtender Punkt beim Umschreiben von Dateien ist: Für die AOF-Persistenz wird das Umschreiben von Dateien zwar dringend empfohlen, es ist jedoch nicht erforderlich, dass Daten beim Importieren in Redis gespeichert und gestartet werden wird deaktiviert und die geplante Aufgabe wird dann regelmäßig jeden Tag zu einer bestimmten Zeit ausgeführt.
4.2.4.1 Gründe für die Komprimierungsfunktion
Der Grund, warum File Rewrite AOF-Dateien komprimieren kann, ist folgender:
Abgelaufene Daten werden nicht mehr in die Datei geschrieben.
- Ungültige Befehle werden nicht mehr in die Datei geschrieben: z. B. das wiederholte Festlegen einiger Daten (set mykey v1, set mykey v2), das Löschen einiger Daten (set myset v1, del myset) usw.
- Mehrere Befehle können zu einem zusammengeführt werden: z. B. sadd myset v1, sadd myset v2, sadd myset v3 können zu sadd myset v1 v2 v3 zusammengeführt werden.
- Aus den oben genannten Gründen ist ersichtlich, dass das Umschreiben von Dateien nicht nur den von der Datei belegten Speicherplatz reduzieren, sondern auch die Wiederherstellung beschleunigen kann, da AOF nach dem Umschreiben weniger Befehle ausführt.
4.2.4.2 Auslösen des Umschreibens von Dateien
Das Umschreiben von Dateien ist in manuelles Auslösen und automatisches Auslösen unterteilt:
- Manuelle Auslösung: Rufen Sie den Befehl bfrewriteaof direkt auf. Die Ausführung dieses Befehls ähnelt in gewisser Weise der von bgsave. Beide Fork-Prozesse führen bestimmte Arbeiten aus und blockieren nur beim Forken.
- Automatische Auslösung: Führen Sie bgrewriteaof automatisch aus, indem Sie die Optionen „auto-aof-rewrite-min-size“ und „auto-aof-rewrite-percentage“ festlegen. Nur wenn die beiden Optionen auto-aof-rewrite-min-size und auto-aof-rewrite-percentage gleichzeitig erfüllt sind, wird das AOF-Umschreiben, also der bgrewriteaof-Vorgang, automatisch ausgelöst.
Die automatisch ausgelöste Konfiguration befindet sich in den Zeilen 771 und 772 von /etc/redis/6379.conf自动触发的配置位于/etc/redis/6379.conf的771行和772行
- auto-aof-rewrite-percentage 100
当前AOF文件大小（即aof_current_size）是上次日志重写时AOF文件大小（aof_base_size）两倍时，发生bgrewriteaof操作
- auto-aof-rewrite-min-size 64mb
当前AOF文件执行bgrewriteaof命令的最小值，避免刚开始启动Redis时由于文件尺寸较小导致频繁的bgrewriteaof
4.2.4.3 文件重写的流程
文件重写的流程如下：
- Redis父进程首先平判断当前是否存在正在执行bgsave/bgrewriteaof的子进程；如果存在则bgrewriteaof命令直接返回，如果存在bgsave命令则等bgsave执行完成后再执行。
- 父进程执行fork操作创建子进程，这个过程中父进程是阻塞的。
- 父进程fork后，bgrewriteaof命令返回“Background append only file rewrite started”信息并不再阻塞父进程，并可以响应其他命令。Redis的所有写命令依然写入AOF缓冲区，并根据appendfsync策略同步到硬盘，保证原有AOF机制的正确。
- 由于fork操作使用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然在响应命令，因此Redis使用AOF重写缓冲区（aof_rewrite_buf）保存这部分数据，防止新AOF文件生成期间丢失这部分数据。也就是说，bgrewriteaof执行期间，Redis的写命令同时追加到aof_buf和aof_rewrite_buf两个缓冲区。
- 子进程根据内存快照，按照命令合并规则写入到新的AOF文件。
- 子进程写完新的AOF文件后，向父进程发信号，父进程更新统计信息，具体可以通过info persistence查看。
- 父进程把AOF重写缓冲区的数据写入到新的AOF文件，这样就保证了新AOF文件所保存的数据库状态和服务器当前状态一致。
- 使用新的AOF文件替换老文件，文成AOF重写。
关于文件重写的流程，有两点需要特别注意：
auto-aof-rewrite-percentage 100- Die aktuelle AOF-Dateigröße (d. h. aof_current_size ) ist: Wenn sich die AOF-Dateigröße (aof_base_size) während des letzten Protokollumschreibens verdoppelt hat, ist der bgrewriteaof-Vorgang aufgetreten Dateifehler beim Starten von Redis. Kleine Größe führt zu häufigem bgrewriteaof
4.2.4.3 Dateiumschreibungsprozess
Der Prozess des Dateiumschreibens ist wie folgt:
Der übergeordnete Redis-Prozess ermittelt zunächst, ob es einen untergeordneten Prozess gibt, der derzeit bgsave/bgrewriteaof ausführt; Wenn es existiert, bgrewriteaof Der Befehl kehrt direkt zurück. Wenn ein bgsave-Befehl vorhanden ist, wird er ausgeführt, nachdem die bgsave-Ausführung abgeschlossen ist. - Der übergeordnete Prozess führt eine Fork-Operation durch, um einen untergeordneten Prozess zu erstellen. Während dieses Prozesses ist der übergeordnete Prozess blockiert.
- Nach der Verzweigung des übergeordneten Prozesses gibt der Befehl bgrewriteaof die Meldung „Nur Datei-Rewrite im Hintergrund anhängen“ zurück und blockiert den übergeordneten Prozess nicht mehr und kann auf andere Befehle reagieren. Alle Schreibbefehle von Redis werden weiterhin in den AOF-Puffer geschrieben und gemäß der appendfsync-Richtlinie mit der Festplatte synchronisiert, um die Richtigkeit des ursprünglichen AOF-Mechanismus sicherzustellen.
- Da der Fork-Vorgang die Copy-on-Write-Technologie verwendet, kann der untergeordnete Prozess die Speicherdaten nur während des Fork-Vorgangs gemeinsam nutzen. Da der übergeordnete Prozess immer noch auf den Befehl reagiert, verwendet Redis den AOF-Rewrite-Puffer (aof_rewrite_buf), um diesen Teil der Daten zu speichern und zu verhindern, dass dieser Teil der Daten während der Generierung der neuen AOF-Datei verloren geht. Mit anderen Worten: Während der Ausführung von bgrewriteaof wird der Schreibbefehl von Redis gleichzeitig an die Puffer aof_buf und aof_rewrite_buf angehängt.
Der untergeordnete Prozess schreibt gemäß dem Speicher-Snapshot und den Befehlszusammenführungsregeln in die neue AOF-Datei.
Nachdem der untergeordnete Prozess das Schreiben der neuen AOF-Datei abgeschlossen hat, sendet er ein Signal an den übergeordneten Prozess und der übergeordnete Prozess aktualisiert die statistischen Informationen, die über die Informationspersistenz angezeigt werden können. Der übergeordnete Prozess schreibt die Daten im AOF-Rewrite-Puffer in die neue AOF-Datei und stellt so sicher, dass der in der neuen AOF-Datei gespeicherte Datenbankstatus mit dem aktuellen Status des Servers übereinstimmt.
Ersetzen Sie die alte Datei durch die neue AOF-Datei und schreiben Sie sie in AOF um.
In Bezug auf den Prozess des Umschreibens von Dateien gibt es zwei Punkte, die besondere Aufmerksamkeit erfordern:
Das Umschreiben wird dadurch durchgeführt, dass der übergeordnete Prozess den untergeordneten Prozess verzweigt.
Der Schreibbefehl wird von Redis während des Umschreibens ausgeführt muss angehängt werden. In der neuen AOF-Datei führt Redis zu diesem Zweck den aof_rewrite_buf-Cache ein kann nur geladen werden, wenn AOF deaktiviert ist. Geben Sie die RDB-Datei ein, um Daten wiederherzustellen.
Wenn AOF aktiviert ist, die AOF-Datei jedoch nicht vorhanden ist, wird die RDB-Datei nicht geladen, selbst wenn sie vorhanden ist.
Wenn Redis eine AOF-Datei lädt, wird die AOF-Datei überprüft. Wenn die Datei beschädigt ist, wird ein Fehler im Protokoll gedruckt und Redis kann nicht gestartet werden. Wenn jedoch das Ende der AOF-Datei unvollständig ist (ein plötzlicher Maschinenausfall kann leicht dazu führen, dass das Ende der Datei unvollständig ist) und der Parameter aof_load_truncated aktiviert ist, wird eine Warnung im Protokoll ausgegeben und von Redis ignoriert das Ende der AOF-Datei und startet erfolgreich. Der Parameter aof_load_truncated ist standardmäßig aktiviert.
🎜🎜5. Vor- und Nachteile von RDB und AOF🎜🎜🎜RDB-Persistenz🎜🎜🎜Vorteile: RDB-Dateien sind kompakt, klein, schnell in der Netzwerkübertragung und für die vollständige Wiederherstellung geeignet; die Geschwindigkeit ist viel schneller als bei AOF. Einer der wichtigsten Vorteile von RDB besteht natürlich darin, dass es im Vergleich zu AOF einen relativ geringen Einfluss auf die Leistung hat. 🎜 Nachteile: Der bekannte Nachteil von RDB-Dateien besteht darin, dass die Persistenzmethode von Daten-Snapshots dazu führt, dass eine Echtzeit-Persistenz nicht erreicht werden kann. Heutzutage, wenn Daten immer wichtiger werden, ist ein großer Datenverlust oft inakzeptabel. So wird die AOF-Persistenz zum Mainstream. Darüber hinaus müssen RDB-Dateien einem bestimmten Format entsprechen und eine schlechte Kompatibilität aufweisen (z. B. ist die alte Version von Redis nicht mit der neuen Version von RDB-Dateien kompatibel). 🎜 Für die RDB-Persistenz wird einerseits der Redis-Hauptprozess blockiert, wenn bgsave einen Fork-Vorgang ausführt. Andererseits führt das Schreiben von Daten auf die Festplatte durch den Unterprozess auch zu E/A-Druck. 🎜🎜🎜AOF-Persistenz🎜🎜🎜Entsprechend der RDB-Persistenz liegt die Priorität von AOF in der Unterstützung der Persistenz der zweiten Ebene und einer guten Kompatibilität. Die Nachteile sind große Dateien, langsame Wiederherstellungsgeschwindigkeit und große Auswirkungen auf die Leistung. 🎜🎜Für die AOF-Persistenz wird die Häufigkeit des Schreibens von Daten auf die Festplatte erheblich erhöht (zweite Ebene unter der Everysec-Richtlinie), der E/A-Druck ist größer und es kann sogar zu zusätzlichen Blockierungsproblemen im AOF kommen. 🎜🎜Das Umschreiben von AOF-Dateien ähnelt dem bgsave von RDB, und es wird Probleme mit der Blockierung während der Verzweigung und dem E/A-Druck auf untergeordnete Prozesse geben. Da AOF häufiger Daten auf die Festplatte schreibt, hat dies relativ gesehen einen größeren Einfluss auf die Leistung des Redis-Hauptprozesses. 🎜Im Allgemeinen wird empfohlen, die automatische Neuschreibfunktion von AOF zu deaktivieren, eine geplante Aufgabe für den Neuschreibvorgang festzulegen und diese am frühen Morgen bei geringem Geschäftsvolumen auszuführen, um die Auswirkungen von AOF zu verringern die Leistung des Hauptprozesses und der Lese- und Schreibdruck von IO.
Weitere Kenntnisse zum Thema Programmierung finden Sie unter: Einführung in die Programmierung! !
