Seite 4 - Redis

Redis Cluster verteilt jeden Key deterministisch auf einen von 16384 Hash Slots und macht damit horizontale Skalierung ohne zentralen Koordinator möglich. Wer die Slot-Berechnung per CRC16, die CROSSSLOT-Fehlermeldung bei Multi-Key-Befehlen und den gezielten Einsatz von Hash Tags versteht, vermeidet Verteilungsprobleme und Laufzeitfehler, bevor sie in Produktion auftreten.

Der Befehl INFO liefert eine Fülle an Rohdaten über eine Redis-Instanz, ist als reine Textausgabe jedoch für systematisches Alerting kaum geeignet. Der Redis Exporter übersetzt genau diese Rohdaten in strukturierte Prometheus-Metriken, ergänzt sie um eigene Prüfbefehle für Schlüsselgrößen und Latenzen und macht sie damit erst für Dashboards und Alerting-Regeln nutzbar. Dieser Artikel zeigt, welche Metriken der Exporter konkret liefert, wie sinnvolle Alerting-Regeln für Speicherauslastung, Verbindungsanzahl und Replikations-Lag aussehen und wie sich daraus ein Dashboard für den täglichen Betrieb aufbauen lässt, das nicht nur bei einem akuten Ausfall, sondern schon bei den ersten Warnsignalen anschlägt.

PHP-FPM verarbeitet jeden Request in einem eigenen, synchronen Worker-Prozess, der erst dann wieder für den nächsten Request zur Verfügung steht, wenn die aktuelle Anfrage vollständig abgeschlossen ist. Blockierende Redis-Commands wie BLPOP, BRPOP oder XREAD BLOCK warten aktiv auf ein Ereignis, bevor sie zurückkehren, und passen damit fundamental nicht zu diesem Modell: Ein einzelner solcher Aufruf innerhalb eines Magento-Controllers oder Plugins kann einen kompletten PHP-FPM-Worker für Sekunden oder gar Minuten belegen, während andere Besucher auf freie Worker warten müssen. Dieser Artikel zeigt, warum diese Commands in Webprozessen problematisch sind, wo sie in der Praxis versehentlich landen können und welche Alternativen für ereignisgesteuerte Abläufe in einer synchronen PHP-Architektur tatsächlich funktionieren.

Wenn Redis in einer Magento-Umgebung Probleme macht, sind meist nur wenige Fehlerbilder wirklich haeufig: verweigerte Verbindungen, OOM-Fehler beim Schreiben und Session-Lock-Timeouts im Checkout. Dieser Artikel geht jedes dieser Fehlerbilder systematisch durch, zeigt die Diagnose-Schritte und die konkrete Loesung.

Ein API-Endpunkt ohne Rate-Limiting ist eine offene Einladung fuer Missbrauch, egal ob durch fehlerhafte Clients, aggressive Scraper oder gezielte Angriffe. Redis liefert mit INCR, EXPIRE und Lua-Scripts die Bausteine, um Fixed-Window-, Sliding-Window- und Token-Bucket-Limiter zu bauen, die auch unter Last korrekt und atomar bleiben.

Wer eine Redis-Hochverfügbarkeitslösung plant, steht fast immer vor derselben Grundsatzentscheidung: Redis Sentinel für automatischen Failover ohne Sharding, oder Redis Cluster für Hochverfügbarkeit mit eingebauter horizontaler Skalierung. Beide lösen unterschiedliche Probleme, und die falsche Wahl bedeutet entweder unnötige operative Komplexität oder eine Architektur, die an der nächsten Wachstumsgrenze scheitert.

Semantische Produktempfehlungen, die auf Ähnlichkeit statt auf exakten Attributfiltern basieren, brauchen eine Möglichkeit, Embedding-Vektoren effizient nach Nähe zu durchsuchen. Redis Vector Search, aufbauend auf RediSearch, bringt genau diese Fähigkeit über HNSW- und FLAT-Indizes direkt in die ohnehin schon vorhandene Redis-Infrastruktur.

Sobald mehrere Prozesse auf dieselbe Ressource zugreifen, reicht ein lokales Mutex nicht mehr aus. Redis bietet mit SET NX PX ein einfaches Sperrprimitiv und mit dem Redlock-Algorithmus einen Ansatz fuer mehrere unabhaengige Instanzen, doch die bekannte Kritik von Martin Kleppmann zeigt klar, wo die Grenzen dieses Verfahrens liegen und wann einfachere Locks tatsaechlich ausreichen.

Write-Through schreibt synchron in Cache und Datenbank und garantiert damit Konsistenz um den Preis zusaetzlicher Latenz. Write-Back schreibt nur in den Cache und verzoegert die Datenbank asynchron, was Latenz spart, aber ein reales Risiko fuer Datenverlust bei einem Ausfall des Cache-Servers erzeugt. Welche Strategie passt, haengt von den Konsistenzanforderungen der jeweiligen Daten ab.

Redis und Varnish werden in Magento-Diskussionen oft gegeneinander gestellt, dabei loesen sie grundverschiedene Probleme. Redis ist das Cache- und Session-Backend fuer Objektcache und Full-Page-Cache-Speicherung, Varnish ist der HTTP-Layer davor, der ganze Seiten ausliefert, bevor Magento ueberhaupt gestartet wird. Dieser Artikel erklaert die saubere Rollenverteilung.