Client-Side Caching für Hot Keys in Magento-Shops mit Redis

1. Was Hot Keys sind und welche Magento-Zugriffe sie typischerweise erzeugen

Ein Hot Key ist ein einzelner Redis-Schlüssel, der im Verhältnis zur Gesamtzahl aller Zugriffe extrem überproportional häufig gelesen wird, oft mehrere Größenordnungen häufiger als ein durchschnittlicher Schlüssel im selben Datenbestand. In Magento entstehen solche Hot Keys vor allem bei Werten, die für praktisch jeden Request relevant sind, unabhängig davon, welches Produkt oder welche Kategorie konkret aufgerufen wird, etwa der serialisierte Store-Konfigurationsbaum, aktive Feature-Flags aus einem Custom-Modul oder häufig abgefragte Layout-Handle-Zuordnungen.

Auch der Full-Page-Cache-Key für besonders populäre Seiten, etwa die Startseite oder eine stark beworbene Kategorieseite, kann faktisch zum Hot Key werden, wenn ein signifikanter Anteil des gesamten Traffics auf diese eine Seite entfällt. Der gemeinsame Nenner all dieser Fälle ist, dass sehr viele, potenziell parallel laufende PHP-FPM-Worker denselben, sich selten ändernden Wert innerhalb kurzer Zeit wiederholt aus Redis anfordern.

2. Warum Hot Keys trotz performantem Redis zum Engpass werden können

Redis selbst verarbeitet einzelne Lesezugriffe extrem schnell, typischerweise im niedrigen Mikrosekundenbereich, sodass die reine Serverseitige Verarbeitung eines Hot Keys selten das eigentliche Problem ist. Der Engpass entsteht stattdessen meist durch die Summe der Netzwerk-Rundreisen: Jeder einzelne GET-Aufruf erfordert einen vollständigen Hin- und Rückweg über das Netzwerk, inklusive TCP-Overhead und, je nach Deployment, TLS-Handshake-Kosten bei bereits bestehenden, aber neu ausgehandelten Verbindungen.

Bei Zehntausenden Requests pro Minute, von denen praktisch jeder denselben Hot Key abfragt, summiert sich dieser scheinbar kleine Overhead zu einer spürbaren Gesamtlatenz und zusätzlicher Netzwerklast auf dem Redis-Server, selbst wenn Redis selbst weit von seiner CPU-Kapazitätsgrenze entfernt bleibt. Genau diese wiederholte, redundante Netzwerk-Rundreise für einen ohnehin fast immer identischen Wert ist der Ansatzpunkt fürs Client-Side Caching.

3. RESP3 und Server Assisted Client-Side Caching im Grundprinzip

Seit Redis 6 unterstützt der Server das neue Antwortprotokoll RESP3 sowie eine Funktion namens Client-Side Caching, technisch realisiert über den Befehl CLIENT TRACKING. Aktiviert ein Client das Tracking, merkt sich Redis serverseitig, welche Schlüssel dieser Client zuletzt gelesen hat, und schickt bei einer Änderung eines dieser Schlüssel proaktiv eine Invalidierungsnachricht an den Client, ohne dass dieser aktiv nachfragen muss.

Der Client kann den Wert eines getrackten Schlüssels daraufhin so lange direkt aus seinem eigenen, lokalen Speicher bedienen, bis er entweder die Invalidierungsnachricht empfängt oder den Schlüssel aus anderen Gründen aus seinem lokalen Cache entfernt. Dieses Muster spart bei jedem wiederholten Lesezugriff auf denselben, unveränderten Schlüssel die komplette Netzwerk-Rundreise zu Redis, solange keine Änderung vorliegt.

4. Voraussetzungen: Redis-Version, RESP3 und PHP-Client-Unterstützung

Client-Side Caching setzt mindestens Redis 6 voraus, wobei die praktische Stabilität und Feature-Vollständigkeit sich mit jeder neueren Version weiter verbessert hat. Auf PHP-Seite benötigt es einen Redis-Client, der sowohl RESP3 als auch CLIENT TRACKING unterstützt: phpredis bietet diese Unterstützung ab entsprechend aktuellen Versionen, während bei Predis die Unterstützung je nach eingesetzter Version und Konfiguration geprüft werden muss.

Zusätzlich muss die Verbindung explizit auf RESP3 umgestellt werden, meist über HELLO 3 beim Verbindungsaufbau, bevor CLIENT TRACKING ON aktiviert werden kann. Läuft ein Teil der Infrastruktur noch auf einer älteren Redis-Version oder einem Client ohne RESP3-Unterstützung, etwa in einem gemischten Deployment mit mehreren PHP-Versionen und Extension-Ständen, ist Client-Side Caching für diese Komponenten schlicht nicht verfügbar.

