Redis-Protokoll: Tipps für eine schnelle Wiederherstellung

"

Es ist richtig, unabhängig zu sein, und es ist richtig, sich in den Kreis zu integrieren. Der entscheidende Punkt ist, herauszufinden, welche Art von Leben Sie wollen und welchen Preis Sie bereit sind, dafür zu zahlen.

„

Wir beziehen uns normalerweise auf Redis. Verwenden Sie es als Cache, um die Leseantwortleistung zu verbessern. Sobald Redis ausfällt, gehen alle Daten im Speicher verloren. Wenn Sie direkt auf die Datenbank zugreifen und eine große Menge Datenverkehr auf MySQL trifft, kann dies passieren schwerwiegendere Probleme verursachen.

Darüber hinaus ist die Leistung beim langsamen Lesen aus der Datenbank in Redis zwangsläufig schneller als beim Abrufen von Redis, was ebenfalls zu einer langsameren Reaktion führt.

Um eine schnelle Wiederherstellung ohne Angst vor Ausfallzeiten zu erreichen, hat Redis zwei wichtige Killerfunktionen entwickelt, nämlich AOF-Protokolle (Append Only FIle) und RDB-Snapshots.

Beim Erlernen einer Technologie kommt man meist nur mit vereinzelten technischen Punkten in Berührung, ohne ein vollständiges Wissensgerüst und Architektursystem im Kopf zu etablieren und ohne eine systematische Sichtweise. Das wird sehr schwierig sein, und auf den ersten Blick sieht es so aus, als ob Sie es schaffen könnten, aber dann werden Sie es vergessen und verwirrt sein.

Lassen Sie uns gemeinsam Redis gründlich lernen und die Kernprinzipien und praktischen Fähigkeiten von Redis gründlich beherrschen. Erstellen Sie ein vollständiges Wissensgerüst und lernen Sie, das gesamte Wissenssystem aus einer globalen Perspektive zu organisieren.

Dieser Artikel ist Hardcore. Ich empfehle Ihnen, ihn zu speichern, ihn zu liken, sich zu beruhigen und ihn zu lesen. Ich glaube, Sie werden viel gewinnen.

Der vorherige Artikel analysierte die Kerndatenstruktur, das IO-Modell und das Thread-Modell von Redis und verwendete die entsprechende Datenkodierung entsprechend verschiedenen Daten. Verstehen Sie genau, warum es wirklich schnell ist!

Empfohlen (kostenlos): redis

Dieser Artikel konzentriert sich auf die folgenden Punkte:

• Wie kann man sich nach einer Ausfallzeit schnell erholen?

• ist ausgefallen, wie vermeidet Redis Datenverlust?

• Was ist ein RDB-Speicher-Snapshot?

• AOF-Protokollimplementierungsmechanismus

• Was ist Copy-on-Write-Technologie? Die beteiligten Wissenspunkte sind in der Abbildung dargestellt: Etwa zwei In drei Dimensionen erweitert sind dies:

Anwendungsdimension: Cache-Nutzung, Cluster-Nutzung, clevere Nutzung von Datenstrukturen

• Systemdimension: kann in drei Höhen eingeteilt werden

Hohe Leistung: Thread-Modell, Netzwerk-IO-Modell , Datenstruktur, Persistenzmechanismus;

Hohe Verfügbarkeit: Master-Slave-Replikation, Sentinel-Cluster, Cluster-Sharding-Cluster;

Hohe Skalierbarkeit: Lastausgleich

Die Kapitel der Redis-Serie drehen sich um die folgende Mindmap: Lassen Sie uns gemeinsam Redis erkunden. Das Geheimnis leistungsstarker, langlebiger Mechanismen.

Verstehen Sie Redis gründlich.

1. Verschaffen Sie sich einen Panoramablick und beherrschen Sie die Systemansicht.

Die Systemsicht ist tatsächlich bis zu einem gewissen Grad entscheidend, wenn man Probleme löst. Die Systemsicht bedeutet, dass man Probleme anhand und auf organisierte Weise lokalisieren und lösen kann.

2. RDB-Speicher-Snapshot, der eine schnelle Wiederherstellung nach Ausfallzeiten ermöglicht

