So erreichen Sie eine schnelle Wiederherstellung und Beständigkeit ohne Angst vor Ausfallzeiten in Redis

Wie kann man in Redis eine schnelle Wiederherstellung und Ausdauer erreichen, ohne Angst vor Ausfallzeiten haben zu müssen? Der folgende Artikel führt Sie durch das Ganze und ich hoffe, er hilft Ihnen weiter!

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

Wir verwenden Redis normalerweise als Cache, um die Leseantwortleistung zu verbessern. Wenn wir direkt auf die Datenbank zugreifen und eine große Menge Datenverkehr auf MySQL trifft, kann dies schwerwiegendere Folgen haben Probleme. [Verwandte Empfehlungen: Redis-Video-Tutorial]

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 Verlangsamung der Reaktion führt.

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

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.

Folgen Sie „Code Byte“, um Redis gründlich zu verstehen und die Kernprinzipien und praktischen Fähigkeiten von Redis gründlich zu 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.

Im vorherigen Artikel haben wir die Kerndatenstruktur, das IO-Modell und das Thread-Modell von Redis analysiert und entsprechend verschiedenen Daten eine geeignete Datencodierung verwendet. Verstehen Sie genau, warum es wirklich schnell ist!

Dieser Artikel konzentriert sich auf die folgenden Punkte:

• Wie erholt man sich schnell nach einer Ausfallzeit?
• Ausfallzeiten, wie vermeidet Redis Datenverlust?
• Was ist ein RDB-Speicher-Snapshot?
• AOF-Protokollimplementierungsmechanismus
• Was ist Copy-on-Write-Technologie?
• ….

Die beteiligten Wissenspunkte sind wie in der Abbildung dargestellt:

Redis-Panorama

Das Panorama kann um zwei Dimensionen erweitert werden:

Anwendungsdimensionen: Cache-Nutzung, Clustering-Anwendung und clevere Nutzung von Datenstrukturen

Systemdimensionen: können in drei Höhen klassifiziert werden

1. Hohe Leistung: Thread-Modell, Netzwerk-IO-Modell, Datenstruktur, Persistenzmechanismus;
2. Hohe Verfügbarkeit: Master-Slave-Replikation , Sentinel-Cluster, Cluster-Sharded-Cluster;
3. Hohe Erweiterung: Lastausgleich

Die Kapitel der Redis-Serie drehen uns dieses Mal um die Geheimnisse des Hochleistungs- und Persistenzmechanismus von Redis.

Haben Sie einen Panoramablick und beherrschen Sie die Systemansicht.

Der Systemblick ist tatsächlich bis zu einem gewissen Grad entscheidend, wenn man Probleme löst. Ein Systemblick bedeutet, dass man Probleme fundiert und organisiert lokalisieren und lösen kann.

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

65 Brother: Redis ist aus bestimmten Gründen ausgefallen, was dazu führt, dass der gesamte Datenverkehr sofort auf das Backend MySQL trifft, aber seine Daten sind noch vorhanden Keine Daten im Speicher nach Neustart? Wie kann ich Datenverlust nach Neustart verhindern?

65 Keine Sorge, „Code Byte“ führt Sie Schritt für Schritt durch die schnelle Wiederherstellung nach einem Redis-Absturz.

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 „Schreib“-Vorgang zum Betreiben des Speichers ausgeführt wird, wird dieser gleichzeitig auf die Festplatte geschrieben.

Diese Lösung hat ein schwerwiegendes Problem: jede Schreibanweisung Schreibt nicht nur in den Speicher, sondern auch auf die Festplatte. Die Leistung der Festplatte ist im Vergleich zum Speicher zu langsam, was zu einer erheblichen Leistungseinbuße von Redis führt.

Speicherschnappschuss

65 Bruder: Wie kann man also dieses Problem beim gleichzeitigen Schreiben vermeiden?

Wir verwenden Redis normalerweise als Cache. Auch wenn Redis nicht alle Daten speichert, können sie dennoch über die Datenbank abgerufen werden, sodass Redis nicht alle Daten speichert. Redis-Datenpersistenz verwendet den „RDB-Daten-Snapshot“. Methode. Erzielen Sie eine schnelle Wiederherstellung nach Ausfallzeiten.

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, bei dem die Daten zu einem bestimmten Zeitpunkt in Form einer Datei erfasst und auf die Festplatte geschrieben werden. Diese Snapshot-Datei heißt RDB-Datei. 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.

Lesen Sie bei der Datenwiederherstellung die RDB-Datei direkt in den Speicher, um die Wiederherstellung abzuschließen.

65 Bruder: Von welchen Daten machst du Schnappschüsse? Oder wie oft soll man Schnappschüsse machen? Dies wirkt sich auf die Ausführungseffizienz des Snapshots aus.

