Client-Side Caching mit Tracking: Redis-Daten im Anwendungsspeicher halten

1. Das Grundproblem: jeder Lesezugriff kostet einen Roundtrip

Ein klassischer Redis-Zugriff läuft immer über das Netzwerk, selbst wenn der angefragte Wert seit Millisekunden unverändert im Speicher des Redis-Servers liegt. Bei einer Produktdetailseite, die pro Aufruf mehrere gecachte Fragmente aus Redis liest, etwa Preisdaten, Verfügbarkeit und Kategoriezuordnung, summieren sich diese Roundtrips schnell zu einer spürbaren Latenz, besonders wenn Anwendung und Redis-Server nicht auf derselben Maschine laufen und jeder Roundtrip mit Netzwerk-Overhead und TLS-Handshake-Kosten verbunden ist.

Ein naheliegender Gedanke ist, häufig gelesene Werte direkt im Speicher der Anwendung zu halten und Redis nur noch bei einem Cache-Miss zu befragen. Das Problem dabei ist klassische Cache-Invalidierung: Woher weiß die Anwendung, dass ein lokal gehaltener Wert inzwischen veraltet ist, wenn ein anderer Prozess den zugrunde liegenden Schlüssel in Redis verändert hat? Genau hier setzt das Tracking-Protokoll an.

2. Wie das RESP3-Tracking-Protokoll invalidierende Nachrichten sendet

Mit CLIENT TRACKING ON aktiviert eine Verbindung serverseitiges Tracking für sich selbst. Ab diesem Zeitpunkt merkt sich Redis, welche Schlüssel dieser Client bei Lesebefehlen wie GET oder MGET abgefragt hat, und legt intern eine Zuordnung von Schlüssel zu interessierten Clients an. Ändert sich einer dieser Schlüssel, sei es durch SET, DEL, EXPIRE oder einen anderen schreibenden Befehl, sendet Redis proaktiv eine Invalidierungsnachricht an den betroffenen Client, ohne dass dieser aktiv nachfragen muss.

Technisch basiert das auf dem RESP3-Protokoll, das im Gegensatz zu RESP2 echte Push-Nachrichten kennt, die außerhalb des normalen Anfrage-Antwort-Zyklus über dieselbe Verbindung eintreffen können. Die Anwendung muss ihre Client-Bibliothek entsprechend so einsetzen, dass sie auf einer separaten Verbindung, der sogenannten RESP3-Push-Verbindung, oder direkt auf der Hauptverbindung eingehende Invalidierungsnachrichten erkennt und den betroffenen lokalen Cache-Eintrag sofort entfernt.

# Tracking für die aktuelle Verbindung aktivieren (RESP3 erforderlich)
redis-cli -3
> CLIENT TRACKING ON
OK
> GET product:4711:price
"49.90"

# Ändert ein anderer Client den Schlüssel, kommt eine Push-Nachricht:
# >3
# $10
# invalidate
# *1
# $18
# product:4711:price

3. Default-Modus: serverseitige Nachverfolgung pro Client

Im Default-Modus merkt sich Redis für jeden getrackten Client individuell, welche Schlüssel er zuletzt gelesen hat. Diese Zuordnung liegt in einer invalidierungstabelle im Server-Speicher und wächst mit der Anzahl unterschiedlicher Schlüssel, die aktive Clients abfragen. Der Vorteil ist Präzision: Ein Client bekommt ausschließlich Invalidierungen für Schlüssel, die er tatsächlich selbst gelesen hat, was den Nachrichtenverkehr minimal hält.

Der Nachteil ist der Speicherverbrauch auf dem Redis-Server selbst, der mit vielen gleichzeitig getrackten Clients und großen, unterschiedlichen Schlüsselmengen wächst. Bei sehr vielen aktiven Verbindungen mit jeweils breit gestreuten Lesezugriffen kann diese Tabelle spürbaren Speicherdruck erzeugen, weshalb der Default-Modus vor allem für eine überschaubare Anzahl langlebiger Verbindungen mit stabilem Zugriffsmuster geeignet ist, etwa Anwendungsserver-Prozesse mit dauerhaft geöffneter Redis-Verbindung.

