Seite 7 - Redis

Message Queues entkoppeln PHP-Anwendungen von langsamen oder unzuverlässigen Nachbarsystemen und verlagern Arbeit in asynchrone Worker-Prozesse. Wer versteht, wie Acknowledgments, Prefetch und Dead-Letter-Queues zusammenspielen, kann Message Queues aus PHP heraus so ansteuern, dass Nachrichten weder verloren gehen noch doppelt verarbeitet werden.

Redis kennt von Haus aus kein natives Konzept für Mandantenfähigkeit, weshalb jedes Multi-Tenant-Setup eine bewusste architektonische Entscheidung erfordert. Drei Ansätze stehen dabei typischerweise zur Wahl: präfix-basierte Namensräume innerhalb einer gemeinsamen Datenbank, logische Datenbanken über den klassischen SELECT-Index, oder vollständig getrennte Instanzen pro Mandant. Alle drei unterscheiden sich deutlich in Isolationsgrad, Backup-Granularität und Skalierbarkeit. Dieser Artikel vergleicht die drei Strategien anhand konkreter Kriterien und leitet daraus eine praktische Empfehlung für Multi-Store-Magento-Setups ab, in denen mehrere Store-Views denselben Cache-Layer nutzen sollen.

Redis übernimmt in Magento gleich drei Rollen: Session-Speicher, Object-Cache-Backend und optional Full-Page-Cache. Wer alle drei Rollen in derselben Datenbank ablegt, riskiert Tag-Kollisionen, unnötige Cache-Flushes und im schlimmsten Fall abgemeldete Kunden durch verlorene Sessions. Dieser Artikel zeigt, wie Redis in Magento korrekt konfiguriert, überwacht und vor Speicherüberlauf geschützt wird.

Redis verarbeitet Befehle traditionell in einem einzigen Thread, was Race Conditions verhindert, aber die verfügbare CPU-Leistung moderner Multi-Core-Server nur zu einem Bruchteil ausnutzt. KeyDB setzt an genau diesem Punkt an und verarbeitet Netzwerk-I/O und Befehlsausführung über mehrere Threads gleichzeitig, während es sich als weitgehend kompatible Alternative zum Redis-Protokoll positioniert. Dieser Artikel ordnet ein, wie KeyDB technisch funktioniert, wie hoch der tatsächliche Kompatibilitätsgrad ist und in welchen Magento-Betriebsszenarien sich ein Umstieg überhaupt lohnen könnte.

Seit Redis 6 steht mit RESP3 eine überarbeitete Version des Redis-Protokolls zur Verfügung, die deutlich mehr strukturierte Datentypen kennt als das seit Jahrzehnten etablierte RESP2. Für Anwendungen, die Redis nur über eine ausgereifte Client-Bibliothek ansprechen, bleibt vieles davon unsichtbar, doch wer eigene Serialisierung schreibt, Client-Side Caching nutzen möchte oder einfach verstehen will, warum manche Werte plötzlich als Double statt als String zurückkommen, sollte die praktischen Unterschiede kennen. Dieser Artikel zeigt, welche neuen Datentypen RESP3 einführt, wie es um die Kompatibilität der Client-Bibliotheken steht und was sich bei einer Umstellung konkret ändert.

Dragonfly ist ein 2022 vorgestellter In-Memory-Datenspeicher, der sich als kompatibler Ersatz für Redis positioniert, dabei aber intern eine komplett andere Architektur verfolgt. Statt eines einzigen Threads verteilt Dragonfly Arbeit über einen Shared-Nothing-Ansatz auf mehrere Kerne, verwendet eine eigene Speicherstruktur namens Dashtable und verspricht deutlich schnellere Snapshots als Redis' forkbasiertes RDB-Verfahren. Dieser Artikel ordnet ein, wie diese Architektur technisch funktioniert, wie belastbar die Performance-Versprechen sind und für welche Magento-Betriebsszenarien ein Testeinsatz heute schon sinnvoll erscheint.

Redis uebernimmt in Magento 2 zwei grundverschiedene Aufgaben: schreibintensiven Session-Storage und leselastiges Caching, oft auf demselben Server ohne saubere Trennung. Dieser Artikel zeigt, wie man den Speicherbedarf fuer Redis-Sessions berechnet, env.php und redis.conf fuer getrennte Instanzen konfiguriert und mit Monitoring rechtzeitig erkennt, wenn die Redis-Dimensionierung an ihre Grenzen stoesst.

Wenn Redis unter maxmemory-Druck einen Key entfernen muss, durchsucht es nicht die gesamte Datenbank nach dem am längsten ungenutzten Eintrag. Stattdessen zieht es eine kleine Zufalls-Stichprobe und wählt daraus den vermeintlich besten Kandidaten, ein bewusster Kompromiss zwischen Genauigkeit und Geschwindigkeit, der sich über maxmemory-samples fein justieren lässt.

Eine funktionierende Tag-Invalidierung ist die Grundvoraussetzung dafuer, dass der Magento Full Page Cache ueberhaupt nutzbar bleibt, ohne veraltete Preise oder Lagerbestaende auszuliefern. Wer versteht, wie X-Magento-Tags gesetzt werden, wie Redis diese Tags intern verwaltet und warum cache:clean etwas grundlegend anderes tut als cache:flush, kann Invalidierungsprobleme gezielt statt durch pauschales Cache-Leeren loesen.

Redis TTL-Werte bestimmen nicht nur, wann ein Key verschwindet, sondern beeinflussen direkt die Systemlast beim Ablauf. Wer Tausende Keys mit identischer TTL setzt, riskiert einen Thundering-Herd-Effekt, bei dem alle Caches gleichzeitig leerlaufen und das Backend mit Anfragen ueberfluten. TTL-Jitter loest genau dieses Problem.