Wenn Redis als Cache verwendet wird und der Speicherplatz voll ist, werden alte Daten automatisch gelöscht. Memcached funktioniert standardmäßig auf diese Weise und die meisten Entwickler sind damit vertraut. (Empfohlenes Lernen: Redis-Video-Tutorial)
LRU ist der einzige von Redis unterstützte Recycling-Algorithmus. In diesem Artikel wird die Maxmemory-Anweisung zur Begrenzung der maximalen Speichernutzung ausführlich vorgestellt und ausführlich erläutert was Redis verwendet. Ungefährer LRU-Algorithmus.
maxmemory-Konfigurationsanweisung
maxmemory wird verwendet, um den maximalen Speicher anzugeben, den Redis verwenden kann. Es kann in der Datei redis.conf festgelegt oder während des Betriebs über den Befehl CONFIG SET dynamisch geändert werden.
Um beispielsweise ein Speicherlimit von 100 MB festzulegen, können Sie es in der Datei redis.conf wie folgt konfigurieren:
maxmemory 100mb
Setzen Sie maxmemory auf 0, was bedeutet, dass kein Speicher vorhanden ist Limit. Natürlich gibt es für 32-Bit-Systeme eine implizite Einschränkung: bis zu 3 GB RAM.
Wenn die Speichernutzung die maximale Grenze erreicht und neue Daten gespeichert werden müssen, gibt Redis abhängig von den konfigurierten Richtlinien möglicherweise direkt eine Fehlermeldung zurück oder löscht einige alte Daten.
Räumungsrichtlinie
Wenn das maximale Speicherlimit (maxmemory) erreicht ist, entscheidet Redis über das spezifische Verhalten basierend auf der durch maxmemory-policy konfigurierten Richtlinie.
In der aktuellen Version umfassen die von Redis 3.0 unterstützten Strategien:
noeviction: Löschen Sie die Strategie nicht, wenn das maximale Speicherlimit erreicht ist Es wird mehr Speicher benötigt, direkt Fehlermeldung zurückgeben. Die meisten Schreibbefehle führen dazu, dass mehr Speicher belegt wird (mit seltenen Ausnahmen wie DEL).
allkeys-lru: Für alle Schlüssel gleich; zuerst die zuletzt verwendeten (LRU) Schlüssel löschen.
volatile-lru: Nur auf den Teil beschränkt, in dem „expire“ festgelegt ist; zuerst den zuletzt verwendeten Schlüssel (LRU) löschen.
allkeys-random: Für alle Schlüssel gleich; einige Schlüssel werden nach dem Zufallsprinzip gelöscht.
volatile-random: Nur auf den Teil beschränkt, in dem „expire“ festgelegt ist. Einen Teil des Schlüssels zufällig löschen.
volatile-ttl: Nur begrenzt auf den Teil mit festgelegtem Ablaufdatum; Schlüssel mit kurzer Restlaufzeit (Time to Live, TTL) werden zuerst gelöscht.
Wenn der Ablaufschlüssel nicht festgelegt ist und die Voraussetzungen nicht erfüllt sind, ist das Verhalten der Strategien volatile-lru, volatile-random und volatile-ttl im Grunde dasselbe wie noeviction (kein Löschen).
Sie müssen eine geeignete Räumungsstrategie basierend auf den Merkmalen des Systems auswählen. Natürlich können Sie die Räumungsrichtlinie auch dynamisch über Befehle während des Betriebs festlegen und Cache-Fehler und -Treffer über den INFO-Befehl zur Optimierung überwachen.
Generell gilt:
Bei der Aufteilung in Hot Data und Cold Data wird die Verwendung der Allkeys-LRU-Strategie empfohlen. Das heißt, einige der Schlüssel werden häufig gelesen und geschrieben. Wenn Sie sich über die spezifischen Geschäftsmerkmale nicht sicher sind, ist allkeys-lru eine gute Wahl.
Wenn Sie alle Schlüssel in einer Schleife lesen und schreiben müssen oder die Zugriffshäufigkeit jedes Schlüssels ähnlich ist, können Sie die Allkeys-Random-Strategie verwenden, d. h. die Wahrscheinlichkeit, alle Elemente zu lesen und zu schreiben, beträgt fast gleich.
Wenn Sie möchten, dass Redis Schlüssel, die gelöscht werden müssen, basierend auf TTL filtert, verwenden Sie bitte die Strategie volatile-ttl.
Die Hauptanwendungsszenarien der Strategien „Volatile-Lru“ und „Volatile-Random“ sind: Instanzen mit Cache- und persistenten Schlüsseln. Im Allgemeinen sollten für solche Szenarien zwei separate Redis-Instanzen verwendet werden.
Es ist erwähnenswert, dass das Festlegen von „expire“ zusätzlichen Speicher verbraucht, sodass die Verwendung der allkeys-lru-Strategie den Speicher effizienter nutzen kann, da auf diese Weise die Ablaufzeit nicht mehr festgelegt werden kann.
Die interne Umsetzung der Räumung
Der Räumungsprozess kann folgendermaßen verstanden werden:
Der Client führt einen Befehl aus, Dies führt dazu, dass die Datenmenge von Redis zunimmt und mehr Speicher beansprucht.
Redis überprüft die Speichernutzung, wenn sie das maximale Speicherlimit überschreitet, werden einige Schlüssel gemäß der Richtlinie gelöscht.
Fahren Sie mit dem nächsten Befehl fort und so weiter.
Während dieses Vorgangs wird die Speichernutzung kontinuierlich den Grenzwert erreichen, ihn dann überschreiten und dann einige Schlüssel löschen, und die Nutzung wird wieder unter den Grenzwert fallen.
Wenn ein bestimmter Befehl eine große Speichernutzung verursacht (z. B. das Speichern eines großen Satzes über einen neuen Schlüssel), kann die Speichernutzung für einen bestimmten Zeitraum das maximale Speicherlimit erheblich überschreiten.
Ungefährer LRU-Algorithmus
Redis verwendet nicht den vollständigen LRU-Algorithmus. Der automatisch entfernte Schlüssel ist nicht unbedingt derjenige, der die LRU-Eigenschaften am besten erfüllt. Stattdessen wird eine kleine Anzahl von Schlüsselproben durch den ungefähren LRU-Algorithmus extrahiert und dann der Schlüssel mit der ältesten Zugriffszeit gelöscht.
Der Räumungsalgorithmus wurde seit Redis 3.0 stark optimiert und verwendet Pool als Kandidaten. Dies verbessert die Algorithmuseffizienz erheblich und kommt dem echten LRU-Algorithmus näher.
Im LRU-Algorithmus von Redis kann die Genauigkeit des Algorithmus durch Festlegen der Anzahl der Stichproben optimiert werden. Konfigurieren Sie über den folgenden Befehl:
maxmemory-samples 5
Warum nicht die vollständige LRU-Implementierung verwenden? Der Grund ist, Speicher zu sparen. Das Verhalten von Redis entspricht jedoch grundsätzlich dem von LRU. Das Folgende ist eine Verhaltensvergleichstabelle zwischen Redis LRU und dem vollständigen LRU-Algorithmus.
Während des Testvorgangs beginnt der Zugriff mit dem ersten Schlüssel, sodass der erste Schlüssel das beste Räumungsobjekt ist.
Auf dem Bild sind drei Arten von Punkten zu sehen, die drei verschiedene Streifen bilden.
Der hellgraue Teil zeigt das geräumte Objekt an.
Der graue Teil stellt „nicht geräumte“ Objekte dar.
Der grüne Teil zeigt die später hinzugefügten Objekte an.
Bei der reinen LRU-Algorithmus-Implementierung wird die erste Hälfte des alten Schlüssels freigegeben. Der LRU-Algorithmus von Redis gibt längere Schlüssel nur probabilistisch frei.
Wie Sie sehen können, ist der Effekt von 5 Samples in Redis 3.0 viel besser als der von Redis 2.8. Natürlich ist Redis 2.8 auch gut, der zuletzt aufgerufene Schlüssel befindet sich grundsätzlich noch im Speicher. Bei Verwendung von 10 Samples in Redis 3.0 kommt es dem reinen LRU-Algorithmus sehr nahe.
Beachten Sie, dass LRU nur ein Wahrscheinlichkeitsmodell ist, das verwendet wird, um vorherzusagen, dass auf einen bestimmten Schlüssel in Zukunft weiterhin zugegriffen werden kann. Wenn die Datenzugriffssituation außerdem einer Potenzgesetzverteilung entspricht, gilt für die meisten Anfragen: LRU wird eine gute Leistung erbringen.
In der Simulation haben wir festgestellt, dass bei Verwendung des Potenzgesetzzugriffs die Ergebnisse von reinem LRU und Redis sehr unterschiedlich oder sogar unsichtbar sind.
Natürlich können Sie die Anzahl der Stichproben auch auf 10 erhöhen, allerdings auf Kosten der zusätzlichen CPU-Belastung, sodass die Ergebnisse näher an der tatsächlichen LRU liegen und der Unterschied anhand der Cache-Miss-Statistiken beurteilt werden kann .
Es ist einfach, die Stichprobengröße festzulegen, indem Sie den Befehl CONFIG SET maxmemory-samples
Weitere technische Artikel zu Redis finden Sie im Redis Getting Started Tutorial Kolumne Fang an zu lernen!
Das obige ist der detaillierte Inhalt vonWo kann man die Cache-Bereinigungsrichtlinie in Redis konfigurieren?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!