Seite 2 - Redis

Redis kennt von Haus aus nur den direkten Key-Zugriff, keine Abfragen über mehrere Felder oder Volltextsuche. RediSearch schließt diese Lücke, indem es Sekundärindizes direkt über Hashes oder JSON-Dokumente anlegt und damit Filter-, Sortier- und Volltextabfragen ermöglicht, ohne die Daten in ein separates Suchsystem zu duplizieren.

Redis Transaktionen queuen Befehle mit MULTI und fuehren sie atomar mit EXEC aus, ohne dass ein anderer Client dazwischenfunkt. Wer jedoch glaubt, MULTI/EXEC verhalte sich wie eine SQL-Transaktion mit Rollback bei Laufzeitfehlern, baut auf eine falsche Annahme, die im Produktivbetrieb zu inkonsistenten Daten fuehren kann.

AOF-Persistence protokolliert jede Schreiboperation als Kommando in einer Append-Only-Datei und erlaubt Redis damit deutlich engere Durability-Garantien als reine RDB-Snapshots. Die Wahl der appendfsync-Strategie zwischen always, everysec und no entscheidet direkt darüber, wie viele Millisekunden Latenz gegen wie viele Sekunden potenziellen Datenverlust getauscht werden.

Sporadische Latenzspitzen gehören zu den unangenehmsten Performance-Problemen in einer Redis-Instanz, weil sie sich weder mit einem einzelnen Befehl reproduzieren noch mit einer einfachen Lastmessung erklären lassen. Der eingebaute Latency Monitor wurde genau für diesen Fall entwickelt: Er protokolliert intern verschiedene Ereignisklassen, von langsamen Befehlen über Fork-Vorgänge bis hin zu Ablaufzyklen abgelaufener Schlüssel, und macht sie über die Befehle LATENCY HISTORY, LATENCY LATEST und LATENCY DOCTOR zugänglich. Dieser Artikel zeigt, wie diese Ereignisklassen im Detail funktionieren, wie sich der Latency Monitor sinnvoll mit dem klassischen Slowlog kombinieren lässt und wie ein systematischer Diagnose-Workflow aussieht, wenn Latenzprobleme nur gelegentlich und scheinbar willkürlich auftreten.

Als Redis Ltd im März 2024 ankündigte, künftige Versionen nicht mehr unter der freizügigen BSD-Lizenz, sondern unter der Server Side Public License und der Redis Source Available License zu veröffentlichen, reagierte ein Teil der Community mit der Gründung eines eigenständigen Forks. Unter dem Dach der Linux Foundation entstand Valkey, das auf dem letzten BSD-lizenzierten Redis-Stand aufsetzt und seither eigenständig weiterentwickelt wird. Für Betreiber bestehender Redis-Installationen, auch im Magento-Umfeld, stellt sich seither die konkrete Frage, wie kompatibel Valkey tatsächlich ist und ob ein Wechsel sinnvoll ist.

Cache-Invalidierung gilt zurecht als eines der beiden schwierigen Probleme der Informatik, weil jede Strategie einen Trade-off zwischen Konsistenz, Implementierungsaufwand und Performance erzwingt. Mit Redis stehen TTL-basierte, explizite und Tag-basierte Invalidierung zur Verfuegung, und dieser Artikel ordnet ein, welche Strategie fuer welchen Anwendungsfall tatsaechlich die richtige ist.

Sorted Sets gelten meist als Werkzeug fuer Leaderboards, sind aber eine der vielseitigsten Datenstrukturen in Redis. Mit einer nach Score sortierten Skip List im Hintergrund eignen sich Sorted Sets ebenso fuer Zeitreihen, verzoegerte Job-Ausfuehrung und Prioritaets-Warteschlangen, oft ohne zusaetzliche Infrastruktur neben Redis selbst.

Jede Form von Persistence in Redis kostet Latenz, ob durch fsync-Aufrufe bei jedem Schreibvorgang oder durch den Fork-Prozess hinter einem Snapshot. Wer diesen Tradeoff nicht versteht, wählt entweder eine Konfiguration, die Latenzspitzen im Produktivbetrieb verursacht, oder eine, die im Ernstfall mehr Daten verliert als geplant.

Magentos Full Page Cache invalidiert Einträge über Tags wie cat_p_123 oder cat_c_45, die entitätsbezogen, aber standardmäßig nicht store-spezifisch sind. In einer Multi-Store-Installation mit mehreren Websites, Store-Groups und Store-Views bedeutet das: Eine Änderung, die eigentlich nur eine einzige Store-View betrifft, etwa eine store-spezifische Preisregel oder ein individueller Freigabestatus, kann trotzdem Cache-Einträge für alle anderen Stores mit invalidieren, weil sie denselben Tag-Namensraum teilen. Wer viele Stores betreibt, muss deshalb bewusst entscheiden, wie granular Tags aufgebaut werden, ohne dabei in eine Tag-Explosion mit unüberschaubar vielen, kaum wiederverwendeten Tags zu laufen.

In stark frequentierten Magento-Shops greifen alle PHP-FPM-Worker eines Servers auf dieselbe Handvoll häufig gelesener Konfigurationswerte zu, etwa Store-Konfiguration, Feature-Flags oder Layout-Handles, die sich pro Request kaum je ändern, aber bei jedem Request erneut aus Redis gelesen werden. Solche extrem häufig gelesenen Schlüssel werden als Hot Keys bezeichnet und können unter hoher Last selbst bei einem grundsätzlich performanten Redis zu einem messbaren Engpass werden, weil jede einzelne Netzwerk-Rundreise zu Redis Zeit kostet, die sich bei Zehntausenden Requests pro Minute deutlich summiert. Redis-Client-Side-Caching über das RESP3-Protokoll verspricht hier Abhilfe, indem es Hot-Key-Werte direkt im Speicher des aufrufenden Prozesses vorhält, mit klaren, aber praktisch relevanten Grenzen für die Integration in Magentos Cache-Backend-Architektur.