4. Broadcasting-Modus: Invalidierung nach Präfix statt pro Schlüssel

Der Broadcasting-Modus, aktiviert über CLIENT TRACKING ON BCAST PREFIX product:, verzichtet auf die individuelle Nachverfolgung einzelner Schlüssel pro Client. Stattdessen abonniert der Client ein oder mehrere Schlüsselpräfixe, und Redis sendet Invalidierungsnachrichten für jeden geänderten Schlüssel innerhalb dieser Präfixe an alle Clients, die dieses Präfix abonniert haben, unabhängig davon, ob der jeweilige Client den konkreten Schlüssel überhaupt jemals gelesen hat.

Das reduziert den Speicherbedarf auf dem Server drastisch, weil keine Zuordnung von einzelnen Schlüsseln zu einzelnen Clients mehr gepflegt werden muss, nur eine Liste abonnierter Präfixe. Der Trade-off ist ein potenziell höheres Nachrichtenaufkommen: Bei einem breit gefassten Präfix wie product: erhalten Clients auch Invalidierungen für Produkte, die sie nie in ihren lokalen Cache geladen haben. Für Workloads mit klar abgrenzbaren, thematisch passenden Präfixen und vielen gleichzeitigen Clients ist Broadcasting deshalb oft die praktikablere Wahl.

# Broadcasting-Modus mit zwei Praefixen aktivieren
redis-cli -3
> CLIENT TRACKING ON BCAST PREFIX product: PREFIX category:
OK

# Optional: eigene Redirect-Verbindung für Push-Nachrichten nutzen
> CLIENT TRACKING ON REDIRECT 42 BCAST PREFIX product:
OK

5. Anwendungsintegration am Beispiel eines PHP-Clients

In der Praxis kapselt man Tracking meist in einer kleinen Cache-Fassade: Ein lokales Array oder ein PSR-16-kompatibler In-Memory-Cache hält Werte, während im Hintergrund eine dedizierte Redis-Verbindung im RESP3-Modus auf Invalidierungsnachrichten lauscht und bei jeder eingehenden Nachricht den passenden lokalen Eintrag entfernt. Für PHP-basierte Anwendungen mit Request-lebendem Prozessmodell lohnt sich Tracking vor allem dann, wenn ein langlebiger Worker-Prozess, etwa unter RoadRunner oder Swoole, mehrere Requests nacheinander mit demselben lokalen Cache bedient, da klassisches PHP-FPM den Prozessspeicher ohnehin nach jedem Request verwirft.

Für kurzlebige PHP-FPM-Prozesse bringt Tracking daher kaum einen Vorteil, weil der lokale Cache ohnehin nie über einen einzelnen Request hinaus existiert. Anders sieht es bei Daemon-Prozessen aus, etwa einem Consumer, der dauerhaft läuft und wiederholt dieselben Referenzdaten liest, wie Kategoriebäume oder Preisregeln, die sich selten, aber unvorhersehbar ändern.

{
  "pattern": "long-lived worker process",
  "local_cache": "in-memory array keyed by redis key",
  "tracking_connection": "separate RESP3 connection, BCAST mode",
  "on_invalidate_push": "remove matching key from local_cache",
  "on_cache_miss": "fetch from redis, populate local_cache"
}

6. Praktische Grenze: Speicherverbrauch auf Client-Seite

Client-Side Caching verlagert Speicherbedarf vom zentralen Redis-Server auf jeden einzelnen Anwendungsprozess. Bei horizontal skalierten Anwendungen mit vielen parallelen Worker-Prozessen bedeutet das, dass derselbe gecachte Wert potenziell in jedem Prozess separat im Speicher liegt, statt zentral einmal in Redis. Für kleine, häufig gelesene Referenzdaten ist das unproblematisch, für große Objekte oder sehr viele unterschiedliche Schlüssel kann sich der Speicherverbrauch über alle Prozesse hinweg schnell summieren und den Vorteil des eingesparten Netzwerk-Roundtrips durch erhöhten Speicherdruck auf den Anwendungsservern erkaufen.