3. "

   65 Brother: Redis ist aus bestimmten Gründen ausgefallen, was dazu führt, dass der gesamte Datenverkehr auf das Backend MySQL trifft. Ich habe Redis sofort neu gestartet, aber seine Daten werden darin gespeichert Der Speicher ist leer, aber nach dem Neustart sind immer noch keine Daten vorhanden.
"

65 Keine Sorge, „Code Byte“ zeigt Ihnen Schritt für Schritt, wie Sie nach einem Redis-Absturz schnell wiederherstellen können.

Redis-Daten werden im Speicher gespeichert. Ist es möglich, die Daten im Speicher auf die Festplatte zu schreiben? Beim Neustart von Redis werden die auf der Festplatte gespeicherten Daten schnell im Speicher wiederhergestellt, sodass nach dem Neustart normale Dienste bereitgestellt werden können.

"

65 Bruder: Ich habe mir eine Lösung überlegt. Jedes Mal, wenn ein „Schreibvorgang“ zum Betreiben des Speichers ausgeführt wird, wird dieser gleichzeitig auf die Festplatte geschrieben

"

Diese Lösung hat ein schwerwiegendes Problem: jedes Schreiben Die Anweisung schreibt nicht nur in den Speicher, sondern auch auf die Festplatte. Die Leistung der Festplatte ist im Vergleich zum Speicher zu langsam, was dazu führt, dass die Leistung von Redis stark beeinträchtigt wird : Wie vermeide ich dieses Problem beim gleichzeitigen Schreiben?

"

Wir verwenden Redis normalerweise als Cache. Selbst wenn Redis nicht alle Daten speichert, können sie dennoch über die Datenbank abgerufen werden, sodass Redis nicht alle Daten speichert. Die Datenpersistenz von Redis verwendet den „RDB-Daten-Snapshot“. "Methode Um eine schnelle Wiederherstellung nach Ausfallzeiten zu erreichen. "

65 Bruder: Was ist also ein RDB-Speicher-Snapshot?

"

Während Redis den Befehl „Schreiben“ ausführt, ändern sich die Speicherdaten weiterhin. Der sogenannte Speicher-Snapshot bezieht sich auf die Statusdaten der Daten im Redis-Speicher zu einem bestimmten Zeitpunkt.

Es ist, als ob die Zeit in einem bestimmten Moment eingefroren ist. Wenn wir Fotos machen, können wir den Moment in einem bestimmten Moment vollständig durch Fotos festhalten.

Redis ähnelt dem, es nimmt die Daten zu einem bestimmten Zeitpunkt in Form einer Datei und schreibt sie auf die Festplatte. Diese Snapshot-Datei wird als RDB-Datei bezeichnet, und RDB ist die Abkürzung für Redis DataBase.

Redis führt regelmäßig RDB-Speicher-Snapshots aus, sodass nicht jedes Mal, wenn der Befehl „Schreiben“ ausgeführt wird, auf die Festplatte geschrieben werden muss. Es muss nur auf die Festplatte geschrieben werden, wenn der Speicher-Snapshot ausgeführt wird. Es stellt nicht nur sicher, dass es schnell ist, aber nicht kaputt geht, es erreicht auch Haltbarkeit und kann sich schnell nach Ausfallzeiten erholen.

RDB-Speicher-Snapshot

Bei der Datenwiederherstellung wird die RDB-Datei direkt in den Speicher eingelesen, um die Wiederherstellung abzuschließen.

"

65 Bruder: Welche Daten sollten erfasst werden? Oder wie oft sollte ein Schnappschuss erstellt werden? Dies wirkt sich auf die Ausführungseffizienz des Schnappschusses aus.

"

65 Bruder, ich fange an, über Dateneffizienz nachzudenken Probleme. In „Redis Core: Das schnellste und unzerbrechliche Geheimnis“ wissen wir, dass sein Single-Thread-Modell bestimmt, dass wir unser Bestes geben sollten, um Vorgänge zu vermeiden, die den Haupt-Thread blockieren, und zu verhindern, dass die RDB-Dateigenerierung den Haupt-Thread blockiert.

RDB-Strategie generieren

Redis bietet zwei Anweisungen zum Generieren von RDB-Dateien:

• Speichern: wird vom Hauptthread ausgeführt und blockiert

