Leitfaden zur Auswahl effektiver Redis-Räumungsrichtlinien

Redis ist schnell, weil es Daten im Speicher hält, aber der Speicher ist begrenzt. Wenn Ihre Redis-Instanz maxmemory erreicht, entscheidet die Räumungsrichtlinie, ob Redis Schlüssel entfernt, Schreibvorgänge ablehnt oder nur Schlüssel mit einer Ablaufzeit räumt.

Die Auswahl einer effektiven Redis-Räumungsrichtlinie ist am wichtigsten, wenn Redis als Cache, Sitzungsspeicher oder gemischter Datenspeicher fungiert. Die falsche Richtlinie kann wichtige Schlüssel räumen oder Schreibvorgänge während eines Verkehrsspitzenwerts fehlschlagen lassen.

---

Grundlegendes zu Redis-Räumung und maxmemory

Räumungsrichtlinien kommen nur dann zum Tragen, wenn die Redis-Speichernutzung das mit der Konfigurationsdirektive maxmemory festgelegte Limit überschreitet. Wenn maxmemory nicht gesetzt oder auf 0 gesetzt ist, wendet Redis kein Speicherlimit für normale Schreibvorgänge an. Auf einem dedizierten Host kann dies schließlich zu Speicherdruck des Betriebssystems führen, daher legen Produktions-Cache-Bereitstellungen normalerweise ein explizites Limit fest.

Um die Räumung zu aktivieren, müssen Sie maxmemory in Ihrer redis.conf-Datei oder über den Befehl CONFIG SET konfigurieren:

# Setzen Sie maxmemory auf 2 GB
CONFIG SET maxmemory 2gb

Sobald der Speicher begrenzt ist, verwendet Redis die konfigurierte Räumungsrichtlinie, um zu entscheiden, welche Schlüssel verworfen werden sollen, wenn ein Schreibbefehl mehr Speicher benötigt.

Die integrierten Redis-Räumungsrichtlinien

Redis bietet mehrere verschiedene Richtlinien. Diese werden mit der Direktive maxmemory-policy konfiguriert. Die Richtlinien fallen im Allgemeinen in zwei Kategorien: solche, die auf Least Recently Used (LRU) oder Least Frequently Used (LFU) basieren, und solche, die auf Schlüssel mit Time To Live (TTL) abzielen.

1. Richtlinien ohne TTL-Anforderungen

Diese Richtlinien gelten für alle Schlüssel in der Datenbank, unabhängig davon, ob für sie eine Ablaufzeit festgelegt ist.

noeviction

Dies ist die Standardrichtlinie. Wenn das Speicherlimit erreicht ist, lehnt Redis Schreibbefehle (wie SET, LPUSH usw.) ab und gibt einen Fehler an den Client zurück. Lesevorgänge (GET) sind weiterhin erlaubt. Dies ist oft für unternehmenskritische Daten geeignet, bei denen Datenverlust inakzeptabel ist, kann jedoch bei hohem Schreibdruck zu Anwendungsfehlern führen.

allkeys-lru

Räumt die am wenigsten zuletzt verwendeten Schlüssel unter allen Schlüsseln in der Datenbank, bis die Speichernutzung unter dem maxmemory-Limit liegt. Dies ist die Standardwahl für einen allgemeinen Cache, bei dem alle Datenobjekte gleichermaßen cachebar sind.

allkeys-lfu

Räumt die am wenigsten häufig verwendeten Schlüssel unter allen Schlüsseln. LFU priorisiert das Behalten von Schlüsseln, die oft zugegriffen werden, auch wenn sie nicht kürzlich zugegriffen wurden. Dies ist effektiv, wenn Zugriffsmuster volatil sind, aber sehr beliebte Elemente möglicherweise auf unbestimmte Zeit resident bleiben.

allkeys-random

Räumt zufällig ausgewählte Schlüssel, bis das Speicherlimit erfüllt ist. Dies wird selten für Produktions-Caches empfohlen, es sei denn, das Datenzugriffsmuster ist vollständig gleichmäßig und unvorhersehbar.

2. Richtlinien, die TTL erfordern (flüchtige Schlüssel)

Diese Richtlinien berücksichtigen nur Schlüssel, die eine explizite Ablaufzeit (EXPIRE oder SETEX) haben. Sie ignorieren nicht ablaufende Schlüssel bei der Durchführung der Räumung.

volatile-lru

Räumt die am wenigsten zuletzt verwendeten Schlüssel unter denen, die eine Ablaufzeit haben.

volatile-lfu

Räumt die am wenigsten häufig verwendeten Schlüssel unter denen, die eine Ablaufzeit haben.

volatile-random

Räumt einen zufälligen Schlüssel unter denen, die eine Ablaufzeit haben.

volatile-ttl

