Was passiert, wenn der Redis-Speicher zu groß ist?

1 Die Hauptdatenbank ist ausgefallen

Werfen wir einen Blick auf den Notfallwiederherstellungsprozess nach einem Ausfall der Hauptdatenbank: wie unten gezeigt

# 🎜🎜 #

Wenn die Hauptdatenbank ausgefallen ist, besteht unsere häufigste Disaster-Recovery-Strategie darin, die Hauptdatenbank abzuschneiden. Insbesondere wählt es eine Slave-Bibliothek aus den verbleibenden Slave-Bibliotheken des Clusters aus und aktualisiert sie zur Master-Bibliothek. Nachdem die Slave-Bibliothek zur Master-Bibliothek aktualisiert wurde, werden die verbleibenden Slave-Bibliotheken darunter gemountet, um ihre Slave-Bibliothek zu werden Die gesamte Master-Slave-Datenbank wird wiederhergestellt.

Das Obige ist ein vollständiger Disaster-Recovery-Prozess, und der teuerste Prozess ist das erneute Mounten der Slave-Bibliothek, nicht der Wechsel der Hauptbibliothek.

Dies liegt daran, dass Redis die Daten aus der neuen Hauptdatenbank nicht weiter synchronisieren kann, nachdem sich die Hauptdatenbank basierend auf Synchronisierungspunkten wie MySQL und Mongodb geändert hat. Sobald im Redis-Cluster die Slave-Datenbank den Master wechselt, besteht der Ansatz von Redis darin, die Slave-Datenbank von der ersetzten Master-Datenbank zu löschen und dann eine Kopie der Daten aus der neuen Master-Datenbank vollständig zu synchronisieren, bevor die Übertragung fortgesetzt wird.

Der gesamte Redo-Prozess der Slave-Datenbank sieht folgendermaßen aus:

1. Die Hauptdatenbank speichert ihre eigenen Daten auf der Festplatte

   #🎜🎜 ## 🎜🎜#

   Die Hauptbibliothek sendet die RDB-Datei an die Slave-Bibliothek

2. Laden aus der Bibliothek starten
3. # 🎜🎜##🎜🎜 #Starten Sie den Download nach dem Laden fort und beginnen Sie gleichzeitig mit der Bereitstellung von Diensten

4. Offensichtlich ist das Speichervolumen von Redis in diesem Prozess umso größer Je länger die einzelnen oben genannten Schritte dauern, desto höher sind die tatsächlichen Testdaten (wir glauben, dass unsere Maschinenleistung besser ist):

Sie Wenn die Daten 20 G erreichen, wurde die Wiederherstellungszeit der Slave-Bibliothek auf fast 20 Minuten verlängert. Wenn 10 Slave-Bibliotheken vorhanden sind, dauert die Wiederherstellung nacheinander insgesamt 200 Minuten Die Bibliothek ist derzeit für eine große Anzahl von Leseanfragen verantwortlich. Können Sie eine so lange Wiederherstellungszeit ertragen? gleichzeitig wiederholt werden? Dies liegt daran, dass, wenn alle Slave-Bibliotheken gleichzeitig RDB-Dateien von der Master-Bibliothek anfordern, die Netzwerkkarte der Master-Bibliothek sofort nach dem Volllaufen in einen Zustand übergeht, in dem sie keine Dienste mehr normal bereitstellen kann. Zu diesem Zeitpunkt stürzt die Hauptdatenbank erneut ab, was die Sache nur noch schlimmer macht.

Natürlich können wir die Slave-Datenbanken stapelweise wiederherstellen, beispielsweise in Zweiergruppen, sodass sich die Wiederherstellungszeit aller Slave-Datenbanken nur von 200 Minuten auf 100 Minuten verkürzt Eine fünfzigstufige Lösung zu hundert Schritten?

Ein weiteres wichtiges Problem ist die rote Position im vierten Punkt Wir nennen es „Synchronisationspuffer“.

Der Schreibvorgang der Redis-Hauptbibliothek wird in diesem Bereich gespeichert und dann an die Slave-Bibliothek gesendet. Wenn die Schritte 1, 2 und 3 oben zu lange dauern, ist es wahrscheinlich, dass diese Synchronisierung erfolgt Puffer Es wurde neu geschrieben. Zu diesem Zeitpunkt kann die Slave-Bibliothek den entsprechenden Wiederaufnahmeort nicht finden. Die Antwort besteht darin, die Schritte 1, 2 und 3 zu wiederholen 1, 2 und 3 Dieser Schritt braucht Zeit, sodass die Slave-Bibliothek für immer in einen Teufelskreis gerät: Sie fordert ständig vollständige Daten von der Hauptbibliothek an, was schwerwiegende Auswirkungen auf die Netzwerkkarte der Hauptbibliothek hat.