• bgsave: ruft die Glibc-Funktion fork auf; Code> Erzeugt einen untergeordneten Prozess zum Schreiben von RDB-Dateien. Die Snapshot-Persistenz wird vollständig vom untergeordneten Prozess verwaltet. Der übergeordnete Prozess verarbeitet weiterhin Clientanforderungen und generiert die Standardkonfiguration von RDB-Dateien. <code>fork产生一个子进程用于写入 RDB 文件，快照持久化完全交给子进程来处理，父进程继续处理客户端请求，生成 RDB 文件的默认配置。

“

65 哥：那在对内存数据做「快照」的时候，内存数据还能修改么？也就是写指令能否正常处理？

”

首先我们要明确一点，避免阻塞和 RDB 文件生成期间能处理写操作不是一回事。虽然主线程没有阻塞，到那时为了保证快照的数据的一致性，只能处理读操作，不能修改正在执行快照的数据。

很明显，为了生成 RDB 而暂停写操作，Redis 是不答应的。

“

65 哥：那 Redis 如何实现一边处理写请求，同时生成 RDB 文件呢？

”

Redis 使用操作系统的多进程写时复制技术 COW(Copy On Write) 来实现快照持久化，这个机制很有意思，也很少人知道。多进程 COW 也是鉴定程序员知识广度的一个重要指标。

Redis 在持久化时会调用 glibc 的函数fork产生一个子进程，快照持久化完全交给子进程来处理，父进程继续处理客户端请求。

子进程刚刚产生时，它和父进程共享内存里面的代码段和数据段。这时你可以将父子进程想像成一个连体婴儿，共享身体。

这是 Linux 操作系统的机制，为了节约内存资源，所以尽可能让它们共享起来。在进程分离的一瞬间，内存的增长几乎没有明显变化。

bgsave 子进程可以共享主线程的所有内存数据，读取主线程的数据并写入到 RDB 文件。

在执行 SAVE 命令或者BGSAVE命令创建一个新的 RDB 文件时，程序会对数据库中的键进行检查，已过期的键不会被保存到新创建的 RDB 文件中。

当主线程执行写指令修改数据的时候，这个数据就会复制一份副本， bgsave

"65 Brother: Können die Speicherdaten beim Erstellen eines „Schnappschusses“ der Speicherdaten noch geändert werden? Das heißt, kann der Schreibbefehl normal verarbeitet werden?

“

Zunächst müssen wir klarstellen, dass das Vermeiden von Blockierungen und die Fähigkeit, Schreibvorgänge während der RDB-Dateigenerierung zu verarbeiten, nicht dasselbe sind, obwohl der Hauptthread zu diesem Zeitpunkt nicht blockiert ist, um dies sicherzustellen Aufgrund der Konsistenz der Snapshot-Daten können nur Lesevorgänge verarbeitet werden

Natürlich erlaubt Redis nicht, Schreibvorgänge anzuhalten, um RDB zu generieren

"

65 Brother: Wie Kann Redis gleichzeitig Schreibanfragen verarbeiten und RDB-Dateien generieren?

“

Redis nutzt die Multiprozess-Copy-on-Write-Technologie COW (Copy On Write), um Snapshot-Persistenz zu erreichen, und nur wenige Menschen wissen, dass Multiprozess-COW ein wichtiger Faktor ist

Redis ruft die Glibc-Funktion fork auf, um einen untergeordneten Prozess zu generieren. Die Snapshot-Persistenz wird vollständig vom untergeordneten Prozess verwaltet Wenn die Client-Anfrage zum ersten Mal generiert wird, teilt sie das Codesegment und das Datensegment im Speicher mit dem übergeordneten Prozess. Zu diesem Zeitpunkt können Sie sich die übergeordneten und untergeordneten Prozesse als siamesische Babys vorstellen Der Mechanismus des Linux-Betriebssystems, also versuchen Sie, sie so weit wie möglich zu teilen, wenn der Prozess getrennt ist, gibt es fast keine offensichtliche Änderung im Speicherwachstum bgsave Der untergeordnete Prozess kann alle Speicherdaten des Hauptthreads teilen und die Daten des Hauptthreads lesen und in die RDB-Datei schreiben

