Lawinen- und Penetrationsprobleme in Java-Cache und -Lösungen

Cache-Lawine

Cache-Lawine bedeutet, dass eine große Anzahl von Caches in Redis gleichzeitig ausfällt. Wenn in diesem Zeitraum eine große Anzahl von Anfragen gleichzeitig initiiert wird, greift die Anfrage direkt auf die Datenbank zu kann die Datenbank überfordern.

Cache-Lawine beschreibt im Allgemeinen Daten, die sich nicht im Cache, sondern in der Datenbank befinden, und die Anforderung wird aufgrund des Zeitablaufs direkt an die Datenbank weitergeleitet.

Lösung

Es gibt viele Möglichkeiten, die Cache-Lawine zu lösen:

• 1. Sperren, um den Single-Thread-Zugriff auf den Cache sicherzustellen. Auf diese Weise werden nicht viele Anfragen gleichzeitig auf die Datenbank zugreifen.

• 2. Stellen Sie die Ablaufzeit nicht gleich ein. Ein typisches Beispiel ist die Initialisierung der Aufwärmdaten. Beim Speichern der Daten im Cache kann eine zufällige Zeit verwendet werden, um sicherzustellen, dass nicht viele Caches gleichzeitig ablaufen.

• 3. Wenn der Speicher es zulässt, kann der Cache so eingestellt werden, dass er nie abläuft.

Cache-Aufschlüsselung

Cache-Aufschlüsselung ist der Cache-Lawine sehr ähnlich. Der Unterschied besteht darin, dass sich die Cache-Aufschlüsselung im Allgemeinen auf einen einzelnen Cache-Fehler bezieht und gleichzeitig große gleichzeitige Anforderungen auf diesen Schlüssel zugreifen müssen, was dazu führt Datenbankdruck.

Lösung

Die Methode zur Lösung des Cache-Ausfalls ist der Methode zur Lösung der Cache-Lawine sehr ähnlich:

• 1 Sperre, um den Single-Thread-Zugriff auf den Cache sicherzustellen. Auf diese Weise wird der Cache neu geschrieben, nachdem die erste Anforderung die Datenbank erreicht hat, und nachfolgende Anforderungen können den Cache direkt lesen.

• 2. Wenn der Speicher es zulässt, kann der Cache so eingestellt werden, dass er nie abläuft.

Cache-Penetration

Der wesentliche Unterschied zwischen der Cache-Penetration und den beiden oben genannten Phänomenen besteht darin, dass die Daten, auf die zu diesem Zeitpunkt zugegriffen wird, nicht in der Datenbank vorhanden sind. Da die Datenbank also nicht vorhanden ist, ist sie definitiv nicht im Cache vorhanden Wenn die Parallelität also zu groß ist, gelangen kontinuierlich Daten in die Datenbank, was einen großen Druck auf die Datenbank ausübt.

Lösung

Für das Problem der Cache-Penetration hat das Sperren keine gute Wirkung, da der Schlüssel selbst nicht vorhanden ist. Selbst wenn die Anzahl der Thread-Zugriffe kontrolliert wird, werden Anfragen weiterhin kontinuierlich in der Datenbank eingehen.

Um das Problem der Cache-Penetration zu lösen, können im Allgemeinen die folgenden Lösungen zusammen verwendet werden:

• 1 Die Schnittstellenschicht führt eine Überprüfung durch und gibt illegale Schlüssel direkt zurück, wenn sie gefunden werden. Wenn die Datenbank beispielsweise automatisch inkrementierende IDs verwendet, kann eine nicht ganzzahlige oder negative ID direkt zurückgegeben werden. Wenn eine 32-Bit-UUID verwendet wird, ist die ID-Länge nicht gleich 32 Bits, es kann direkt zurückgegeben werden.

• 2. Nicht vorhandene Daten zwischenspeichern Sie können einen leeren oder anderen vereinbarten ungültigen Wert direkt zwischenspeichern. Bei dieser Lösung ist es am besten, eine kurze Ablaufzeit für den Schlüssel festzulegen, da sonst eine große Anzahl nicht vorhandener Schlüssel in Redis gespeichert wird, die auch viel Speicher belegen.

Bloom-Filter

Was die oben genannte Cache-Penetrationslösung betrifft, denken wir darüber nach: Wenn ein Schlüssel die Überprüfung der ersten Methode umgehen kann und zu diesem Zeitpunkt auf eine große Anzahl nicht vorhandener Schlüssel zugegriffen wird (z. B 100 Millionen oder 1 Milliarde), dann werden zu diesem Zeitpunkt alle im Cache gespeichert, was sehr viel Platz beansprucht und viel Serverspeicher verschwendet, was zu unzureichendem Speicher führt.

Gibt es also eine bessere Lösung? Dies ist der Bloom-Filter, den wir als Nächstes vorstellen werden. Der Bloom-Filter kann das Problem zu vieler Schlüsselwerte weitestgehend lösen.

Was ist ein Bloom-Filter?

Vielleicht wissen die meisten Menschen, dass es eine solche Interviewfrage gibt: Wie kann man schnell feststellen, ob ein Element in 1 Milliarde massiven ungeordneten Daten vorhanden ist?

Um dieses Problem zu lösen, müssen Sie einen Bloom-Filter verwenden, da der Speicher der meisten Server sonst nicht so große Datenmengen speichern kann.