Räumt zuerst den Schlüssel mit der kürzesten verbleibenden Time to Live (TTL). Dies ist ideal für zeitkritische Daten wie Sitzungstoken oder temporären Anwendungsstatus, um sicherzustellen, dass ältere, bald ablaufende Daten zuerst bereinigt werden.

---

Auswahl der richtigen Richtlinie für Ihren Workload

Die optimale Räumungsrichtlinie hängt vollständig davon ab, was Sie cachen und wie Ihre Anwendung die Daten verwendet.

Workload-Typ	Empfohlene Richtlinie	Begründung
Allgemeiner Cache (am häufigsten)	allkeys-lru	Geht davon aus, dass ältere, ungenutzte Daten zuerst entfernt werden sollten, unabhängig von der TTL. Einfach und hochwirksam.
Zeitkritische Daten (z. B. Token, kurzlebige Sitzungen)	volatile-ttl	Räumt bevorzugt Schlüssel mit der kürzesten verbleibenden TTL.
Hot-Data-Cache (Hohe Zugriffsverzerrung)	allkeys-lfu oder volatile-lfu	Schützt häufig zugegriffene Elemente davor, aufgrund kürzlicher Inaktivität geräumt zu werden.
Verbindliche Datenaufbewahrung (Kein Verlust erlaubt)	noeviction	Verhindert Datenverlust, indem Schreibvorgänge mit Fehlern abgelehnt werden, was manuelles Eingreifen oder die Behandlung durch die vorgelagerte Anwendung erfordert.
Gemischte Workloads (Einige Daten laufen ab, andere nicht)	volatile-lru, volatile-lfu oder volatile-ttl	Wenn Ihre nicht ablaufenden Schlüssel wesentlich sind, verwenden Sie eine flüchtige Richtlinie, um sie zu schützen, indem Sie nur explizit ablaufende Schlüssel räumen.

Praktisches Beispiel: Implementierung eines Sitzungsspeichers

Wenn Redis hauptsächlich zum Speichern von Benutzersitzungen verwendet wird, setzen Sie für jeden Sitzungsschlüssel eine explizite TTL, z. B. 30 Minuten. volatile-ttl kann funktionieren, wenn die verbleibende Lebensdauer das wichtigste Signal ist. Wenn Ihre Anwendung Sitzungs-TTLs bei Aktivität aktualisiert, behalten aktive Sitzungen auf natürliche Weise eine längere verbleibende TTL. Wenn sie keine TTLs aktualisiert, ziehen Sie stattdessen volatile-lru oder volatile-lfu in Betracht.

# 1. Setzen Sie maxmemory (z. B. 10 GB)
CONFIG SET maxmemory 10gb

# 2. Wählen Sie die Richtlinie, die auf Time-to-Live-Daten abzielt
CONFIG SET maxmemory-policy volatile-ttl

Praktisches Beispiel: Implementierung eines HTTP-Caches

Zum Cachen vollständiger HTTP-Antworten (die möglicherweise nicht immer eine TTL haben) möchten Sie die Daten behalten, auf die am häufigsten zugegriffen wird, auch wenn diese Daten einige Stunden unberührt waren. allkeys-lru oder allkeys-lfu sind ideal.

# Verwenden Sie LFU, um wirklich 'heiße' Objekte zu behalten, unabhängig von ihrer Erstellungszeit
CONFIG SET maxmemory-policy allkeys-lfu

Überwachung und Optimierung

Nach der Auswahl einer Richtlinie ist eine kontinuierliche Überwachung unerlässlich. Sie sollten die folgenden Metriken über den Befehl INFO verfolgen:

• used_memory: Wie nah Sie am maxmemory-Limit sind.
• evicted_keys: Die Rate, mit der Redis Daten verwirft. Eine konstant hohe Räumungsrate zeigt an, dass Ihre maxmemory-Einstellung für Ihren Workload zu niedrig ist oder Ihre Räumungsrichtlinie zu aggressiv ist.
• Anwendungs-Cache-Trefferquote: Das ultimative Erfolgsmaß. Wenn Ihre Trefferquote bei steigendem Speicherdruck sinkt, müssen Ihre Richtlinienauswahl oder Ihr maxmemory-Limit angepasst werden.

Best Practice: Lassen Sie beim Optimieren von maxmemory immer einen Sicherheitspuffer (z. B. 10-20 % freien Speicher), um Replikationspufferung, Befehlspufferung und potenziellen Overhead durch die internen Datenstrukturen von Redis zu berücksichtigen.

Abschließende Erkenntnis

Beginnen Sie mit allkeys-lru für einen allgemeinen Cache, allkeys-lfu, wenn eine kleine Menge heißer Schlüssel den Verkehr dominiert, und einer volatile-*-Richtlinie nur, wenn nicht ablaufende Schlüssel geschützt werden müssen. Beobachten Sie dann evicted_keys, die Anwendungstrefferquote und Schreibfehler unter Last, bevor Sie die Richtlinie als abgeschlossen betrachten.