1. Beim Ausführen des Befehls SAVE Mit dem Befehl BGSAVE prüft das Programm, ob der Schlüssel in der Datenbank abgelaufen ist. Die Schlüssel werden nicht in der neu erstellten RDB-Datei gespeichert Mit dem Schreibbefehl zum Ändern der Daten wird eine Kopie der Daten erstellt und der untergeordnete Prozess bgsave liest die kopierten Daten in die RDB-Datei, sodass der Hauptthread das Original direkt ändern kann Daten.

2. Die Copy-on-Write-Technologie stellt sicher, dass die Daten während des Snapshots geändert werden. Dadurch wird nicht nur die Integrität des Snapshots sichergestellt, sondern es wird auch ermöglicht, dass der Hauptthread Änderungen an den Daten vermeidet Auswirkungen auf das normale Geschäft.

Redis verwendet bgsave, um einen Snapshot aller Daten im aktuellen Speicher zu erstellen, der es dem Hauptthread ermöglicht, die Daten gleichzeitig zu ändern

"

65 Brother: Kann die RDB-Datei jede Sekunde ausgeführt werden? Auf diese Weise gehen selbst bei einer Ausfallzeit bis zu 1 Sekunde Daten verloren.

"

Das zu häufige Ausführen vollständiger Daten-Snapshots hat zwei schwerwiegende Leistungseinbußen zur Folge:

Generieren Sie häufig RDB-Dateien und schreiben Sie sie auf die Festplatte, was zu einer übermäßigen Belastung der Festplatte führt. Es scheint, dass die vorherige RDB noch nicht ausgeführt wurde. und der nächste wird gestartet und fällt in eine Endlosschleife. Je größer der Speicher des Hauptthreads ist, desto länger

Vorteile und Nachteile

Die Geschwindigkeit der Snapshot-Wiederherstellung ist hoch, die Häufigkeit der Generierung der RDB-Datei ist jedoch schwierig

RDB verwendet Binär- und Datenkomprimierung zum Schreiben auf die Festplatte, mit kleiner Dateigröße und schneller Datenwiederherstellung. 🎜 🎜Zusätzlich zu den vollständigen RDB-Snapshots entwirft Redis auch AOF-Post-Write-Protokolle Protokolle sind. 🎜🎜🎜AOF-Post-Write-Protokolle, um Datenverlust während der Ausfallzeit zu vermeiden.

Angenommen, das AOF-Protokoll zeichnet alle geänderten Befehlssequenzen seit der Erstellung der Redis-Instanz auf, dann kann die Speicherdatenstruktur der aktuellen Redis-Instanz wiederhergestellt werden, indem alle Anweisungen nacheinander auf einer leeren Redis-Instanz ausgeführt werden, d. h. der Status wird „wiedergegeben“. .

Vergleich von Pre-Write- und Post-Write-Protokollen

Write Ahead Log (WAL): Vor dem eigentlichen Schreiben von Daten werden die geänderten Daten in die Protokolldatei geschrieben, sodass eine Wiederherstellung nach Fehlern gewährleistet ist.

Zum Beispiel ist das Redo-Protokoll in der MySQL Innodb-Speicher-Engine ein Datenprotokoll, das Änderungen aufzeichnet. Vor der eigentlichen Änderung der Daten wird das Änderungsprotokoll aufgezeichnet und die geänderten Daten ausgeführt.

Protokoll nach dem Schreiben: Führen Sie zuerst die Befehlsanforderung „Schreiben“ aus, schreiben Sie die Daten in den Speicher und zeichnen Sie dann das Protokoll auf.

AOF-Post-Write-Befehl

Protokollformat

Wenn Redis den Befehl „Set Key MageByte“ zum Schreiben von Daten in den Speicher empfängt, schreibt Redis die AOF-Datei im folgenden Format.

• "*3": Zeigt an, dass der aktuelle Befehl in drei Teile unterteilt ist. Jeder Teil beginnt mit „$ + Zahl“, gefolgt vom spezifischen „Befehl, Schlüssel, Wert“ dieses Teils.

• „Zahl“: Gibt die Größe der Bytes an, die von diesem Teil des Befehls, Schlüssels und Werts belegt werden. „$3“ bedeutet beispielsweise, dass dieser Teil 3 Bytes enthält, was dem „set“-Befehl entspricht.