5. Default- und Broadcasting-Modus: wie das Tracking konkret funktioniert

Im Default-Modus merkt sich Redis pro Verbindung exakt, welche Schlüssel tatsächlich gelesen wurden, und invalidiert gezielt nur diese, sobald sie sich ändern. Das ist präzise, erzeugt aber pro verfolgtem Schlüssel und Client einen gewissen internen Verwaltungsaufwand auf dem Server, der bei sehr vielen unterschiedlichen, gleichzeitig getrackten Schlüsseln spürbar werden kann.

Im Broadcasting-Modus abonniert ein Client stattdessen ganze Schlüsselpräfixe, etwa alle Schlüssel unter config:, und erhält Invalidierungsnachrichten für jede Änderung innerhalb dieses Präfixes, unabhängig davon, ob der konkrete Schlüssel tatsächlich lokal gecacht wurde. Für Hot-Key-Szenarien mit einer überschaubaren, klar abgegrenzten Menge an Konfigurationsschlüsseln ist der Broadcasting-Modus meist die praktikablere Wahl, weil er den serverseitigen Tracking-Aufwand deutlich reduziert.

<?php
declare(strict_types=1);

/**
 * Aktiviert RESP3-Tracking im Broadcasting-Modus für ein
 * definiertes Präfix häufig gelesener Konfigurationsschlüssel.
 *
 * @param Redis $redis Verbundener phpredis-Client mit RESP3-Unterstützung.
 * @param string $prefix Schlüsselpräfix, dessen Änderungen verfolgt werden.
 * @return void
 */
function enableBroadcastTracking(Redis $redis, string $prefix): void
{
    $redis->rawCommand('HELLO', '3');
    $redis->rawCommand('CLIENT', 'TRACKING', 'ON', 'BCAST', 'PREFIX', $prefix);
}

6. Praktisches Beispiel: einen Konfigurationswert lokal vorhalten

Ein realistischer Kandidat ist ein Feature-Flag, das bei jedem Request geprüft wird, etwa ob ein experimentelles Checkout-Layout aktiv ist. Statt bei jedem Request einen GET-Aufruf gegen Redis abzusetzen, hält ein einfacher In-Process-Cache den zuletzt gelesenen Wert im PHP-Prozessspeicher vor und aktualisiert ihn nur, wenn eine über das Tracking empfangene Invalidierungsnachricht signalisiert, dass sich der Wert tatsächlich geändert hat.

Wichtig ist dabei, dass dieser lokale Cache an den Lebenszyklus der jeweiligen PHP-FPM-Worker-Verbindung gebunden ist, nicht an den einzelnen Request: Innerhalb eines langlebigen PHP-Prozesses, etwa bei einem persistenten Redis-Client über mehrere Requests hinweg, bleibt der lokale Wert über mehrere Requests hinweg gültig, solange keine Invalidierung eintrifft, was den eigentlichen Nutzen des Musters ausmacht.

<?php
declare(strict_types=1);

namespace Mironsoft\HotKeyCache\Model;

use Redis;

/**
 * Hält einen häufig gelesenen Konfigurationswert lokal vor und
 * nutzt RESP3-Invalidierungsnachrichten, um ihn aktuell zu halten.
 */
class TrackedConfigValue
{
    private ?string $cachedValue = null;

    /**
     * @param Redis $redis Verbundener phpredis-Client mit aktivem Tracking.
     * @param string $key Zu verfolgender Konfigurationsschlüssel.
     */
    public function __construct(private readonly Redis $redis, private readonly string $key)
    {
    }

    /**
     * Liefert den aktuellen Wert, möglichst aus dem lokalen Speicher.
     *
     * @return string|null
     */
    public function get(): ?string
    {
        if ($this->cachedValue === null) {
            $value = $this->redis->get($this->key);
            $this->cachedValue = $value !== false ? $value : null;
        }

        return $this->cachedValue;
    }

    /**
     * Wird vom Tracking-Callback bei einer Invalidierungsnachricht aufgerufen.
     *
     * @return void
     */
    public function invalidate(): void
    {
        $this->cachedValue = null;
    }
}

7. Grenzen der Integration in Magentos Cache-Backend-Architektur