Der Bloom-Filter wurde 1970 von Bloom vorgeschlagen. Es handelt sich tatsächlich um einen langen binären Vektor (Bitmap) und eine Reihe zufälliger Zuordnungsfunktionen (Hash-Funktionen).

Bloom-Filter können verwendet werden, um abzufragen, ob ein Element in einer Menge enthalten ist. Sein Vorteil besteht darin, dass die Speicherplatzeffizienz und die Abfragezeit viel besser sind als bei herkömmlichen Algorithmen. Der Nachteil besteht darin, dass es eine gewisse Fehlerkennungsrate aufweist und schwer zu löschen ist.

Bitmap

Eine der Datenstrukturen in Redis ist die Bitmap. Die wichtige Implementierung des Bloom-Filters ist die Implementierung der Bitmap, bei der es sich um ein Bit-Array handelt, und jede Position in diesem Array hat nur 0 und 1. Es gibt zwei besagt, dass jede Position nur 1 Byte einnimmt, wobei 0 bedeutet, dass kein Element vorhanden ist, und 1 bedeutet, dass ein Element vorhanden ist. Wie in der Abbildung unten gezeigt, handelt es sich um ein einfaches Bloom-Filter-Beispiel (ein Schlüsselwert kann durch Hashing und Bitoperationen bestimmt werden, wo er liegen sollte):

Hash-Kollision

Wir haben oben festgestellt, dass sich Lonely und Wolf in derselben Position befinden. Dieses Phänomen, bei dem verschiedene Schlüsselwerte nach dem Hashing den gleichen Wert erhalten, wird als Hash-Kollision bezeichnet. Nachdem eine Hash-Kollision aufgetreten ist und dann Bit-Operationen ausgeführt wurden, wird sie definitiv an der gleichen Position landen.

Wenn zu viele Hash-Kollisionen auftreten, beeinträchtigt dies die Genauigkeit der Beurteilung. Um Hash-Kollisionen zu reduzieren, berücksichtigen wir daher im Allgemeinen die folgenden zwei Faktoren:

#🎜🎜 ##🎜 🎜#

1. Erhöhen Sie die Größe des Bitmap-Arrays (je größer das Bitmap-Array, desto größer der belegte Speicher).
2. Erhöhen Sie die Anzahl der Hash-Funktionen (derselbe Schlüsselwert ist nach einer Funktion gleich, dann nach der Berechnung von zwei oder mehr Hash-Funktionen). gleiche Ergebnisse werden natürlich abnehmen).
Wir müssen die beiden oben genannten Methoden umfassend berücksichtigen: Beispielsweise verbraucht eine Vergrößerung des Bit-Arrays mehr Platz, und je mehr Hash-Berechnungen durchgeführt werden, desto mehr wirkt sich auch der CPU-Verbrauch auf das Endergebnis aus Wie groß das Bit-Array ist und wie oft die Hash-Funktion berechnet werden muss, muss also im Detail analysiert werden.

Zwei Hauptmerkmale des Bloom-Filters

Das Folgende ist ein Bloom-Filter, der durch zwei Hash-Funktionen erhalten wird, wenn unser Redis dies nicht tut Es gibt sie überhaupt, aber die beiden von Redis nach zwei Hash-Funktionen erhaltenen Positionen sind bereits 1 (eine wird von Wolf über f2 und die andere von Nosql über f1 erhalten).

Durch das obige Phänomen können wir also aus der Perspektive des Bloom-Filters schließen, dass der Bloom-Filter hauptsächlich zwei Hauptmerkmale aufweist: #🎜🎜 ##🎜 🎜#

1. Wenn der Bloom-Filter feststellt, dass ein Element vorhanden ist, kann dieses Element vorhanden sein.

• 2. Wenn der Bloom-Filter feststellt, dass ein Element nicht existiert, dann darf dieses Element nicht existieren.

• Aus der Perspektive der Elemente können wir auch zwei Hauptmerkmale zeichnen:

1 Element tatsächlich existiert, dann wird der Bloom-Filter definitiv feststellen, dass es existiert.

• 2. Wenn das Element nicht existiert, stellt der Bloom-Filter möglicherweise fest, dass es existiert.

• PS: Es ist zu beachten, dass, wenn die Hash-Funktion N-mal übergeben wird, die N-Positionen 1 sein müssen, um die Existenz zu bestimmen, solange eine 0 ist , kann festgestellt werden, dass das Element im Bloom-Filter nicht vorhanden ist.

fpp

Weil es im Bloom-Filter immer eine Falsch-Positiv-Rate geben wird, da Hash-Kollisionen nicht zu 100 % vermieden werden können. Der Bloom-Filter nennt diese falsch positive Wahrscheinlichkeit, also False Positive Probability, kurz fpp.

Bei der praktischen Verwendung von Bloom-Filtern können Sie selbst einen FPP definieren und dann basierend auf der Theorie der Bloom-Filter berechnen, wie viele Hash-Funktionen und wie viel Bit-Array-Speicherplatz benötigt werden. Es ist zu beachten, dass dieser FPP nicht als 100 % definiert werden kann, da es keine 100 %ige Garantie dafür gibt, dass keine Hash-Kollisionen auftreten.

Das obige ist der detaillierte Inhalt vonLawinen- und Penetrationsprobleme in Java-Cache und -Lösungen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!