Seite 4 - Redis

Redis Lua-Scripting fuehrt komplette Skripte als einen einzigen atomaren Befehl aus, ohne dass ein anderer Client dazwischenfunken kann. Wer Increment-mit-Limit, bedingtes Loeschen oder andere Read-then-Write-Muster ohne echte Server-Logik umsetzt, riskiert Race-Conditions, die Lua-Skripte strukturell ausschliessen.

Session-Storage wirkt trivial, bis die Anwendung ueber mehrere Server skaliert und die erste Anmeldung nach einem Deploy verschwindet. Redis als zentraler Session-Store loest das Skalierungsproblem, bringt aber eigene Architekturentscheidungen mit sich, von Serialisierungsformat ueber TTL-Strategie bis zur Frage, ob Sticky Sessions ueberhaupt noch noetig sind.

Memory-Fragmentation entsteht, wenn der Allokator jemalloc mehr physischen Speicher belegt, als Redis für die eigentlichen Daten tatsächlich braucht, und lässt sich präzise über mem_fragmentation_ratio messen. Wer versteht, wie jemalloc Speicherblöcke verwaltet, kann Active Defrag gezielt konfigurieren und weiß, wann ein kontrollierter Neustart die bessere Wahl gegenüber Defragmentierung im laufenden Betrieb ist.

Nach jedem Magento-Deployment ist der Redis-Cache leer, und die ersten Requests treffen die Datenbank ungebremst. Dieser Artikel zeigt, warum dieser Traffic-Spike entsteht, wie Warmup-Crawler und Cache-Preload-Skripte ihn verhindern, und wie sich Warmup sauber in die Deployment-Pipeline integrieren laesst.

Wenn eine einzelne Redis-Instanz in Magento an ihre Grenzen stoesst, stehen zwei Wege offen: ein echtes Redis-Cluster mit Sharding oder eine saubere Aufteilung von Cache, Session und Full-Page-Cache auf dedizierte Redis-Instanzen. Dieser Artikel zeigt, wann welcher Weg sinnvoll ist und wie der Umstieg konkret ablaeuft.

Fällt der Master eines Redis-Setups ohne Automatisierung aus, entscheidet die Reaktionszeit eines Menschen über die Ausfallzeit einer Anwendung. Redis Sentinel überwacht Master und Replicas kontinuierlich, stimmt sich mit weiteren Sentinel-Instanzen über den tatsächlichen Zustand ab und befördert bei einem echten Ausfall automatisch eine Replica zum neuen Master, ohne dass jemand manuell eingreifen muss.

Eine Netzwerkpartition kann dazu fuehren, dass zwei Redis-Knoten sich gleichzeitig fuer den einzigen gueltigen Master halten und widerspruechliche Schreibzugriffe akzeptieren. Quorum-basierte Entscheidungen in Sentinel, die Absicherung ueber min-replicas-to-write und ein sauberes Verstaendnis der Failover-Mechanik verhindern, dass eine solche Split-Brain-Situation überhaupt entsteht oder unbemerkt Daten kostet.

Eine falsch gewählte maxmemory-policy führt entweder zu abgelehnten Schreibvorgängen mitten im Betrieb oder zum stillen Verlust wichtiger Daten, die eigentlich dauerhaft gespeichert werden sollten. Wer versteht, wie Redis Speicher unter Druck verwaltet, wählt die passende Policy gezielt statt zufällig und vermeidet beide Szenarien zuverlässig.

Redis-Replikation wirkt auf den ersten Blick simpel: ein Befehl, eine Verbindung, Daten fließen von Master zu Replica. Unter der Oberfläche entscheidet aber das PSYNC-Protokoll darüber, ob nach einer kurzen Netzwerkunterbrechung nur wenige Kilobyte oder der komplette Datensatz erneut übertragen werden, und eine falsch dimensionierte Backlog-Größe macht genau diesen Unterschied in der Praxis regelmäßig zunichte.

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.