Eine sinnvolle Begrenzung ist deshalb ein harter Deckel für die Anzahl lokal gehaltener Einträge, kombiniert mit einer LRU-artigen Verdrängungsstrategie im lokalen Cache selbst, sodass Tracking nur für tatsächlich wiederholt gelesene, kompakte Werte greift und nicht versehentlich zu einem unbegrenzt wachsenden Schattenspeicher der gesamten Redis-Instanz wird.

7. Eignung für Hot Keys: wo Tracking den größten Effekt bringt

Den größten Nutzen bringt Client-Side Caching bei klassischen Hot Keys: Schlüsseln, die von sehr vielen Clients extrem häufig gelesen, aber nur selten geschrieben werden. Typische Beispiele sind globale Konfigurationswerte, Feature-Flags, aktuelle Wechselkurse oder Kategoriebäume, die auf jeder Seite gebraucht werden, sich aber vielleicht nur wenige Male pro Tag ändern. Für solche Werte reduziert Tracking die Serverlast massiv, weil ein Großteil der Lesezugriffe den Redis-Server gar nicht mehr erreicht, sondern direkt aus dem Anwendungsspeicher bedient wird.

Für Werte mit hoher Schreibfrequenz, etwa Warenkorb-Zwischenstände oder Live-Lagerbestände, kehrt sich der Effekt um: Häufige Invalidierungen sorgen dafür, dass der lokale Cache-Eintrag kaum jemals lange genug gültig bleibt, um den Roundtrip wirklich einzusparen, während gleichzeitig zusätzlicher Nachrichtenverkehr für die Invalidierung selbst entsteht. Tracking eignet sich also gezielt für lesedominante, änderungsarme Daten und nicht als pauschaler Ersatz für jeden Cache-Zugriff.

8. Fehlerbehandlung: Verbindungsabbrüche und verpasste Invalidierungen

Ein zentrales Risiko bei Client-Side Caching ist der Verbindungsabbruch: Geht die Tracking-Verbindung verloren, bevor der Client eine Invalidierungsnachricht empfangen konnte, weiß die Anwendung nicht, ob ihr lokaler Cache noch aktuell ist. Redis begegnet diesem Fall mit einer speziellen Nachricht ohne Schlüsselangabe, die signalisiert, dass potenziell Invalidierungen verpasst wurden. Eine robuste Implementierung muss auf diese Nachricht reagieren, indem sie den kompletten lokalen Cache leert, statt selektiv fortzufahren.

Nach einem Reconnect sollte die Anwendung Tracking explizit neu aktivieren und, im Broadcasting-Modus, die abonnierten Präfixe erneut registrieren, da diese nicht automatisch über einen Verbindungsneuaufbau hinweg erhalten bleiben. Wer diese Fehlerbehandlung vernachlässigt, riskiert veraltete Daten im lokalen Cache, die im schlimmsten Fall deutlich länger bestehen bleiben, als es ohne Client-Side Caching der Fall gewesen wäre.

9. Einführungsstrategie: schrittweise Migration einzelner Datenklassen

Ein pauschaler Umstieg der gesamten Anwendung auf Client-Side Caching ist selten sinnvoll. Bewährt hat sich ein schrittweises Vorgehen: Zunächst identifiziert man konkrete Hot-Key-Kandidaten anhand von Zugriffsstatistiken, etwa über redis-cli --hotkeys oder eigenes Monitoring, aktiviert Tracking testweise für genau diese Datenklasse und misst den Effekt auf Latenz und Serverlast unter realistischem Traffic, bevor weitere Datenklassen folgen.

Parallel dazu lohnt sich ein Blick auf die eingesetzte Client-Bibliothek: Nicht jede Redis-Bibliothek unterstützt RESP3-Tracking gleich gut, manche kapseln die Push-Nachrichtenverarbeitung bereits komfortabel, andere erfordern manuelles Handling der Redirect-Verbindung. Diese Prüfung sollte am Anfang jeder Einführung stehen, bevor Tracking produktiv in größerem Umfang eingesetzt wird.

10. Zusammenfassung

11. FAQ: Client-Side Caching mit Tracking: Das Wichtigste auf einen Blick