AOF-Protokollformat

"

65 Brother: Warum verwendet Redis das Post-Write-Protokoll?

"

Das Post-Write-Protokoll vermeidet zusätzlichen Prüfaufwand und erfordert keine Syntaxprüfung für ausgeführte Befehle. Wenn Sie die Write-Ahead-Protokollierung verwenden, müssen Sie zunächst überprüfen, ob die Syntax korrekt ist. Andernfalls werden im Protokoll falsche Befehle aufgezeichnet, und bei der Protokollwiederherstellung tritt ein Fehler auf.

Außerdem blockiert das Aufzeichnen des Protokolls nach dem Schreiben nicht die Ausführung des aktuellen „Schreib“-Befehls.

“

65 Bruder: Ist bei AOF also alles sicher?

”

Dummer Junge, so einfach ist das nicht. Wenn Redis gerade mit der Ausführung des Befehls fertig ist und abstürzt, bevor das Protokoll aufgezeichnet wird, gehen möglicherweise die mit dem Befehl verbundenen Daten verloren.

Außerdem vermeidet AOF das Blockieren des aktuellen Befehls, kann jedoch das Risiko einer Blockierung des nächsten Befehls mit sich bringen. Das AOF-Protokoll wird vom Hauptthread ausgeführt. Wenn der Datenträgerdruck hoch ist, ist das Schreiben auf die Festplatte sehr langsam, was dazu führt, dass nachfolgende „Schreib“-Anweisungen blockiert werden.

Ist Ihnen aufgefallen, dass diese beiden Probleme mit dem Zurückschreiben auf die Festplatte zusammenhängen? Wenn Sie den Zeitpunkt des Zurückschreibens des AOF-Protokolls auf die Festplatte nach der Ausführung des Befehls „Schreiben“ einigermaßen steuern können, wird das Problem gelöst.

Writeback-Strategie

Um die Effizienz beim Schreiben von Dateien zu verbessern, speichert das Betriebssystem die geschriebenen Daten normalerweise vorübergehend in einem Speicher, wenn der Benutzer die Funktion write aufruft, um einige Daten in die Datei zu schreiben Puffer werden die Daten im Puffer erst dann tatsächlich auf die Festplatte geschrieben, wenn der Pufferplatz voll ist oder das angegebene Zeitlimit überschritten wird. write 函数，将一些数据写入到文件的时候，操作系统通常会将写入数据暂时保存在一个内存缓冲区里面，等到缓冲区的空间被填满、或者超过了指定的时限之后，才真正地将缓冲区中的数据写入到磁盘里面。

这种做法虽然提高了效率，但也为写入数据带来了安全问题，因为如果计算机发生停机，那么保存在内存缓冲区里面的写入数据将会丢失。

为此，系统提供了fsync和fdatasync两个同步函数，它们可以强制让操作系统立即将缓冲区中的数据写入到硬盘里面，从而确保写入数据的安全性。

Redis 提供的 AOF 配置项appendfsync写回策略直接决定 AOF 持久化功能的效率和安全性。

• always：同步写回，写指令执行完毕立马将 aof_buf缓冲区中的内容刷写到 AOF 文件。

• everysec：每秒写回，写指令执行完，日志只会写到 AOF 文件缓冲区，每隔一秒就把缓冲区内容同步到磁盘。

• no： 操作系统控制，写执行执行完毕，把日志写到 AOF 文件内存缓冲区，由操作系统决定何时刷写到磁盘。

没有两全其美的策略，我们需要在性能和可靠性上做一个取舍。

always同步写回可以做到数据不丢失，但是每个「写」指令都需要写入磁盘，性能最差。

everysec每秒写回，避免了同步写回的性能开销，发生宕机可能有一秒位写入磁盘的数据丢失，在性能和可靠性之间做了折中。

no

Obwohl dieser Ansatz die Effizienz verbessert, bringt er auch Sicherheitsprobleme für die geschriebenen Daten mit sich, denn wenn der Computer herunterfährt, gehen die im Speicherpuffer gespeicherten geschriebenen Daten verloren.

