1. Anwendung des Redis-Cache
In unseren tatsächlichen Geschäftsszenarien wird Redis im Allgemeinen in Verbindung mit anderen Datenbanken verwendet, um den Druck auf das Back-End zu verringern Datenbank, wie sie beispielsweise in Verbindung mit der relationalen Datenbank MySQL verwendet wird.
Redis speichert häufig abgefragte Daten in MySQL , z. B. Hotspot-Daten, zwischen, sodass beim Zugriff durch Benutzer keine Notwendigkeit besteht Stattdessen werden die zwischengespeicherten Daten in Redis direkt abgerufen, wodurch der Lesedruck auf die Back-End-Datenbank verringert wird.
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 Daten gleichzeitig in Redis, sodass Benutzer beim erneuten Lesen Daten direkt von Redis erhalten können. Das Flussdiagramm lautet wie folgt:
Bei der Verwendung von Redis als Cache-Datenbank werden wir unweigerlich mit drei gemeinsamen Cachings konfrontiert Probleme 🎜#Cache-Aufschlüsselung
Cache-Lawine
- #🎜 🎜 #
2. Cache-Penetration
2.1 Einführung
Cache-Penetration bezieht sich darauf, wann der Benutzer ein bestimmtes Wann abfragt Die Daten werden abgerufen, die Daten sind nicht in Redis vorhanden, das heißt, der Cache wird nicht erreicht. Zu diesem Zeitpunkt wird die Abfrageanforderung an die Persistenzschichtdatenbank MySQL übertragen , und MySQL kann nur ein leeres Objekt zurückgeben, um den Abfragefehler darzustellen. Wenn es viele solcher Anfragen gibt oder Benutzer solche Anfragen für böswillige Angriffe verwenden, wird die MySQL-Datenbank stark belastet und sogar zusammengebrochen. Dieses Phänomen wird als Cache-Penetration bezeichnet.
2.2 Lösung
Leeres Objekt 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, erhält er ein
leeres Objekt
aus dem Cache. Die Anfrage des Benutzers wird in der Cache-Ebene blockiert, wodurch die Back-End-Datenbank geschützt wird Bei diesem Ansatz gibt es auch einige Probleme. Obwohl die Anforderung nicht in MSQL gelangen kann, belegt diese Strategie 
Redis-Cache-Speicherplatz. #? der Hotspot-Daten, auf die Benutzer zugreifen können, werden in Bloom-Filtern gespeichert (auch Cache-Vorwärmung genannt).
Wenn ein Benutzer sie anfordert, durchläuft er zunächst den Bloom-Filter Der angeforderte Schlüssel ist vorhanden.
Wenn er nicht vorhanden ist, wird die Anfrage weiterhin ausgeführt. Wenn der Cache nicht vorhanden ist, gehen Sie zu die abzufragende Datenbank. Im Vergleich zur ersten Methode ist die Verwendung der
Bloom-Filtermethode effizienter und praktischer.
Das Prozessdiagramm sieht wie folgt aus:
Bei der Cache-Vorwärmung werden relevante Daten vorab zwischengespeichert Das System startet den Ladevorgang in das Redis-Cache-System. 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:
Leere Objekte zwischenspeichern: Geeignet für Szenarien, in denen die Anzahl der Schlüssel für leere Daten begrenzt ist und die Wahrscheinlichkeit wiederholter Schlüsselanforderungen hoch ist. 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 dass die vom Benutzer abgefragten Daten nicht im Cache vorhanden sind, sondern in der Back-End-Datenbank. Der Grund für dieses Phänomen liegt im Allgemeinen im Ablauf des Schlüssels im Cache. 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 niemals ablaufen.
Verteilte Sperre
Übernehmen Sie die verteilte Sperrmethode, um die Verwendung des Caches neu zu gestalten. Der Prozess ist wie folgt:
Sperre: Wenn wir Daten nach Schlüssel abfragen, fragen wir zuerst den Cache ab. Wenn nicht, sperren Sie es über eine verteilte Sperre. Der erste Prozess, der die Sperre erhält, betritt die Back-End-Datenbank zur Abfrage und puffert die Abfrageergebnisse in Redis.
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 Vergleich der Lösungen
Läuft nie ab: Da diese Lösung keine echte Ablaufzeit festlegt, gibt es eigentlich keine Reihe von Gefahren durch Hotspot-Schlüssel, aber es kommt zu Dateninkonsistenzen 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 die Gefahr eines Deadlocks Thread-Pool-Blockierung, aber diese Methode kann effizienter sein. Eine gute Methode reduziert die Back-End-Speicherlast und sorgt für eine bessere Konsistenz.
4. Cache-Lawine
4.1 Einführung
Cache-Lawine bedeutet, dass eine große Anzahl von Schlüsseln im Cache gleichzeitig abläuft und zu diesem Zeitpunkt der Datenzugriff sehr groß ist, was zu einem Plötzlicher Druckanstieg auf die Back-End-Datenbank und sogar Hang, dieses Phänomen wird als Cache-Lawine bezeichnet. Es unterscheidet sich von einem 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.
4.2 Lösung
Umgang mit dem Ablauf
Um Cache-Ausfälle und Lawinenprobleme zu reduzieren, die durch eine große Anzahl gleichzeitig ablaufender Schlüssel verursacht werden, können Sie die Strategie anwenden, dass Hotspot-Daten niemals ablaufen Ablauf, was sich von Cache Avalanche unterscheidet Es gibt Ähnlichkeiten. Um zu verhindern, dass Schlüssel gleichzeitig ablaufen, können Sie außerdem eine zufällige Ablaufzeit für sie festlegen.
redis hohe Verfügbarkeit
Ein Redis kann aufgrund einer Lawine hängen bleiben, dann können Sie ein paar weitere Redis hinzufügen und einen Cluster aufbauen.
Das obige ist der detaillierte Inhalt vonBeispielanalyse des Redis-Caching-Problems. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
