Lassen Sie uns über die drei Caching-Probleme von Redis sprechen

Dieser Artikel vermittelt Ihnen relevantes Wissen über Redis. Er stellt hauptsächlich drei Arten von Cache-Problemen vor, nämlich Cache-Penetration, Cache-Aufschlüsselung und Cache-Lawine.

Empfohlenes Lernen: Redis-Lerntutorial

1. Anwendung des Redis-Cache

In unseren tatsächlichen Geschäftsszenarien wird Redis im Allgemeinen in Verbindung mit anderen Datenbanken verwendet, um den Druck zu reduzieren End-End-Datenbank, beispielsweise in Verbindung mit der relationalen Datenbank MySQL.

Redis speichert häufig abgefragte Daten in MySQL, z. B. Hot Data, sodass Benutzer bei einem Besuch keine Abfragen in MySQL durchführen müssen, sondern direkt zwischengespeicherte Daten in Redis erhalten. Dadurch wird der Lesedruck auf die Back-End-Datenbank verringert. Wenn die vom Benutzer abgefragten Daten in Redis nicht verfügbar sind, wird die Abfrageanforderung des Benutzers an die MySQL-Datenbank übertragen.

Wenn MySQL die Daten an den Client zurückgibt, werden die Daten auch in Redis zwischengespeichert. Damit der Benutzer beim Lesen wieder auf die Daten zugreifen kann, können Daten direkt von Redis abgerufen werden. Das Flussdiagramm sieht wie folgt aus:

Wenn wir Redis

als Cache-Datenbank verwenden, läuft es natürlich nicht immer reibungslos. Wir werden auf häufige

drei Caching-Probleme stoßen:

Cache-Penetration

• Cache-Penetration
• Cache-Lawine
• 2. Cache-Penetration2.1 Einführung

Cache-Penetration

bedeutet

Wenn der Benutzer bestimmte Daten abfragt , die Daten sind in Redis nicht vorhanden, das heißt, der Cache wird nicht erreicht. Zu diesem Zeitpunkt wird die Abfrageanforderung an die Persistenzschichtdatenbank MySQL übertragen. Es stellt sich heraus, dass die Daten in MySQL nicht vorhanden sind gibt nur ein leeres Objekt zurück, was darauf hinweist, dass die Abfrage fehlgeschlagen ist.

Wenn es zu viele solcher Anfragen gibt oder wenn Benutzer solche Anfragen für böswillige Angriffe verwenden, wird die MySQL-Datenbank stark belastet und kann sogar zusammenbrechen. Dieses Phänomen wird als Cache-Penetration bezeichnet.

2.2 Lösung

Leere Objekte zwischenspeichern

Wenn MySQL ein leeres Objekt zurückgibt, speichert Redis das Objekt im Cache und legt eine Ablaufzeit dafür fest. Wenn der Benutzer dieselbe Anfrage erneut initiiert, wird ein

leeres Objekt

aus dem Cache abgerufen. Die Anfrage des Benutzers wird in der Cache-Ebene blockiert, wodurch die Back-End-Datenbank geschützt wird. Obwohl die Anforderung nicht in MSQL eingegeben werden kann, belegt diese Strategie den Redis-Cache-Speicherplatz. Bloom-Filter

Speichern Sie zunächst alle Schlüssel der Hotspot-Daten, auf die der Benutzer zugreifen kann, im Bloom-Filter (auch Cache-Vorwärmung genannt).

Wenn ein Benutzer vorhanden ist, wird die Anfrage zuerst gesendet Durch den Bloom-Filter wird ermittelt, ob der angeforderte Schlüssel vorhanden ist. Andernfalls wird die Abfrage weiterhin ausgeführt und im Cache ausgeführt Wenn der Cache nicht vorhanden ist, rufen Sie die Datenbank auf, um eine Abfrage durchzuführen. Im Vergleich zur ersten Methode ist die Verwendung der Bloom-Filtermethode effizienter und praktischer.