Zu diesem Zweck stellt das System zwei Synchronisationsfunktionen bereit, fsync und fdatasync, die das Betriebssystem zwingen können, die Daten im Puffer sofort auf die Festplatte zu schreiben, Gewährleisten Sie somit die Sicherheit der geschriebenen Daten.

🎜Die von Redis bereitgestellte Rückschreibstrategie für das AOF-Konfigurationselement appendfsync bestimmt direkt die Effizienz und Sicherheit der AOF-Persistenzfunktion. 🎜🎜🎜🎜immer: Synchrones Zurückschreiben, der Inhalt im aof_buf-Puffer wird sofort nach Ausführung des Schreibbefehls in die AOF-Datei geschrieben. 🎜🎜🎜🎜jede Sekunde: Jede Sekunde zurückschreiben Nachdem der Schreibbefehl ausgeführt wurde, wird das Protokoll nur in den AOF-Dateipuffer geschrieben und der Pufferinhalt wird jede Sekunde mit der Festplatte synchronisiert. 🎜🎜🎜🎜Nein: Vom Betriebssystem gesteuert wird das Protokoll nach Abschluss der Schreibausführung in den AOF-Dateispeicherpuffer geschrieben und das Betriebssystem entscheidet, wann es auf die Festplatte geleert wird. 🎜🎜🎜🎜Es gibt keine Strategie, die das Beste aus beiden Welten vereint, wir müssen einen Kompromiss zwischen Leistung und Zuverlässigkeit eingehen. 🎜🎜always Synchrones Zurückschreiben kann Datenverlust verhindern, aber jeder „Schreib“-Befehl muss auf die Festplatte geschrieben werden, die die schlechteste Leistung hat. 🎜🎜everysec schreibt jede Sekunde zurück und vermeidet so den Leistungsaufwand des synchronen Zurückschreibens. Im Falle einer Ausfallzeit können auf die Festplatte geschriebene Daten für eine Sekunde verloren gehen, was einen Kompromiss zwischen Leistung und Zuverlässigkeit darstellt. 🎜🎜nein Betriebssystemsteuerung: Schreiben Sie nach der Ausführung des Schreibbefehls in den AOF-Dateipuffer, um nachfolgende „Schreib“-Befehle auszuführen. Die Leistung ist am besten, es können jedoch viele Daten verloren gehen. 🎜🎜“🎜65 Bruder: Wie soll ich dann eine Strategie wählen?🎜„

Wir können die Rückschreibstrategie entsprechend den Systemanforderungen für hohe Leistung und hohe Zuverlässigkeit auswählen. Zusammenfassend: Wenn Sie eine hohe Leistung erzielen möchten, wählen Sie die Strategie „Kein“; wenn Sie eine hohe Zuverlässigkeitsgarantie erhalten möchten, wählen Sie die Strategie „Immer“. ; Wenn Sie einen geringen Datenverlust zulassen und eine starke Beeinträchtigung der Leistung wünschen, wählen Sie die Everysec-Strategie.

Vorteile und Nachteile: Das Protokoll wird erst nach erfolgreicher Ausführung aufgezeichnet, wodurch der Aufwand für die Überprüfung der Befehlssyntax vermieden wird . Blockiert den aktuellen „Schreib“-Befehl.

Nachteile: Da AOF den Inhalt jeder Anweisung aufzeichnet, sehen Sie sich bitte das Protokollformat oben für das spezifische Format an. Jeder Befehl muss während der Fehlerwiederherstellung ausgeführt werden. Wenn die Protokolldatei zu groß ist, ist der gesamte Wiederherstellungsprozess sehr langsam.

Darüber hinaus unterliegt das Dateisystem auch Beschränkungen hinsichtlich der Dateigröße. Wenn die Datei größer wird, verringert sich auch die Effizienz beim Anhängen.

Das Protokoll ist zu groß: AOF-Umschreibmechanismus

"65 Bruder: Was soll ich tun, wenn die AOF-Protokolldatei zu groß ist?

"

Das AOF-Vorschreibprotokoll zeichnet jede „Schreib“-Befehlsoperation auf . Es verursacht keinen Leistungsverlust wie der vollständige RDB-Snapshot, aber die Ausführungsgeschwindigkeit ist nicht so hoch wie bei RDB. Gleichzeitig führen zu große Protokolldateien auch zu Leistungsproblemen. Für einen echten Mann wie Redis, der nur schnell sein möchte. Probleme durch zu große Baumstämme kann er auf keinen Fall tolerieren.

