Leitfaden zur Auswahl effektiver Redis-Eviction-Policies

Redis ist bekannt für seine Geschwindigkeit, die hauptsächlich auf seiner In-Memory-Natur beruht. Wenn Ihr Datensatz jedoch größer wird als der verfügbare physische Speicher, muss Redis proaktiv ältere oder weniger kritische Daten entfernen, um Platz für neue Einträge zu schaffen. Dieser Prozess wird durch Eviction Policies (Entfernungsrichtlinien) verwaltet, die entscheidend für die Aufrechterhaltung der Leistung und die Gewährleistung eines optimalen Cache-Betriebs sind. Die Wahl der richtigen Richtlinie wirkt sich direkt auf die Cache-Hit-Raten, die Latenz und die Speichernutzung aus.

Dieser Leitfaden untersucht die verschiedenen integrierten Redis-Eviction-Policies, erklärt, wie jede funktioniert, und gibt praktische Ratschläge zur Auswahl der effektivsten Strategie für verschiedene Anwendungs-Workloads, von reinen Caching-Szenarien bis hin zur Verwaltung von Zeitreihendaten.

---

Verständnis von Redis Eviction und maxmemory

Eviction-Policies kommen erst zum Tragen, wenn die Redis-Speichernutzung das durch die maxmemory-Konfigurationsdirektive festgelegte Limit überschreitet. Wenn maxmemory nicht gesetzt ist (oder auf 0 gesetzt ist), verwendet Redis den gesamten verfügbaren Speicher, und es findet keine Entnahme statt, was potenziell zu Systeminstabilität führen kann, wenn der Host-Computer keinen RAM mehr hat.

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

# Setze maxmemory auf 2GB
CONFIG SET maxmemory 2gb

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

Die integrierten Redis Eviction Policies

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

1. Richtlinien ohne TTL-Anforderungen

Diese Richtlinien operieren auf allen Schlüsseln 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 dem Client einen Fehler zurück. Lesezugriffe (GET) sind weiterhin erlaubt. Dies ist oft für geschäftskritische Daten geeignet, bei denen Datenverlust nicht akzeptabel ist, kann aber unter hohem Schreibdruck zu Anwendungsfehlern führen.

allkeys-lru

Entfernt die am wenigsten kürzlich 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 Allzweck-Cache, bei dem alle Datenelemente gleichermaßen cachebar sind.

allkeys-lfu

Entfernt die am seltensten verwendeten Schlüssel unter allen Schlüsseln. LFU priorisiert das Beibehalten von Schlüsseln, auf die häufig zugegriffen wird, auch wenn nicht kürzlich darauf zugegriffen wurde. Dies ist effektiv, wenn Zugriffsmuster volatil sind, aber sehr beliebte Elemente können auf unbestimmte Zeit im Speicher verbleiben.

allkeys-random

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

2. Richtlinien, die TTL erfordern (Volatile Keys)

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

volatile-lru

Entfernt die am wenigsten kürzlich verwendeten Schlüssel unter denjenigen, die eine Ablaufzeit haben.

volatile-lfu

Entfernt die am seltensten verwendeten Schlüssel unter denjenigen, die eine Ablaufzeit haben.

volatile-random

Entfernt einen zufälligen Schlüssel unter denjenigen, die eine Ablaufzeit haben.

volatile-ttl

Entfernt zuerst den Schlüssel mit der kürzesten verbleibenden Lebensdauer (TTL). Dies ist ideal für zeitkritische Daten wie Sitzungstoken oder temporären Anwendungszustand und stellt sicher, dass ältere, bald ablaufende Daten zuerst bereinigt werden.

---

Auswahl der richtigen Richtlinie für Ihren Workload

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

