1. Vorwort
Jeder weiß, dass einer der Engpässe bei Computern die E/A ist. Um das Problem der Nichtübereinstimmung zwischen Speicher und Festplattengeschwindigkeit zu lösen, wird ein Cache generiert, um einige heiße Daten im Speicher abzulegen und jederzeit darauf zuzugreifen. Dies reduziert die Verbindungszeit der Datenbankanforderung, um ein Aufhängen der Datenbank zu vermeiden. Es ist zu beachten, dass unabhängig davon, ob es sich um einen Zusammenbruch oder um das später besprochene Eindringen und die Lawine handelt, alles unter der Voraussetzung einer hohen Parallelität erfolgt, beispielsweise wenn ein bestimmter Hotkey im Cache fehlschlägt.
2. Ursache des Problems
Es gibt zwei Hauptgründe:
1. Schlüssel wurde durch Seitenaustausch entfernt.
Aus dem ersten Grund hat der Schlüssel in Redis eine Ablaufzeit. Wenn der Schlüssel zu einem bestimmten Zeitpunkt abläuft (wenn das Einkaufszentrum ein Ereignis durchführt, beginnt er um 0:00 Uhr), dann werden alle Abfrageanforderungen für ein bestimmtes Produkt ausgeführt nach 0:00 Uhr wird an die Datenbank weitergegeben, was zum Absturz der Datenbank führt.
3. Verarbeitungsideen für den Umgang mit Ausfällen
Die normale Verarbeitungsanforderung ist wie in der Abbildung dargestellt:
Da der Schlüsselablauf unvermeidlich ist, wenn hoher Datenverkehr zu Redis kommt, entsprechend den Single-Threaded-Eigenschaften von Redis Es kann davon ausgegangen werden, dass sich die Aufgabe in der Warteschlange befindet. Wenn die Anforderung Redis erreicht und festgestellt wird, dass der Schlüssel abgelaufen ist, wird ein Vorgang ausgeführt: Setzen der Sperre.
Dieser Vorgang läuft ungefähr wie folgt ab:
Die Anfrage kommt bei Redis an und es wird festgestellt, dass der Redis-Schlüssel abgelaufen ist. Überprüfen Sie, ob eine Sperre vorhanden ist. Gehen Sie zurück zur Rückseite Warteschlange und Warteschlange. Beachten Sie, dass dies setnx() und nicht set() sein sollte, da möglicherweise andere Threads die Sperre festgelegt haben an die Datenbank, um die Daten abzurufen, und geben Sie die Sperre frei, nachdem die Anforderung zurückgegeben wurde.
- Aber es wirft eine neue Frage auf: Was passiert, wenn Sie die Sperre erhalten und den Abruf der Daten anfordern? Das heißt, die Sperre wird nicht aufgehoben und andere Prozesse warten auf die Lösung ist: Ja, die Sperre legt eine Ablaufzeit fest und wird nicht freigegeben. Es ist leicht zu sagen, dass die Sperre erneut auftritt Zeitüberschreitung? Das heißt, die Daten werden nicht innerhalb der festgelegten Zeit entfernt, sondern die Sperre wird aufgrund des Ablaufs häufig inkrementiert. Dies ist jedoch unzuverlässig, da bei der ersten Anforderung eine Zeitüberschreitung auftreten kann Bei nachfolgenden Anforderungen tritt ebenfalls eine Zeitüberschreitung auf. Nach mehreren Zeitüberschreitungen hintereinander ist der Wert für die Ablaufzeit der Sperre zwangsläufig extrem groß. Ja, das hat zu viele Nachteile.
- Eine andere Idee besteht darin, einen weiteren Thread zur Überwachung zu starten. Wenn der Thread beim Abrufen von Daten nicht aufhängt, verzögern Sie die Ablaufzeit der Sperre entsprechend.
4. Penetration 
Der Hauptgrund für die Penetration ist, dass viele Anfragen auf Daten zugreifen, die nicht in der Datenbank vorhanden sind. Beispielsweise wurde ein Einkaufszentrum, das Bücher verkauft, aufgefordert, Teeprodukte abzufragen, weil der Redis-Cache Wird hauptsächlich zum Zwischenspeichern heißer Daten verwendet. Daten, die nicht in der Datenbank vorhanden sind, können nicht zwischengespeichert werden. Diese Art von abnormalem Datenverkehr erreicht die Datenbank direkt und gibt „keine“ Abfrageergebnisse zurück.
Um diese Art von Anfrage zu bearbeiten, besteht die Lösung darin, der Zugriffsanfrage eine Filterebene hinzuzufügen, z. B. Bloom-Filter, erweiterter Bloom-Filter und Kuckucksfilter.
Zusätzlich zu Bloom-Filtern können Sie einige Parameterprüfungen hinzufügen. Wenn Sie beispielsweise Parameter wie id = -10 anfordern, wird Redis zwangsläufig umgangen. Sie können die Benutzerauthentifizierungstests und andere Vorgänge überprüfen. 
5. Lawine
Avalanche ist ähnlich wie eine Panne. Der Unterschied besteht darin, dass eine Panne auftritt, wenn ein Hotspot-Schlüssel zu einem bestimmten Zeitpunkt ausfällt, während eine Lawine auftritt, wenn eine große Anzahl von Hotspot-Schlüsseln augenblicklich ausfällt Es handelt sich um eine zufällige Ablaufzeit, die sehr ungenau ist. Wenn eine Bank beispielsweise Aktivitäten durchführt, beträgt der Zinskoeffizient nach dem Nullpunkt 3 % Kann der entsprechende Schlüssel des Benutzers in einen zufälligen Ablauf geändert werden? Wenn vergangene Daten verwendet werden, spricht man von Dirty Data.
Offensichtlich nicht möglich, sparen Sie das gleiche Geld f0c; Sie sparen 3 Millionen an Zinsen bis zum Ende des Jahres, und der Nachbar hat nur 2 Millionen. Das ist kein Kampf, nur ein Scherz~
Die richtige Idee ist Überprüfen Sie zunächst, ob der Schlüssel zum richtigen Zeitpunkt abläuft. Wenn das Problem mit dem Geschlecht, aber nicht mit der Zeit zusammenhängt, kann es durch eine zufällige Ablaufzeit gelöst werden.
Wenn es zeitbezogen ist, zum Beispiel ändert die gerade erwähnte Bank einen bestimmten Koeffizienten an einem bestimmten Tag, dann muss eine starke Abhängigkeitsaufschlüsselungslösung verwendet werden. Die Strategie besteht darin, zuerst alle Schlüssel mit dem vergangenen Thread zu aktualisieren.
Während der Aktualisierung des Hotspot-Schlüssels im Hintergrund verzögert die Business-Schicht die eingehende Anfrage, z. B. indem sie einige Millisekunden oder Sekunden kurz in den Ruhezustand versetzt Stellen Sie die folgenden Update-Hotspot-Schlüssel zur Verfügung, um den Druck zu verteilen.
Das obige ist der detaillierte Inhalt vonWas verursacht die Redis-Ausfalllawine und wie kann man sie lösen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
