Zusammenbruch und Lawine der Redis-Cache-Penetration

5. Reids-Cache-Problem und Lösung

5.1. Hintergrund

Redis ist eine In-Memory-Datenbank. Wenn sich die abgefragten Daten im Redis-Cache befinden, müssen sie nicht in der realen Datenbank durchsucht werden, was die Abfrage beschleunigt und die Sicherheit der realen Datenbank schützt, aber auch einige Neuerungen mit sich bringt Probleme. Beispielsweise befinden sich die abgefragten Daten nicht im Speicher und in der Datenbank und eine große Anzahl von Schlüsseln schlägt gleichzeitig fehl. Daher müssen diese Probleme gelöst werden, damit Redis besser als Cache verwendet werden kann.

5.2, Cache-Penetration

5.2.1. Was ist Cache-Penetration?

Cache-Penetration: Kurz gesagt, die Abfrage durchläuft den Cache und wird direkt in der realen Datenbank durchsucht, die Daten sind jedoch nicht in der realen Datenbank vorhanden und es kommt zu diesem Zeitpunkt zu einer Cache-Penetration.

Denn wenn der Redis-Cache in das System eingeführt wird, wird nach dem Eingang einer Anforderung zuerst der Redis-Cache abgefragt und der Cache direkt zurückgegeben. Wenn kein Cache vorhanden ist, wird er in der realen Datenbank abgefragt. Wenn einer in der realen Datenbank vorhanden ist, wird er weggeworfenIn den Cache, aber die Daten, die einigen Schlüsseln entsprechen, sind in der realen Datenbank nicht vorhanden, sodass die Daten nicht bei jeder Anforderung in den Cache geworfen werden Da dieser Schlüssel nicht aus dem Cache abgerufen werden kann, wird die Anforderung an die echte Datenbank weitergeleitet, was die reale Datenbank überfordern kann. Einige Hacker nutzen die Cache-Penetration, um Ihre Datenbank zu zerstören, was dazu führt, dass das Unternehmen nicht mehr normal läuft.
Fügen Sie hier eine Bildbeschreibung ein

5.2.2, wie man es löst

  1. Leere Werte zwischenspeichern

    Wenn die von einer Abfrage zurückgegebenen Daten leer sind (unabhängig davon, ob die Datenbank vorhanden ist), speichern wir das Ergebnis dennoch zwischen (null) und legen eine kurze Ablaufzeit dafür fest, bis zu fünf Minuten. Dies verhindert, dass dieselbe Abfrage bei wiederholter Abfrage ungültig wird Taste.

Fügen Sie hier eine Bildbeschreibung ein

  1. Blacklist festlegen

    Das Zwischenspeichern von Nullwerten zur Lösung der Cache-Penetration führt zu Datenredundanz, da es viele illegale Schlüssel gibt. Beim Zwischenspeichern von Nullwerten zur Lösung der Cache-Penetration sind mehr Werte erforderlich, die jedem illegalen Schlüssel entsprechen. Bei einem gegebenen Nullwert sind Obwohl wir eine sehr kurze Ablaufzeit festlegen können, verschwendet dies dennoch Speicherplatz. Um dieses Problem zu lösen, können wir die Eigenschaften der Set-Sammlung verwenden, um eine Blacklist festzulegen, dh nur die Schlüssel, die nicht in der Liste enthalten sind weiter rückwärts Für den Zugriff wird der Schlüssel in der Liste abgefangen.

