1. Vorteile und Kosten des Cachings
1.1 Vorteile
Beschleunigtes Lesen und Schreiben: Da Caches normalerweise vollen Speicher haben (z. B. Redis, Memcache) und die Speicherschicht normalerweise nicht über eine unzureichende Lese- und Schreibleistung verfügt (z. B wie MySQL) ist die Geschwindigkeit des Speicherlesens und -schreibens viel höher als die der Festplatten-E/A. Die Verwendung von Cache kann das Lesen und Schreiben effektiv beschleunigen und das Benutzererlebnis optimieren.
Back-End-Last reduzieren: Helfen Sie dem Back-End, die Zugriffsmenge zu reduzieren (Mysql ist auf eine maximale Anzahl von Verbindungen eingestellt. Wenn eine große Anzahl von Zugriffen gleichzeitig die Datenbank und die Festplatte erreichen Die E/A-Geschwindigkeit ist sehr langsam, was leicht dazu führen kann, dass die maximale Anzahl an Verbindungen ausgeschöpft wird, aber Redis ist theoretisch die größte) und komplexe Berechnungen (z. B. sehr komplexe SQL-Anweisungen) durchführen, was die Belastung erheblich reduziert Backend. 1.2 Kosten
Code-Wartungskosten:
Nach dem Hinzufügen des Caches müssen die Logik der Cache-Schicht und der Speicherschicht gleichzeitig verarbeitet werden, was die Kosten für die Wartung des Codes für Entwickler erhöht. -
Betriebs- und Wartungskosten: Nehmen Sie Redis Cluster als Beispiel. Nach dem Beitritt erhöhen sich die Betriebs- und Wartungskosten virtuell. 1.3 Nutzungsszenarien
Komplexe Berechnungen mit hohem Overhead: Nehmen Sie MySQL als Beispiel (z. B. eine große Anzahl gemeinsamer Tabellenoperationen, einige Gruppierungsberechnungen) ohne Zwischenspeicherung Eine hohe Parallelität ist nicht nur unbefriedigend, sondern stellt auch eine enorme Belastung für MySQL dar.
Beschleunigen Sie die Antwort auf Anfragen:
Auch wenn die Abfrage eines einzelnen Backend-Datenelements schnell genug ist, können Sie den Cache dennoch verwenden. Redis kann als Beispiel Zehntausende Lese- und Schreibvorgänge pro Sekunde durchführen Die bereitgestellten Batch-Operationen können die Reaktionszeit der gesamten E/A-Kette optimieren nach einer Weile verschwunden sein. Was ist der Grund? Normalerweise wird der Redis-Cache im Speicher gespeichert, aber da Speicher kostbar und begrenzt ist, werden häufig billige und große Festplatten zur Speicherung verwendet. Eine Maschine verfügt möglicherweise nur über ein paar Dutzend Gigabyte Arbeitsspeicher, kann aber über mehrere Terabyte Festplattenkapazität verfügen. Redis basiert hauptsächlich auf Speicher, um leistungsstarke Lese- und Schreibvorgänge mit hoher Parallelität durchzuführen. Da der Speicher beispielsweise begrenzt ist, kann Redis nur 10 GB verwenden. Was werden Sie tun, wenn Sie 20 GB Daten hineinschreiben? Natürlich werden die 10G-Daten gelöscht und dann bleiben die 10G-Daten erhalten. Welche Daten müssen gelöscht werden? Welche Daten müssen aufbewahrt werden? Natürlich müssen Sie selten verwendete Daten löschen und häufig verwendete Daten aufbewahren. Die Ablaufrichtlinie von Redis legt fest, dass die Daten auch dann weiterhin Speicher belegen, wenn sie abgelaufen sind. Wenn in Redis der verwendete Speicher die Obergrenze des maximalen Speichers (used_memory>maxmemory) erreicht, wird die entsprechende Überlaufkontrollstrategie ausgelöst. Die spezifische Richtlinie wird durch den Parameter maxmemory-policy gesteuert.
- Redis unterstützt 6 Strategien:
noeviction: Die Standardstrategie, die keine Daten löscht, alle Schreibvorgänge ablehnt und die Client-Fehlermeldung (Fehler) zurückgibt. OOM-Befehl ist derzeit bei belegtem Speicher nicht zulässig Redis reagiert nur auf Lesevorgänge
Löschen Sie gemäß dem LRU-Algorithmus Schlüsselwerte mit Timeout-Attributen (Ablauf) und geben Sie ausreichend Speicherplatz frei. Wenn kein löschbares Schlüsselobjekt vorhanden ist, greifen Sie auf die Noeviction-Strategie zurück.
volatile-random: Abgelaufene Schlüssel nach dem Zufallsprinzip löschen, bis genügend Platz geschaffen ist.
allkeys-lru: Schlüssel gemäß dem LRU-Algorithmus löschen, unabhängig davon, ob Es sind Daten vorhanden oder nicht. Timeout-Eigenschaft festlegen, bis genügend Platz geschaffen ist.
allkeys-random: Alle Schlüssel nach dem Zufallsprinzip löschen, bis genügend Platz geschaffen ist (nicht empfohlen).
volatile-ttl: Basierend auf dem TTL (verbleibende Zeit). Löschen Sie im Attribut des Schlüsselwertobjekts (Lebensdauer, TTL) die Daten, die kürzlich ablaufen. Wenn nicht, greifen Sie auf die Noeviction-Strategie zurück mit dem Zeitstempel, der von den vorhandenen Cache-Elementen am weitesten von der aktuellen Zeit entfernt ist, werden aus dem Cache gelöscht.
2.2 Ablaufstrategie
- Die vom Redis-Server übernommene Ablaufstrategie ist: verzögertes Löschen + reguläres Löschen
Verzögertes Löschen: -
Jede Redis-Bibliothek enthält ein Ablaufwörterbuch, das die Ablaufzeit aller Schlüssel speichert. Wenn der Client einen Schlüssel liest, prüft er zunächst, ob der Schlüssel im Ablaufwörterbuch abgelaufen ist. Wenn der Schlüssel abgelaufen ist, führt er einen Löschvorgang durch und gibt leer zurück. Mit dieser Strategie sollen CPU-Kosten gespart werden. Bei alleiniger Verwendung dieser Methode besteht jedoch das Problem eines Speicherverlusts. Wenn nicht auf den abgelaufenen Schlüssel zugegriffen wird, wird er nicht rechtzeitig gelöscht, was dazu führt, dass der Speicher nicht rechtzeitig freigegeben wird.
Geplantes Löschen:
Redis verwaltet intern eine geplante Aufgabe. Standardmäßig werden 10 Ablaufscans pro Sekunde ausgeführt (die Anzahl der Läufe wird durch die Hz-Konfiguration in redis.conf geändert). Stattdessen wird ein adaptiver Algorithmus verwendet, um Schlüssel basierend auf dem Ablaufverhältnis der Schlüssel und unter Verwendung von zwei Geschwindigkeitsmodi zu recyceln:
1. Entnehmen Sie zufällig 20 Schlüssel aus dem abgelaufenen Wörterbuch.
2 20 Schlüssel
3 .Wenn der Anteil der abgelaufenen Schlüssel 25 % überschreitet, wiederholen Sie die Schritte 1 und 2
Um sicherzustellen, dass der Scan keinen übermäßigen Zyklus aufweist, wurden geplante Löschaufgaben ausgeführt und können keine Dienste für den Scan bereitstellen Außenwelt, was dazu führt, dass der Thread hängen bleibt und die Scanzeit zunimmt. Die Obergrenze beträgt standardmäßig 25 Millisekunden (d. h. im langsamen Modus wird standardmäßig in den Blockmodus gewechselt. Das Zeitlimit im Modus ist 1 Millisekunde und kann nur einmal in 2 Sekunden ausgeführt werden, wird normal beendet und wechselt zurück in den Schnellmodus)
3. Anwendungsaktualisierung
1 Ruft zuerst die Daten aus dem Cache ab. Wenn sie nicht abgerufen werden, werden die Daten aus der Datenbank abgerufen. Nach Erfolg werden sie in den Cache gelegt.
2. Löschen Sie zuerst den Cache und aktualisieren Sie dann die Datenbank: Nach dem Löschen des Caches wird eine Leseanforderung zum Aktualisieren der Daten empfangen direkt gelesen werden. Die Daten für den Lesevorgang sind alt und werden in den Cache geladen. Nachfolgende Leseanforderungen greifen auf alle alten Daten zu.
3. Aktualisieren Sie zuerst die Datenbank und löschen Sie dann den Cache (empfohlen). Der Hauptgrund besteht darin, dass zwei gleichzeitige Schreibvorgänge zu fehlerhaften Daten führen können.
4. Cache-Granularität
1 Vielseitigkeit
Das Zwischenspeichern aller Daten ist vielseitiger als Teildaten, aber erfahrungsgemäß erfordern Anwendungen über einen langen Zeitraum nur wenige wichtige Attribute.
2 Platzbedarf
Das Zwischenspeichern aller Daten nimmt mehr Platz in Anspruch als Teildaten. Es gibt die folgenden Probleme:
Alle Daten führen zu einer Speicherverschwendung.
Alle Daten können jedes Mal eine große Menge Netzwerkverkehr erzeugen, relativ lange dauern und im Extremfall das Netzwerk blockieren.
Der CPU-Overhead für die Serialisierung und Deserialisierung aller Daten ist größer.
3 Codepflege
Vollständige Daten haben offensichtliche Vorteile, aber wenn Sie einigen Daten neue Felder hinzufügen möchten, müssen Sie den Geschäftscode ändern und normalerweise die zwischengespeicherten Daten aktualisieren.
Das obige ist der detaillierte Inhalt vonWas ist die Redis-Cache-Update-Strategie?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
