Die Nutzung des Redis-Caches verbessert die Leistung und Effizienz von Anwendungen erheblich, insbesondere für Datenabfragen. Aber gleichzeitig bringt es auch einige Probleme mit sich. Unter ihnen ist das wichtigste Problem die Konsistenz der Daten, die streng unlösbar ist. Wenn Datenkonsistenz erforderlich ist, kann Caching nicht verwendet werden.
Weitere typische Probleme sind Cache-Durchdringung, Cache-Lawine und Cache-Breakdown. Derzeit gibt es in der Branche auch beliebtere Lösungen. Dieser Artikel soll diese drei Probleme nicht perfekter lösen, noch die gängigen Lösungen in der Branche unterlaufen. Stattdessen werden wir diese drei Problemphänomene anhand der eigentlichen Code-Operation demonstrieren. Der Grund dafür ist, dass es schwierig ist, ein sehr lebendiges Konzept im Kopf zu haben, nur durch die akademische Erklärung dieser Probleme, und mit tatsächlichen Code-Demonstrationen kann man sein Verständnis und Verständnis dieser Probleme vertiefen.
Cache-Durchdringung
Cache-Penetration bezeichnet das Abfragen von Daten, die in einer Datenbank nicht existieren. Wenn der Schlüssel nicht existiert oder der Schlüssel abgelaufen ist, wird die Datenbank abgefragt und die abgefragten Objekte werden in den Cache gelegt. Ist das Datenbank-Abfrageobjekt leer, wird es nicht zwischengespeichert.
Codefluss
- Parameter übergeben die Primärschlüssel-ID des Objekts
- Hol das Objekt aus dem Cache basierend auf dem Schlüssel
- Wenn das Objekt nicht leer ist, kehrt es direkt zurück
- Wenn das Objekt leer ist, führen Sie eine Datenbankabfrage durch
- Wenn das aus der Datenbank abgefragte Objekt nicht leer ist, legen Sie es in den Cache (setzen Sie die Verfallszeit). Stellen Sie sich diese Situation vor: Was würde passieren, wenn der übergebene Parameter -1 wäre? Dieses -1 ist ein Objekt, das nicht existieren darf. Die Datenbank wird jedes Mal abgefragt, jede Abfrage ist leer und wird nicht jedes Mal zwischengespeichert. Wenn es zu einem bösartigen Angriff kommt, kann diese Schwachstelle ausgenutzt werden, um Druck auf die Datenbank auszuüben oder sie sogar zu überfordern. Selbst wenn UUID verwendet wird, ist es leicht, einen nicht vorhandenen KEY zu finden und anzugreifen.
In meiner Arbeit verwende ich die Methode des Cachings von Nullwerten, also Schritt 5 im [Code-Prozess]. Wenn das aus der Datenbank abgefragte Objekt leer ist, wird es ebenfalls in den Cache gelegt, aber die Ablaufzeit des gesetzten Caches ist kurz, zum Beispiel auf 60 Sekunden.
Cache avalanche
Cache-Lawine bezeichnet das Ablauf der Cache-Menge während eines bestimmten Zeitraums.
Einer der Gründe für die Lawine ist zum Beispiel, dass beim Schreiben dieses Artikels es bald um Null Uhr am zwölften Tag sein wird, und es bald eine Welle von Rush-Käufen geben wird. Dann verliert um ein Uhr morgens der Vorrat dieser Ware. Die Zugriffsanfrage für diese Ladung liegt in der Datenbank, und für die Datenbank gibt es periodische Druckspitzen.
Wenn Xiaobian E-Commerce-Projekte durchführt, übernimmt er in der Regel verschiedene Warenkategorien und versteckt verschiedene Zyklen. Waren in derselben Kategorie, plus ein Zufallsfaktor. Auf diese Weise kann die Ablaufzeit des Caches so weit wie möglich verteilt werden, und die Cache-Zeit von Produkten in beliebten Kategorien ist länger, während die Cache-Zeit von Produkten in unbeliebten Kategorien kürzer ist, was ebenfalls die Ressourcen des Caching-Dienstes sparen kann.
Tatsächlich ist ein zentralisierter Ablauf nicht sehr tödlich, und die tödlichere Cache-Lawine ist, dass ein Knoten des Cache-Servers ausfällt oder die Verbindung unterbrochen wird. Da die natürlich auftretende Cache-Lawine in einem bestimmten Zeitraum erzeugt werden muss, kann die Datenbank dem Druck standhalten, und zu diesem Zeitpunkt kann auch die Datenbank dem Druck standhalten. Es ist nichts weiter als periodischer Druck auf die Datenbank. Der Ausfall des Cache-Service-Knotens verursacht unvorhersehbaren Druck auf den Datenbankserver und ist wahrscheinlich, dass die Datenbank sofort überlastet wird.
Cache-Zusammenbruch
Cache-Breakdown bezeichnet einen Schlüssel, der sehr heiß ist und ständig große Nebenläufigkeit transportiert; große Nebenläufigkeit konzentriert sich auf den Zugriff auf diesen Punkt; wenn dieser Schlüssel ausfällt, durchbricht kontinuierlich große Nebenläufigkeit den Cache und fordert direkt die Datenbank an, ähnlich wie ein Loch in eine Barriere.
Als Xiaobian E-Commerce-Projekte machte, machte er dieses Produkt zu einem "Hit".
Tatsächlich ist es in den meisten Fällen schwierig, einen solchen Explosion auf den Datenbankserver unter Druck zu setzen. Es gibt nur wenige Unternehmen, die dieses Niveau erreicht haben. Deshalb hat der pragmatische Editor die Hauptprodukte frühzeitig vorbereitet, damit der Cache niemals abläuft. Selbst wenn sich einige Produkte zu Hits fermentieren, können sie als niemals verlaufend eingestellt werden.
Die Hauptstraße ist einfach, und das mutex-Schlüssel-gegenseitige Ablehnungsschloss wird wirklich nicht verwendet.
|
Veröffentlicht am 19.11.2019 09:55:04
|
|
|
|
