Seite 6 - Redis

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.

Magentos eingebautes Full Page Caching setzt auf eindeutige URLs und HTML-Antworten, die sich vollständig als eine Einheit cachen und über Tags invalidieren lassen. GraphQL bricht dieses Modell auf: Ein einziger POST-Endpunkt, beliebig kombinierbare Query-Strings, Variablen und teils personalisierte Felder erzeugen eine Vielzahl unterschiedlicher Antworten, die sich nicht mehr sauber über eine URL identifizieren lassen. Wer Magento headless oder als API-Backend für ein eigenes Frontend betreibt, muss deshalb eine eigene Caching-Schicht auf Query-Ebene bauen. Redis eignet sich dafür besonders gut, weil sich Query-Antworten dort granular als eigene Schlüssel ablegen, mit präzisen Tags versehen und gezielt invalidieren lassen, ohne dass gleich der gesamte Cache geleert werden muss.

Jede neue TCP-Verbindung zu Redis kostet Zeit, und mit aktiviertem TLS steigt dieser Preis durch den zusätzlichen Handshake nochmals deutlich. Connection-Pooling vermeidet wiederholten Verbindungsaufbau, doch eine falsch dimensionierte Pool-Größe erzeugt neue Probleme, von Wartezeiten bis zur Überlastung des Servers mit offenen Verbindungen.

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 klassische Redis-ACL-Regel legt für einen Nutzer eine Liste erlaubter Befehle und ein einziges Key-Pattern fest. Das reicht für einfache Rollen, scheitert aber, sobald ein Nutzer je nach Befehlsgruppe unterschiedliche Zugriffsrechte auf unterschiedliche Schlüsselbereiche braucht. ACL Selectors lösen genau dieses Problem, indem sie mehrere unabhängige Berechtigungsregeln innerhalb desselben Nutzers erlauben. Wie Selectors technisch funktionieren und wie sich damit ein realistisches Multi-Team-Setup abbilden lässt, zeigt dieser Artikel.

Ein einzelner DEL-Befehl wirkt harmlos, kann bei einer Collection mit Millionen Elementen aber den gesamten Redis-Server für mehrere hundert Millisekunden einfrieren. Lazy Freeing verlagert die eigentliche Speicherfreigabe in einen Hintergrund-Thread und macht das Löschen großer Keys unabhängig von ihrer internen Größe spürbar schnell.