Seite 3 - Redis

Ein wachsendes Redis Cluster verlangt früher oder später, Hash Slots zwischen Knoten zu verschieben, neue Knoten aufzunehmen oder alte zu entfernen, alles während die Anwendung ununterbrochen weiterläuft. redis-cli --cluster reshard orchestriert diesen Vorgang über den MIGRATING- und IMPORTING-Zustand einzelner Slots und macht Resharding zu einer kontrollierten, live durchführbaren Operation statt eines Wartungsfensters.

Bevor ein zusaetzliches Monitoring-Tool installiert wird, lohnt sich der Blick auf das, was Redis von Haus aus liefert: Der INFO-Befehl und redis-cli allein liefern Memory-Statistiken, Hit-Rate, Replikationsstatus und Live-Latenzmessung in einer Tiefe, die fuer die meisten Betriebsszenarien vollstaendig ausreicht, wenn man weiss, wo man hinschauen muss.

RDB und AOF lösen dasselbe Grundproblem, den Verlust von Daten im Speicher bei einem Absturz, mit vollkommen unterschiedlichen Kompromissen zwischen Recovery-Zeit, Datenverlust-Fenster und Ressourcenbedarf. Wer beide Mechanismen versteht und weiß, wann sich die Kombination aus RDB und AOF lohnt, trifft eine Persistenz-Entscheidung, die zum tatsächlichen Anwendungsfall passt, statt sich auf Standardwerte zu verlassen.

Persistence-Mechanismen wie RDB und AOF schützen vor einem Prozess-Crash, aber nicht vor einem defekten Datenträger, einem gelöschten Server oder einem menschlichen Fehler. Eine belastbare Backup-Strategie für Redis kopiert Snapshots konsistent, automatisiert die Aufbewahrung, testet Restores regelmäßig und hält mindestens eine Kopie außerhalb der produktiven Infrastruktur vor.

Wer eine bestehende Redis-Anwendung erstmals gegen einen Redis Cluster betreibt, stößt fast zwangsläufig auf die Fehlermeldung CROSSSLOT keys in request don't hash to the same slot, sobald ein Multi-Key-Befehl wie MGET oder eine Transaktion mehrere Schlüssel gleichzeitig anfasst, die auf unterschiedliche Hash-Slots verteilt sind. Dieser Artikel erklärt, warum dieses Verhalten eine bewusste Design-Entscheidung von Redis Cluster ist, wie sich Hash-Tags gezielt zur Kolokation zusammengehöriger Schlüssel einsetzen lassen und welchen Preis diese Lösung in Form eingeschränkter Sharding-Gleichverteilung kostet.

Millionen eindeutige Besucher zaehlen, ohne Millionen einzelner IDs zu speichern: HyperLogLog schaetzt die Kardinalitaet einer Menge mit einer festen Speichergroesse von nur 12 Kilobyte und einem typischen Fehler von rund 0,81 Prozent, unabhaengig davon, ob die Menge tausend oder eine Milliarde Elemente enthaelt.

Wer nur weiß, dass Redis LRU oder LFU als Eviction-Strategie unterstützt, versteht noch nicht, warum die tatsächliche Trefferrate von der Theorie abweicht. Das approximierte Sampling, der logarithmische Zähler und die Decay-Logik hinter den Kulissen bestimmen, wie nah eine Eviction-Strategie in der Praxis an ihr theoretisches Optimum herankommt.

Das Cache-Aside-Pattern verlagert die gesamte Cache-Logik in die Anwendung: Sie prüft Redis, lädt bei einem Miss aus der Datenbank nach und füllt den Cache selbst wieder auf. Wer dabei Fehlerbehandlung, TTL-Werte und Race Conditions ignoriert, handelt sich stille Inkonsistenzen und unnötige Datenbanklast ein, obwohl Redis genau davor schützen sollte.

Das Redis Cache-Backend ersetzt den dateibasierten Standard-Cache von Magento durch einen In-Memory-Speicher und beseitigt damit eines der haeufigsten I/O-Nadeloehre produktiver Shops. Wer env.php, Cm_Cache_Backend_Redis und die zugehoerigen Parameter fuer Kompression, Datenbank-Trennung und Cache-Tags versteht, kann das Cache-Backend gezielt auf Katalog-Groesse und Traffic abstimmen statt sich auf Standardwerte zu verlassen.

Wenn ein stark nachgefragter Redis-Schluessel abläuft, treffen häufig hunderte gleichzeitige Anfragen ungebremst auf die Datenbank, weil jede Anfrage den Cache Miss unabhängig behandelt. Dieses Phänomen heisst Cache Stampede oder Thundering Herd und lässt sich mit Mutex-Locking oder probabilistischem Early Expiration gezielt verhindern, ohne die Vorteile des Caches aufzugeben.