Das Prozessdiagramm sieht wie folgt aus: Cache-Vorwärmung: Bezieht sich auf das Laden relevanter Daten in das Redis-Cache-System im Voraus, wenn das System startet. Dadurch wird vermieden, dass Daten geladen werden, wenn der Benutzer sie anfordert.

2.3 Vergleich der Lösungen

Beide Lösungen können das Problem der Cache-Penetration lösen , ihre Verwendungsszenarien sind jedoch unterschiedlich:

Cache leere Objekte : Anzahl der Schlüssel, die für leere Daten geeignet sind Szenarien mit begrenzten und hohe Wahrscheinlichkeit wiederholter Schlüsselanfragen.

Bloom-Filter: Geeignet für Szenarien, in denen die Schlüssel leerer Daten unterschiedlich sind und die Wahrscheinlichkeit wiederholter Schlüsselanforderungen gering ist.

3. Cache-Aufschlüsselung

3.1 Einführung

Cache-Aufschlüsselung bedeutet, dass die vom Benutzer abgefragten Daten nicht im Cache, aber in der Backend-Datenbank vorhanden sind. Der Grund für dieses Phänomen ist Im Allgemeinen wird dies durch den Ablauf des Schlüssels im Cache verursacht. Beispielsweise erhält ein Hot-Data-Schlüssel ständig eine große Anzahl gleichzeitiger Zugriffe. Wenn der Schlüssel zu einem bestimmten Zeitpunkt plötzlich ausfällt, gelangen viele gleichzeitige Anforderungen in die Back-End-Datenbank, wodurch der Druck sofort zunimmt. Dieses Phänomen wird als Cache-Zusammenbruch bezeichnet.

3.2 Lösung

Ablaufzeit ändern

Hotspot-Daten so einstellen, dass sie nie ablaufen.

Des -verteilte Lock

nimmt die Methode der Verteilung von Lock

an, um die Verwendung von Cache neu zu gestalten. Wenn Daten generiert werden, wird der Cache zuerst abgefragt. Wenn kein Cache vorhanden ist, wird er durch eine verteilte Sperre gesperrt. Der erste Prozess, der die Sperre erhält, gelangt zur Abfrage in die Back-End-Datenbank und die Abfrageergebnisse werden in Redis gepuffert. Entsperren

: Wenn andere Prozesse feststellen, dass die Sperre von einem bestimmten Prozess belegt ist, wechseln sie in den Wartezustand. Nach dem Entsperren greifen andere Prozesse nacheinander auf den zwischengespeicherten Schlüssel zu. 3.3 Lösungsvergleich und die Codekomplexität wird zunehmen.

• Mutex-Sperre: Die Idee dieser Lösung ist relativ einfach, aber es gibt bestimmte versteckte Gefahren. Wenn beim Cache-Erstellungsprozess ein Problem auftritt oder er lange dauert, besteht möglicherweise das Risiko Deadlock und Thread-Pool-Blockierung, aber diese Methode Es kann die Back-End-Speicherlast besser reduzieren und eine bessere Konsistenz erreichen. 4. Cache-Lawine zu einem plötzlichen Anstieg des Back-End-Datenbankdrucks oder sogar zum Hängenbleiben. Dieses Phänomen wird als Cache-Lawine bezeichnet. Es unterscheidet sich vom Cache-Ausfall, wenn ein bestimmter Hotkey plötzlich abläuft, wenn die Parallelität besonders groß ist, während eine Cache-Lawine auftritt, wenn eine große Anzahl von Schlüsseln gleichzeitig abläuft, sodass sie nicht in derselben Reihenfolge sind überhaupt von der Größenordnung.
• ... Zeit. Legen Sie außerdem eine zufällige Ablaufzeit für den Schlüssel fest, um einen zentralen Ablauf von Schlüsseln zu vermeiden. „Hochverfügbarkeit von Redis“ .

Empfohlenes Lernen:

Redis-Lerntutorial

Das obige ist der detaillierte Inhalt vonLassen Sie uns über die drei Caching-Probleme von Redis sprechen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!