1. Cache-Penetration
Cache-Penetration bedeutet, dass die vom Client angeforderten Daten nicht im Cache oder in der Datenbank vorhanden sind, sodass der Cache niemals wirksam wird und diese Anforderungen in der Datenbank niedergeschlagen werden.
Das heißt, diese Daten existieren überhaupt nicht. Wenn ein Hacker viele Threads startet und weiterhin Anfragen für diese nicht vorhandenen Daten sendet, wird die Anfrage immer an die Datenbank gesendet, wodurch die Datenbank leicht zerstört wird.
Lösung:
1. Leere Objekte zwischenspeichern
Vorteile: einfache Implementierung, einfache Wartung
Nachteile: Zusätzlicher Speicherverbrauch, da einige leere Objekte, die zufälligen IDs entsprechen, zwischengespeichert werden. Dies kann jedoch durch Festlegen von TTL für das Objekt gelöst werden, führt jedoch zu kurzfristigen Dateninkonsistenzen
2. Bloom-Filter
Vorteile: weniger Speicherverbrauch
Nachteile: komplexe Umsetzung, Fehleinschätzung
3. Sonstiges
Verwenden Sie den Bitmap-Typ, um die Zugriffs-Whitelist zu definieren, oder führen Sie eine Echtzeitüberwachung durch und arbeiten Sie mit dem Betriebs- und Wartungspersonal zusammen, um die Zugriffsobjekte und Zugriffsdaten zu überprüfen und den Blacklist-Beschränkungsdienst festzulegen
2. Cache-Aufschlüsselung
Cache-Aufschlüsselung bezieht sich darauf, dass ein Hotspot-Schlüssel zu einem bestimmten Zeitpunkt abläuft und zu diesem Zeitpunkt eine große Anzahl gleichzeitiger Anforderungen für diesen Schlüssel vorliegt, sodass eine große Anzahl von Anforderungen die Datenbank erreicht, was häufig vorkommt. Hotspot-Problem
Lösung:
1. Stellen Sie beliebte Daten vorein und speichern Sie sie im Voraus im Cache
2. Überwachen Sie beliebte Daten in Echtzeit und passen Sie die Ablaufzeit der Schlüssel an
3. Cache der zweiten Ebene: Cache der zweiten Ebene für heiße Daten und unterschiedliche Ablaufzeiten für verschiedene Cache-Ebenen festlegen.
4. Legen Sie verteilte Sperren fest
3. Cache-Lawine
Eine große Anzahl von Anwendungsanforderungen kann nicht im Redis-Cache verarbeitet werden, und dann sendet die Anwendung eine große Anzahl von Anforderungen an die Datenbankschicht, wodurch der Druck auf die Datenbankschicht stark ansteigt
Der Unterschied zwischen Panne und Avalanche besteht darin, dass die Panne für bestimmte Hotspot-Daten gilt, während Avalanche für alle Daten gilt.
Grund 1: Eine große Anzahl von Schlüsseln im Cache läuft gleichzeitig ab, was dazu führt, dass eine große Anzahl von Anforderungen nicht verarbeitet werden kann und eine große Datenmenge an die Quelldatenbank zurückgegeben werden muss
Lösung 1: Stellen Sie die Ablaufzeit
unterschiedlich ein. Differenzieren Sie die Cache-Ablaufzeit und lassen Sie nicht zu, dass eine große Anzahl von Schlüsseln gleichzeitig abläuft. Wenn Sie beispielsweise den Cache initialisieren, fügen Sie der Ablaufzeit dieser Daten eine kleine Zufallszahl hinzu, sodass die Ablaufzeit verschiedener Daten unterschiedlich, aber nicht sehr unterschiedlich ist, sodass vermieden wird, dass eine große Datenmenge gleichzeitig abläuft und sicherstellen, dass diese Daten zu einem ähnlichen Zeitpunkt abgelaufen sind
Option 2: Service-Downgrade
Ermöglicht dem Kerngeschäft den Zugriff auf die Datenbank. Nicht zum Kerngeschäft gehörende Unternehmen geben vordefinierte Informationen direkt zurück
Lösung 3: Stellen Sie
den Cache so ein, dass er beim Initialisieren der Cache-Daten nie abläuft, ohne die Ablaufzeit festzulegen, und starten Sie dann einen Hintergrundthread, um alle 30 Sekunden alle Daten im Cache zu aktualisieren, und steuern Sie die Häufigkeit der Aktualisierung der Daten aus der Datenbank durch geeignete Maßnahmen Schlafen Sie, um den Druck auf die Datenbank zu verringern.
Grund 2: Die Redis-Instanz fällt aus und ist nicht in der Lage, Anfragen zu verarbeiten, was zu einem Rückstand einer großen Anzahl von Anfragen auf der Datenbankebene führt
Szenario 1: Service-Fusing
Unterbricht den Zugriff von Geschäftsanwendungen auf Cache-Dienste und verringert so den Druck auf die Datenbank
Option 2 Anforderungsstrombegrenzung:
Steuern Sie die Anzahl der Anforderungen, die pro Sekunde in die Anwendung eingehen, um zu vermeiden, dass zu viele Anforderungen an die Datenbank gesendet werden
Lösung 3 Redis baut einen hochzuverlässigen Cluster auf.
Erstellen Sie einen hochzuverlässigen Redis-Cluster mithilfe von Master-Slave-Knoten. Es kann sicherstellen, dass bei einem Ausfall des Redis-Masterknotens und einer Ausfallzeit der Slave-Knoten zum Masterknoten wechselt und weiterhin Dienste bereitstellt, wodurch die durch die Ausfallzeit der Cache-Instanz verursachte Cache-Lawine vermieden wird