Fügen Sie hier eine Bildbeschreibung ein

  1. Bloom-Filter

    Der Bloom-Filter (Bloom-Filter) wurde 1970 von Bloom vorgeschlagen. Es handelt sich tatsächlich um einen sehr langen binären Vektor (Bitmap) und eine Reihe zufälliger Zuordnungsfunktionen (Hash-Funktionen). Unter diesen bedeutet 0, dass es nicht existiert, und 1 bedeutet, dass es existiert. Es gibt k unabhängige Hash-Funktionszuordnungen, und der Hash-Wert wird anhand der zu beurteilenden Zeichen berechnet. Wenn die durch k Indizes erhaltenen Werte alle sind 1, das aktuelle Zeichen wird als vorhanden betrachtet, andernfalls existiert es nicht.

    Ein Bloom-Filter ist eine Datenstruktur, die effizient bestimmen kann, ob ein Element in einer Sammlung vorhanden ist, und zur Bewältigung der Cache-Penetration verwendet werden kann. Alle möglichen gültigen Schlüssel werden im Bloom-Filter gespeichert. Jede eingehende Anfrage wird zuerst beurteilt. Wenn sie nicht im Bloom-Filter ist, kann sie direkt herausgefiltert werden, ohne den Cache oder die Datenbank abzufragen.

    • Vorteile: Es ist sehr schnell, nimmt sehr wenig Platz ein und arbeitet mit dem zugrunde liegenden Binärvektor der Maschine.

    • Nachteile: Es gibt eine gewisse Fehlerkennungsrate und Schwierigkeiten beim Löschen.
      Fügen Sie hier eine Bildbeschreibung ein

  2. Echtzeitüberwachung

    Wenn festgestellt wird, dass die Trefferquote von Redis schnell abnimmt, müssen die Zugriffsobjekte und die abgerufenen Daten überprüft und in Zusammenarbeit mit dem Betriebs- und Wartungspersonal eine Blacklist erstellt werden, um die Dienste auf sie zu beschränken (z. B.: IP-Blacklist

  3. Strombegrenzungskontrolle

    Durch die Implementierung eines Strombegrenzungsmechanismus auf Systemebene können Sie die Anforderungshäufigkeit einer einzelnen IP oder eines Benutzers begrenzen und das häufige Senden einer großen Anzahl ungültiger Anforderungen verhindern, wodurch der Druck auf die Cache-Ebene und die Back-End-Dienste verringert wird.

  4. Grundcheck

    Führen Sie eine grundlegende Parameterüberprüfung auf der Geschäftsebene durch, z. B. die Überprüfung der Gültigkeit eingehender Parameter, um ungültige Anforderungen zu eliminieren. Auf diese Weise können die meisten böswilligen oder ungültigen Anfragen herausgefiltert werden, bevor die Anfrage Redis erreicht.

5.3, Cache-Aufschlüsselung

5.3.1 Was ist eine Cache-Aufschlüsselung?

Cache-Aufschlüsselung: Kurz gesagt, es geht darum, den Cache (Redis) zu durchbrechen und direkt auf die reale Datenbank zuzugreifen, was einen enormen Druck auf die reale Datenbank ausübt.

Der Grund für den Cache-Ausfall liegt hauptsächlich darin, dass die Hotkeys gleichzeitig ablaufen, was dazu führt, dass eine große Anzahl von Anfragen die Schlüssel nicht im Cache abruft und diese Anfragen direkt an die reale Datenbank weitergeleitet werden, was zum Absturz der Datenbank führt. Cache-Thrashing tritt häufig in kurzen Zeitfenstern auf, in denen beliebte Daten ungültig werden.

Fügen Sie hier eine Bildbeschreibung ein

5.3.2, wie man es löst

  1. Wärmen Sie den Hotspot-Schlüssel auf

    Laden Sie heiße Daten aktiv in den Cache, wenn das System startet oder bevor der Cache abläuft, und wärmen Sie den Cache im Voraus auf. Das heißt, legen Sie heiße Daten im Voraus in den Cache und überwachen Sie sie in Echtzeit, um sicherzustellen, dass sich immer heiße Daten im Cache befinden, und verringern Sie die Möglichkeit eines Cache-Ausfalls.

  2. Passen Sie die Ablaufzeit des Hotspot-Schlüssels richtig an

    Sie können beim Festlegen der Cache-Ablaufzeit ein gewisses Maß an Zufälligkeit hinzufügen. Dadurch kann der Cache zu unterschiedlichen Zeitpunkten ungültig gemacht werden, wodurch die Wahrscheinlichkeit verringert wird, dass eine große Anzahl von Caches gleichzeitig ungültig gemacht wird

  3. Isolierung heißer Daten

    Wir können heiße Daten isolieren und verschiedene Cache-Instanzen oder Cluster verwenden, um sie zu speichern. Dies kann die Wahrscheinlichkeit einer Konzentration heißer Daten auf einem Cache-Knoten verringern und das Risiko eines Cache-Ausfalls verringern

  4. Mutex

    Wenn der Cache ungültig gemacht wird, wird ein Mutex verwendet, um zu verhindern, dass mehrere Anfragen gleichzeitig auf die Datenbank zugreifen. Wenn eine Anfrage feststellt, dass der Cache ungültig ist, ruft sie zuerst den Mutex ab, fragt dann die Datenbank ab und legt das Ergebnis im Cache ab. Andere Anfragen warten, bevor sie die Sperre erhalten, wodurch vermieden wird, dass mehrere Anfragen gleichzeitig in den Cache eindringen.

  5. verteilte Sperre

    Wenn die Daten nicht im Cache verfügbar sind, müssen Sie anstelle einer sofortigen Abfrage in der Datenbank eine verteilte Sperre erhalten (z. B. setnx in Redis), die Sperre abrufen und dann die Daten in die Datenbank laden. Der Thread ist nicht verfügbar Die Sperre wird in den Ruhezustand versetzt. Wiederholen Sie nach einer gewissen Zeit die gesamte Datenabrufmethode.

  6. Asynchrone Hintergrundaktualisierung

    Wenn die Daten im Cache bald ablaufen, werden die alten Cache-Daten sofort zurückgegeben und der Cache und die Datenbank werden asynchron aktualisiert. Dadurch kann sichergestellt werden, dass Benutzer schnell auf alte zwischengespeicherte Daten zugreifen können und Cache-Ausfälle aufgrund langer Datenbankabfragezeiten vermieden werden. Legen Sie gleichzeitig nach Abschluss der Datenaktualisierung die neuen Daten in den Cache.

5.4, ​​​​Cache-Lawine

5.4.1 Was ist Cache-Lawine?

Cache-Lawine: Bezieht sich auf einen bestimmten Zeitraum, in dem eine große Datenmenge im Cache gleichzeitig abläuft und zu diesem Zeitpunkt eine große Anzahl von Anforderungen eintrifft, was dazu führt, dass die Anforderung den Cache und die Datenbank nicht erreicht angefordert werden muss, was zu einer übermäßigen unmittelbaren Belastung der Datenbank führt. Cache-Lawinen werden häufig durch Cache-Systemausfälle, Knotenausfallzeiten oder bestimmte ungewöhnliche Bedingungen verursacht.

Der Unterschied zwischen Cache-Lawine und Cache-Aufschlüsselung besteht darin, dass Ersteres das zentralisierte Ablaufen einer großen Anzahl von Schlüsseln ist, während Letzteres das Ablaufen eines bestimmten Hotkeys ist.

Fügen Sie hier eine Bildbeschreibung ein

5.4.2, wie man es löst

  1. Zeitintervall für die Ablaufzeit des Schlüssels

    Legen Sie die Ablaufzeit des Caches angemessen fest, um eine Überlastung der Datenbank durch den gleichzeitigen Ausfall aller Caches zu vermeiden. Strategien wie zufällige Ablaufzeit und hierarchische Einstellung der Ablaufzeit können verwendet werden, um der Cache-Ablaufzeit eine gewisse Zufälligkeit und gleichmäßige Verteilung zu verleihen.

  2. Mehrstufiger Cache

    Führen Sie eine mehrstufige Cache-Architektur ein, platzieren Sie beliebte Daten in der Cache-Ebene näher an der Anwendung und speichern Sie zwischengespeicherte Daten hierarchisch. Sie können einen lokalen Cache (z. B. Speicher) als Cache der ersten Ebene in Kombination mit Redis als Cache der zweiten Ebene verwenden und sogar eine erweiterte Cache-Ebene einführen, z. B. einen verteilten Cache. Auf diese Weise können bei einem Cache-Ausfall die Daten aus der Cache-Ebene der unteren Ebene ergänzt werden, wodurch der direkte Zugriff auf die Back-End-Datenbank reduziert wird.

  3. Cache-Datenverteilung

    Wenn Sie sich zum Speichern aller zwischengespeicherten Daten auf nur eine Redis-Instanz verlassen, besteht das Risiko eines Single Point of Failure. Die zwischengespeicherten Daten können auf mehrere Redis-Instanzen verteilt werden, um zu vermeiden, dass aufgrund des Ausfalls einer einzelnen Instanz nicht alle zwischengespeicherten Daten verfügbar sind. Mechanismen wie Redis-Cluster und Master-Slave-Replikation können verwendet werden, um eine dezentrale Speicherung und eine hohe Datenverfügbarkeit zu realisieren.

  4. Begrenzend

    Durch die Begrenzung des Anforderungsflusses des Zugriffssystems, die Kontrolle des gleichzeitigen Anforderungsvolumens in einem einzigen Zeitraum und die Reduzierung des Drucks auf den Cache und das Back-End-System. Sie können strombegrenzende Algorithmen wie Token-Buckets, Leaky-Buckets usw. verwenden, um Anforderungen zu begrenzen und zu glätten.

  5. Sperre oder Warteschlange

    Verwenden Sie Sperren oder Warteschlangen, um sicherzustellen, dass nicht viele Threads gleichzeitig in die Datenbank lesen und schreiben, um zu vermeiden, dass bei einem Ausfall eine große Anzahl gleichzeitiger Anforderungen auf das zugrunde liegende Speichersystem fallen, was nicht geeignet ist für Situationen mit hoher Parallelität.

  6. Überwachung und Frühwarnung

    Richten Sie einen systematischen Überwachungs- und Frühwarnmechanismus ein, um die Cache-Trefferrate, die Cache-Ablaufrate und andere Indikatoren in Echtzeit zu überwachen und rechtzeitig Maßnahmen zur Bewältigung ungewöhnlicher Situationen zu ergreifen. Dies kann mithilfe von Tools, Systemprotokollen und Indikatorüberwachung erreicht werden.

Supongo que te gusta

Origin blog.csdn.net/qq_40520912/article/details/131504028
Recomendado
Clasificación