65 Das ist großartig, ich fange an, über Dateneffizienz nachzudenken. Im vorherigen Artikel haben wir erfahren, dass sein Single-Thread-Modell festlegt, dass wir Vorgänge, die den Haupt-Thread blockieren, so weit wie möglich vermeiden und verhindern sollten, dass die RDB-Dateigenerierung den Haupt-Thread blockiert.

RDB-Strategie generieren

Redis bietet zwei Anweisungen zum Generieren von RDB-Dateien:

• save: wird vom Hauptthread ausgeführt und blockiert;
• bgsave: wird durch Aufruf der Glibc-Funktion forkgeneriert > Ein untergeordneter Prozess wird zum Schreiben der RDB-Datei verwendet. Die Snapshot-Persistenz wird vollständig vom untergeordneten Prozess verwaltet. Der übergeordnete Prozess verarbeitet weiterhin Client-Anfragen und generiert die Standardkonfiguration der RDB-Datei. 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 Bruder: 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 verarbeiten zu können, nicht dasselbe sind. Obwohl der Hauptthread nicht blockiert ist, kann er zur Gewährleistung der Konsistenz der Snapshot-Daten nur Lesevorgänge verarbeiten und die Daten des ausgeführten Snapshots nicht ändern.

Offensichtlich lässt Redis nicht zu, dass Schreibvorgänge ausgesetzt werden, 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) des Betriebssystems, um Snapshot-Persistenz zu erreichen. Dieser Mechanismus ist sehr interessant und nur wenige Menschen kennen ihn. Multiprozess-COW ist auch ein wichtiger Indikator für die Breite des Wissens eines Programmierers.

• Redis ruft die Glibc-Funktion fork auf, um während der Persistenz einen untergeordneten Prozess zu generieren. Die Snapshot-Persistenz wird vollständig vom untergeordneten Prozess verwaltet und der übergeordnete Prozess verarbeitet weiterhin Clientanforderungen.
  Wenn der untergeordnete Prozess gerade erstellt wird, teilt er das Codesegment und das Datensegment im Speicher mit dem übergeordneten Prozess. Zu diesem Zeitpunkt können Sie sich den Vater-Sohn-Prozess als einen siamesischen Zwilling vorstellen, der den Körper teilt.
• Dies ist der Mechanismus des Linux-Betriebssystems. Um Speicherressourcen zu sparen, sollten diese so weit wie möglich gemeinsam genutzt werden. In dem Moment, in dem der Prozess getrennt wird, gibt es fast keine offensichtliche Veränderung im Speicherwachstum.
  bgsave Der untergeordnete Prozess kann alle Speicherdaten des Hauptthreads gemeinsam nutzen, die Daten des Hauptthreads lesen und in die RDB-Datei schreiben.

Wenn Sie den Befehl SAVE oder den Befehl BGSAVE ausführen, um eine neue RDB-Datei zu erstellen, überprüft das Programm die Schlüssel in der Datenbank und abgelaufene Schlüssel werden nicht darin gespeichert in der neu erstellten RDB-Datei.

Wenn der Hauptthread den Schreibbefehl ausführt, um die Daten zu ändern, wird eine Kopie der Daten erstellt. bgsave Der Unterprozess liest die kopierten Daten und schreibt sie in die RDB-Datei Der Hauptthread kann die Originaldaten direkt ändern.

Dies stellt nicht nur die Integrität des Snapshots sicher, sondern ermöglicht es dem Hauptthread auch, die Daten gleichzeitig zu ändern, wodurch jegliche Auswirkungen auf das normale Geschäft vermieden werden.

Redis verwendet bgsave, um einen Schnappschuss aller Daten im aktuellen Speicher zu erstellen. Dieser Vorgang wird vom untergeordneten Prozess im Hintergrund ausgeführt, wodurch der Hauptthread gleichzeitig die Daten ändern kann.

65 Bruder: Können Sie die RDB-Datei jede Sekunde ausführen? Auf diese Weise gehen auch 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 sieht so aus, als ob die vorherige RDB noch nicht ausgeführt wurde, und die nächste beginnt erneut zu generieren und gerät in eine Endlosschleife. 🎜🎜🎜🎜Eine Verzweigung aus dem bgsave-Unterprozess blockiert den Hauptthread. Je größer der Speicher des Hauptthreads ist, desto länger ist die Blockierungszeit. 🎜🎜🎜🎜🎜Vorteile und Nachteile🎜🎜🎜Die Wiederherstellungsgeschwindigkeit von Snapshots ist schnell, aber die Häufigkeit der Generierung von RDB-Dateien ist schwer zu kontrollieren, da bei geringerer Häufigkeit mehr Daten verloren gehen zu schnell ist, wird zusätzlicher Overhead verbraucht. 🎜🎜RDB verwendet Binär- und Datenkomprimierung zum Schreiben auf die Festplatte, mit geringer Dateigröße und schneller Datenwiederherstellungsgeschwindigkeit. 🎜🎜Zusätzlich zu den vollständigen RDB-Snapshots entwirft Redis auch AOF-Post-Write-Protokolle. Lassen Sie uns als Nächstes darüber sprechen, was AOF-Protokolle sind. 🎜🎜🎜AOF-Post-Write-Protokoll zur Vermeidung von Datenverlust während Ausfallzeiten🎜🎜🎜Das AOF-Protokoll speichert die sequentielle Befehlssequenz des Redis-Servers. Das AOF-Protokoll zeichnet nur Anweisungen auf, die den Speicher ändern. 🎜

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.

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 von dem 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.