Daher hat Redis einen Killer-„AOF-Rewriting-Mechanismus“ entwickelt. Redis bietet den

-Befehl, um das AOF-Protokoll zu verschlanken.

Das Prinzip besteht darin, einen Unterprozess zu öffnen, um den Speicher zu durchqueren und ihn in eine Reihe von Redis-Betriebsanweisungen umzuwandeln, die in eine neue AOF-Protokolldatei serialisiert werden. Nach Abschluss der Serialisierung wird das inkrementelle AOF-Protokoll, das während des Vorgangs erstellt wurde, an die neue AOF-Protokolldatei angehängt. Nach Abschluss des Anhängens wird die alte AOF-Protokolldatei sofort ersetzt und die Schlankheitsarbeit ist abgeschlossen. bgrewriteaof

"

65 Bruder: Warum kann der AOF-Umschreibemechanismus die Protokolldatei verkleinern?

"

Der Umschreibemechanismus verfügt über eine „Mehrfach-zu-eins“-Funktion, die mehrere Anweisungen im alten Protokoll in eine ausgegebene Anweisung umwandelt.

Wie unten gezeigt:

AOF-Umschreibemechanismus (Fehlerkorrektur: 3 Anweisungen wurden vor dem Umschreiben aufgezeichnet)

"

65 Bruder: Nach dem Umschreiben wird das AOF-Protokoll kleiner und schließlich die neuesten Daten der gesamten Datenbank Wird das Vorgangsprotokoll auf die Festplatte geschrieben? Der bgrewriteaof-Prozess wird abgeschlossen, um ein Blockieren des Hauptthreads zu verhindern.

Der Umschreibvorgang unterscheidet sich vom Zurückschreiben des AOF-Protokolls durch den Hauptthread. Der Umschreibvorgang wird durch den Hintergrund-Unterprozess bgrewriteaof abgeschlossen, um eine Blockierung des Hauptthreads und eine Verschlechterung der Datenbankleistung zu vermeiden.

Im Allgemeinen gibt es insgesamt zwei Protokolle, eine Speicherdatenkopie, nämlich das alte AOF-Protokoll, das neue AOF-Rewrite-Protokoll und die Redis-Datenkopie.

Redis zeichnet die während des Umschreibvorgangs empfangenen „Schreib“-Befehlsvorgänge gleichzeitig im alten AOF-Puffer und im AOF-Umschreibepuffer auf, sodass das Umschreibeprotokoll auch die neuesten Vorgänge speichert. Nachdem alle Operationsdatensätze der kopierten Daten neu geschrieben wurden, werden die letzten im Rewrite-Puffer aufgezeichneten Operationen auch in die neue AOF-Datei geschrieben.

Jedes Mal, wenn AOF neu geschrieben wird, führt Redis zunächst eine Speicherkopie durch, um die Daten zu durchlaufen, um Neuschreibdatensätze zu generieren. Dabei werden zwei Protokolle verwendet, um sicherzustellen, dass die neu geschriebenen Daten während des Neuschreibvorgangs nicht verloren gehen und die Daten konsistent sind .

AOF-Umschreibungsprozess

"

65 Bruder: AOF-Umschreibung hat auch ein Umschreibungsprotokoll. Warum teilt es nicht das Protokoll von AOF selbst?

"

Das ist eine gute Frage, es gibt die folgenden zwei Grund:

Ein Grund dafür ist, dass das Schreiben derselben Datei zwischen übergeordneten und untergeordneten Prozessen unweigerlich zu Wettbewerbsproblemen führt. Die Kontrolle des Wettbewerbs bedeutet, dass dies Auswirkungen auf die Leistung des übergeordneten Prozesses hat.

Wenn der AOF-Umschreibungsprozess fehlschlägt, ist die ursprüngliche AOF-Datei gleichbedeutend mit einer Kontamination und kann nicht wiederhergestellt und verwendet werden. Daher schreibt Redis AOF eine neue Datei neu. Wenn das Umschreiben fehlschlägt, löschen Sie die Datei einfach direkt. Dies hat keine Auswirkungen auf die ursprüngliche AOF-Datei. Nachdem das Umschreiben abgeschlossen ist, ersetzen Sie einfach die alte Datei.