2 Kapazitätserweiterungsproblem

Normalerweise kommt es zu einem plötzlichen Anstieg des Verkehrsaufkommens, bevor die Ursache gefunden wird um die Kapazität zu erweitern.

Laut der Tabelle in Szenario 1 dauert die Erweiterung einer 20G-Redis-Slave-Datenbank in diesem kritischen Moment möglicherweise . .

3 Ein schlechtes Netzwerk führt zur Neuerstellung der Slave-Bibliothek und löst schließlich eine Lawine aus

Das größte Problem in diesem Szenario ist der Unterschied zwischen den Die Synchronisation der Hauptbibliothek und der Slave-Bibliothek ist unterbrochen, und zu diesem Zeitpunkt ist es wahrscheinlich, dass die Slave-Bibliothek noch Schreibanforderungen akzeptiert. Wenn die Unterbrechungszeit also zu lang ist, wird der Synchronisationspuffer wahrscheinlich überschrieben. Zu diesem Zeitpunkt ist die letzte Synchronisationsposition der Slave-Bibliothek verloren gegangen, obwohl sich die Master-Bibliothek nicht geändert hat, da die Synchronisationsposition der Slave-Bibliothek verloren gegangen ist 1, 2 und 3 in Frage 1. 4 Schritte. Wenn die Speichergröße der Hauptbibliothek zu diesem Zeitpunkt zu groß ist, ist die Redo-Geschwindigkeit der Slave-Bibliothek sehr langsam und die an die Slave-Bibliothek gesendeten Leseanforderungen werden gleichzeitig stark beeinträchtigt Die übertragene RDB-Datei ist zu groß und die Netzwerkkarte der Hauptbibliothek wird für lange Zeit stark beeinträchtigt.

4 Je größer der Speicher, desto länger blockiert der Vorgang, der die Persistenz auslöst, den Hauptthread

Redis ist ein Single-Threaded-In-Memory Wenn Redis zeitaufwändige Vorgänge ausführen muss, wird dafür ein neuer Prozess erstellt, z. B. bgsave und bgrewriteaof. Beim Forken eines neuen Prozesses muss der gemeinsam nutzbare Dateninhalt zwar nicht kopiert werden, die Speicherseitentabelle des vorherigen Prozessbereichs wird jedoch vom Hauptthread kopiert und blockiert alle Lese- und Schreibvorgänge Je länger es dauert, desto höher ist die Speichernutzung. Beispiel: Bei Redis mit 20 GB Speicher benötigt bgsave etwa 750 ms, um die Speicherseitentabelle zu kopieren, und der Redis-Hauptthread wird ebenfalls 750 ms lang blockiert.

Lösung

Die Lösung besteht natürlich darin, den Speicherverbrauch zu reduzieren. Unter normalen Umständen tun wir Folgendes: #🎜 🎜 #

1 Legen Sie die Ablaufzeit fest

Legen Sie die Ablaufzeit für zeitkritische Schlüssel fest und reduzieren Sie die Speicherauswirkung abgelaufener Schlüssel durch die Redis-eigene Reinigung abgelaufener Schlüssel Strategie Gleichzeitig kann es auch geschäftliche Probleme reduzieren und muss nicht regelmäßig gereinigt werden.

Das ist einfach Unsinn, aber gibt es jemanden, dem es genauso geht wie uns?

3 Unnötige Daten rechtzeitig bereinigen

Zum Beispiel überträgt ein Redis die Daten von 3 Unternehmen und nach einer gewissen Zeit von 2 Unternehmen gehen offline und bereinigen dann einfach die relevanten Daten dieser beiden Unternehmen.

4 Versuchen Sie, die Daten so weit wie möglich zu komprimieren Achten Sie auf das Speicherwachstum und suchen Sie nach großen Kapazitätsschlüsseln

Ob Sie ein DBA oder ein Entwickler sind, wenn Sie Redis verwenden, müssen Sie auf den Speicher achten, sonst sind Sie tatsächlich inkompetent. Hier können Sie analysieren, welche Schlüssel in Redis vorhanden sind Beispiele sind relativ groß, um dem Unternehmen dabei zu helfen, abnormale Schlüssel schnell zu finden (nicht). Schlüssel, von denen erwartet wird, dass sie wachsen, sind oft die Ursache von Problemen)

6 pika

Wenn Sie wirklich nicht so müde sein wollen, dann Migrieren Sie das Unternehmen auf das neue Open-Source-Pika, damit Sie dem Speicher nicht zu viel Aufmerksamkeit schenken müssen. Redis-Speicher ist auch vorhanden Die dadurch verursachten Probleme sind kein Problem mehr.

Das obige ist der detaillierte Inhalt vonWas passiert, wenn der Redis-Speicher zu groß ist?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!