65 Bruder: Warum verwendet Redis die Post-Write-Protokollierung?

Protokolle nach dem Schreiben vermeiden zusätzlichen Prüfaufwand und erfordern keine Syntaxprüfung der ausgeführten 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 wird das Protokoll nach dem Schreiben aufgezeichnet, blockiert nicht die Ausführung des aktuellen „Schreib“-Befehls.

65 Bruder: Ist AOF also narrensicher?

Dummer Junge, so einfach ist das nicht. Wenn Redis gerade die Ausführung des Befehls beendet hat und vor der Aufzeichnung des Protokolls abstürzt, 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 zur Verfügung, 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: 🎜 Nach Abschluss der Schreibausführung wird das Protokoll vom Betriebssystem gesteuert 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 basierend auf den Anforderungen des Systems an hohe Leistung und hohe Zuverlässigkeit auswählen. Zusammenfassend: Wenn Sie eine hohe Leistung erzielen möchten, wählen Sie die Strategie „Nein“. Wenn Sie eine hohe Zuverlässigkeitsgarantie erhalten möchten, wählen Sie die Strategie „Immer“, wenn Sie einen geringen Datenverlust zulassen, die Leistung jedoch stark beeinträchtigt werden soll . .

Vor- und Nachteile

Vorteile: Das Protokoll wird erst nach erfolgreicher Ausführung aufgezeichnet, wodurch der Aufwand für die Überprüfung der Befehlssyntax vermieden wird. Gleichzeitig wird der aktuelle „Schreib“-Befehl nicht blockiert.

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 bgrewriteaof-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-Bedienanweisungen 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.

65 Bruder: Warum kann der AOF-Umschreibmechanismus Protokolldateien verkleinern?

Der Umschreibmechanismus verfügt über die Funktion „Mehrfach zu Eins“, die mehrere Anweisungen im alten Protokoll nach dem Umschreiben in eine Anweisung umwandelt.

Wie unten gezeigt:

Drei LPUSH-Anweisungen, eine wird nach dem Umschreiben durch AOF generiert. Bei Szenen, die mehrmals geändert wurden, ist der Reduktionseffekt offensichtlicher.

65 Bruder: Nach dem Umschreiben wurde das AOF-Protokoll kleiner und schließlich wurde das Betriebsprotokoll der neuesten Daten der gesamten Datenbank auf die Festplatte geleert. Wird das Umschreiben den Hauptthread blockieren?

„Bruder Ma“ erwähnte oben, dass das AOF-Protokoll vom Hauptthread zurückgeschrieben wird. Der AOF-Umschreibvorgang wird tatsächlich vom Hintergrund-Unterprozess bgrewriteaof abgeschlossen, um ein Blockieren des Hauptthreads zu verhindern.

Der Umschreibvorgang unterscheidet sich vom Zurückschreiben des AOF-Protokolls durch den Hintergrund-Unterprozess bgrewriteaof. Dies dient auch dazu, eine Blockierung des Hauptthreads und eine Beeinträchtigung der Datenbankleistung zu vermeiden verringern.

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 .

65 Brother: AOF Rewrite verfügt auch über ein Rewrite-Protokoll. Warum wird das Protokoll nicht über AOF selbst geteilt?

Dies ist aus den folgenden zwei Gründen eine gute Frage:

Ein Grund dafür ist, dass es unweigerlich zu Konkurrenz kommt, wenn übergeordnete und untergeordnete Prozesse dieselbe Datei schreiben, was sich auf die Leistung des übergeordneten Prozesses auswirkt .

• 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.
Redis 4.0-Hybridprotokollmodell

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.

Redis 4.0 bringt eine neue Persistenzoption zur Lösung dieses Problems – Hybrid-Persistenz. 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 vollständige AOF-Dateiwiedergabe vollständig ersetzt werden kann und die Effizienz des Neustarts erheblich verbessert wird.

Daher werden RDB-Speicher-Snapshots mit einer etwas langsameren Frequenz ausgeführt, wobei die AOF-Protokollierung verwendet wird, um alle „Schreib“-Vorgä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 Minutenebene zulässig ist Im Falle eines Datenverlusts 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.

Bleiben Sie dran...

Originaladresse: https://juejin.cn/post/6961735998547951653

Autor: Code Brother Byte

Weitere Programmierkenntnisse finden Sie unter: Programmiervideo ! !

Das obige ist der detaillierte Inhalt vonSo erreichen Sie eine schnelle Wiederherstellung und Beständigkeit ohne Angst vor Ausfallzeiten in Redis. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!