1. Redis 4.0-Hybridprotokollmodell

2. Beim Neustart von Redis verwenden wir selten RDB, um den Speicherstatus wiederherzustellen, da viele Daten verloren gehen. Normalerweise verwenden wir die AOF-Protokollwiedergabe, aber die Leistung der AOF-Protokollwiedergabe ist viel langsamer als die von RDB. Wenn die Redis-Instanz also groß ist, dauert der Start lange.

Um dieses Problem zu lösen, bringt Redis 4.0 eine neue Persistenzoption – Hybridpersistenz. Speichern Sie den Inhalt der RDB-Datei zusammen mit der inkrementellen AOF-Protokolldatei. Das AOF-Protokoll ist hier nicht mehr das vollständige Protokoll, sondern das inkrementelle AOF-Protokoll, das im Zeitraum vom Beginn der Persistenz bis zum Ende der Persistenz aufgetreten ist. Normalerweise ist dieser Teil des AOF-Protokolls sehr klein.

Beim Neustart von Redis können Sie also zuerst den RDB-Inhalt laden und dann das inkrementelle AOF-Protokoll wiedergeben, wodurch die vorherige Wiedergabe der vollständigen AOF-Datei vollständig ersetzt werden kann und die Effizienz des Neustarts erheblich verbessert wird.

So werden RDB-Speicher-Snapshots mit einer etwas langsameren Frequenz ausgeführt, wobei die AOF-Protokollierung verwendet wird, um alle „Schreibvorgänge“ aufzuzeichnen, die während der beiden RDB-Snapshots stattgefunden haben.

Auf diese Weise müssen Snapshots nicht häufig ausgeführt werden, da AOF gleichzeitig nur die „Schreib“-Anweisungen aufzeichnen muss, die zwischen zwei Snapshots erfolgen, und nicht alle Vorgänge aufzeichnen müssen, um eine übermäßige Dateigröße zu vermeiden .

Zusammenfassung

Redis hat bgsave und copy-on-write entwickelt, um die Auswirkungen auf Lese- und Schreibanweisungen während der Snapshot-Ausführung so weit wie möglich zu vermeiden. Häufige Snapshots üben Druck auf die Festplatte aus und der Fork blockiert den Hauptthread.

Redis hat zwei wichtige Killerfunktionen entwickelt, um eine schnelle Wiederherstellung nach Ausfallzeiten ohne Datenverlust zu erreichen.

Um zu verhindern, dass das Protokoll zu groß wird, wird ein AOF-Umschreibmechanismus bereitgestellt. Der Datenschreibvorgang wird entsprechend dem neuesten Datenstatus der Datenbank als neues Protokoll generiert und im Hintergrund abgeschlossen, ohne den Hauptthread zu blockieren .

Die Integration von AOF und RDB bietet eine neue Persistenzstrategie und ein Hybridprotokollmodell in Redis 4.0. Beim Neustart von Redis können Sie zuerst den RDB-Inhalt laden und dann das inkrementelle AOF-Protokoll wiedergeben, wodurch die vorherige vollständige AOF-Dateiwiedergabe vollständig ersetzt werden kann und die Effizienz des Neustarts erheblich verbessert wird.

Abschließend hat „Code Byte“ in Bezug auf die Wahl von AOF und RDB drei Vorschläge:

• Wenn Daten nicht verloren gehen können, ist die gemischte Verwendung von Speicher-Snapshots und AOF eine gute Wahl.

• Wenn dies möglich ist Bei Datenverlust auf Minutenebene können Sie nur RDB verwenden.

• Wenn Sie nur AOF verwenden, geben Sie der Verwendung der Everysec-Konfigurationsoption Vorrang, da diese ein Gleichgewicht zwischen Zuverlässigkeit und Leistung herstellt.

Nach zwei Serien von Redis-Artikeln sollten die Leser ein umfassendes Verständnis von Redis haben.

Das obige ist der detaillierte Inhalt vonRedis-Protokoll: Tipps für eine schnelle Wiederherstellung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!