Workload-Typ	Empfohlene Policy	Begründung
Allzweck-Cache (Am häufigsten)	allkeys-lru	Geht davon aus, dass ältere, ungenutzte Daten zuerst entfernt werden sollten, unabhängig von der TTL. Einfach und sehr effektiv.
Zeitkritische Daten (z. B. Token, kurzlebige Sitzungen)	volatile-ttl	Garantiert, dass Schlüssel, die sich dem Ablauf nähern, effizient bereinigt werden, bevor sie tatsächlich ablaufen.
Hot Data Cache (Hohe Zugriffsschiefe)	allkeys-lfu oder volatile-lfu	Schützt häufig aufgerufene Elemente davor, aufgrund von Inaktivität verdrängt zu werden.
Zwingende Datenspeicherung (Kein Verlust erlaubt)	noeviction	Verhindert Datenverlust durch Fehler bei Schreibvorgängen, was manuelle Eingriffe oder Handhabung der Upstream-Anwendung erfordert.
Gemischte Workloads (Einige Daten laufen ab, andere nicht)	volatile-lru oder volatile-ttl	Wenn Ihre nicht ablaufenden Schlüssel essentiell sind, verwenden Sie eine volatile Richtlinie, um sie zu schützen, indem Sie nur explizit ablaufende Schlüssel entfernen.

Praktisches Beispiel: Implementierung eines Session Stores

Wenn Redis hauptsächlich zur Speicherung von Benutzersitzungen verwendet wird, würden Sie normalerweise eine explizite TTL für jeden Sitzungsschlüssel festlegen (z. B. 30 Minuten) und eine Richtlinie verwenden, die TTLs berücksichtigt. volatile-ttl ist hier oft überlegen, denn wenn eine Sitzung intensiv genutzt wird, sollte sie nicht einfach verdrängt werden, nur weil sie etwas älter ist als eine andere Sitzung, die seit Wochen nicht mehr angefasst wurde.

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

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

Praktisches Beispiel: Implementierung eines HTTP-Caches

Beim Caching vollständiger HTTP-Antworten (bei denen möglicherweise nicht immer eine TTL gesetzt ist) möchten Sie die am häufigsten aufgerufenen Daten beibehalten, auch wenn diese Daten seit einigen Stunden unberührt liegen. allkeys-lru oder allkeys-lfu sind ideal.

# LFU verwenden, um wirklich "heiße" Objekte beizubehalten, unabhängig von ihrer Erstellungszeit
CONFIG SET maxmemory-policy allkeys-lfu

Monitoring und Tuning

Nach der Auswahl einer Richtlinie ist kontinuierliches Monitoring unerlässlich. Sie sollten die folgenden Metriken über den INFO-Befehl verfolgen:

• used_memory: Wie nahe Sie dem maxmemory-Limit sind.
• evicted_keys: Die Rate, mit der Redis Daten verwirft. Eine konstant hohe Eviction-Rate deutet darauf hin, dass Ihre maxmemory-Einstellung für Ihren Workload zu niedrig ist oder Ihre Eviction-Policy übermäßig aggressiv ist.
• Anwendungscache-Hitrate: Das ultimative Erfolgsmaß. Wenn Ihre Hitrate sinkt, wenn der Speicher unter Druck gerät, müssen Ihre Richtlinienauswahl oder Ihr maxmemory-Limit angepasst werden.

Best Practice: Beim Tuning von maxmemory immer einen Sicherheits Puffer (z. B. 10-20 % freien Speicher) lassen, um Replikationspufferung, Befehlspufferung und potenzielle Overhead von Redis' internen Datenstrukturen zu berücksichtigen.

Fazit

Redis Eviction-Policies bieten eine feingranulare Kontrolle darüber, wie sich Ihr Cache unter Speicherdruck verhält. Es gibt keine einzelne "beste" Richtlinie; die Wahl zwischen LRU-, LFU- oder TTL-basierter Eviction muss genau mit Ihren Datenzugriffsmustern und Geschäftsanforderungen übereinstimmen. Durch die sorgfältige Auswahl der geeigneten Richtlinie – wie z. B. allkeys-lru für allgemeines Caching oder volatile-ttl für Session Stores – können Sie die Cache-Effizienz maximieren und eine robuste Leistung für Ihre Hochgeschwindigkeits-Datenoperationen gewährleisten.