Magentos Cm_Cache_Backend_Redis beziehungsweise das moderne, darauf aufbauende Cache-Backend ist tief in das generische Zend_Cache-Interface eingebettet und geht von einem klassischen, zustandslosen Request-Response-Zugriff auf den Cache aus, nicht von einer dauerhaft gehaltenen, getrackten Verbindung mit lokalem Zwischenspeicher. Client-Side Caching lässt sich deshalb nicht einfach als Konfigurationsoption in diesem bestehenden Backend aktivieren, sondern erfordert eine eigene, zusätzliche Schicht oberhalb oder parallel zum regulären Cache-Backend.

Hinzu kommt, dass PHP-FPM-Worker-Prozesse typischerweise nach jedem oder nach wenigen Requests recycelt werden, abhängig von pm.max_requests, wodurch der Nutzen eines lokalen, prozessgebundenen Caches strukturell begrenzt ist: Ein frisch gestarteter Worker hat noch keinen lokalen Cache-Zustand aufgebaut und muss den Hot Key beim ersten Zugriff ohnehin regulär aus Redis laden.

8. In-Process-Cache-Layer als pragmatischer Workaround

Statt das volle RESP3-Tracking-Protokoll tief in Magentos Cache-Backend zu integrieren, bewährt sich in der Praxis häufig ein pragmatischerer Ansatz: ein einfacher, request-übergreifender In-Process-Cache innerhalb eines langlebigen PHP-Prozesses, kombiniert mit einer kurzen, bewusst gewählten TTL statt vollem, ereignisgesteuertem Tracking. Das verzichtet auf die Echtzeit-Invalidierung des vollständigen RESP3-Ansatzes, ist dafür aber deutlich einfacher zu implementieren und benötigt keine tiefe Änderung an Magentos Cache-Architektur.

Wo tatsächliche Echtzeit-Konsistenz erforderlich ist, etwa bei sicherheitsrelevanten Feature-Flags, lässt sich das RESP3-Tracking gezielt als eigenständige, isolierte Komponente für genau diese wenigen, klar identifizierten Hot Keys einführen, statt zu versuchen, das gesamte Cache-Backend flächendeckend umzustellen.

9. Konsistenzrisiken einschätzen und entscheiden, wann sich der Aufwand lohnt

Jede Form von Client-Side Caching führt zwangsläufig ein Zeitfenster ein, in dem ein Worker theoretisch einen veralteten Wert ausliefert, etwa wenn die Invalidierungsnachricht durch eine kurzzeitige Netzwerkstörung verzögert ankommt. Für unkritische, rein performanceorientierte Werte wie Layout-Handle-Zuordnungen ist dieses Risiko meist vernachlässigbar, für sicherheitsrelevante Werte wie Zugriffsberechtigungen oder Zahlungsstatus dagegen nicht ohne Weiteres akzeptabel. Eine bewusste Klassifizierung der Kandidaten, getrennt nach Konsistenzanforderung, ist deshalb der wichtigste Schritt vor der Einführung: Nur Werte, bei denen ein kurzes Zeitfenster mit potenziell veralteten Daten tolerierbar ist, sollten überhaupt für dieses Muster infrage kommen.

Client-Side Caching für Hot Keys lohnt sich vor allem bei nachweislich sehr hoher Zugriffsfrequenz auf eine kleine, klar identifizierbare Menge an Schlüsseln, kombiniert mit einer Infrastruktur, die bereits RESP3-fähige Redis-Versionen und Clients einsetzt. Fehlt eine dieser Voraussetzungen, oder ist die tatsächliche Zugriffsfrequenz auf einzelne Schlüssel unklar, ist der zusätzliche Implementierungs- und Wartungsaufwand meist nicht gerechtfertigt. Vor jeder Einführung lohnt sich deshalb eine Messung der tatsächlichen Zugriffshäufigkeit einzelner Schlüssel, etwa über redis-cli --hotkeys in Kombination mit aktivierter Maxmemory-Policy oder über eigenes Logging auf Anwendungsebene, um echte Hot Keys von bloß subjektiv häufig erscheinenden Zugriffen zuverlässig zu unterscheiden.

# Redis nach tatsächlichen Hot Keys durchsuchen (benötigt aktive LFU-Policy)
redis-cli --hotkeys

# Zugriffsfrequenz eines konkreten Schlüssels über OBJECT FREQ prüfen
redis-cli OBJECT FREQ "config:feature_flags

10. Zusammenfassung

11. FAQ: Client-Side Caching für Hot Keys in Magento: Das Wichtigste auf einen Blick