Wofür wir Redis einsetzen
In Shopware 6 nimmt Redis den Objekt- und HTTP-Cache sowie die Sessions auf. Das entlastet die Datenbank spürbar, weil Warenkorb und Anmeldestatus nicht mehr über Tabellen laufen, die bei jedem Seitenaufruf geschrieben werden. In TYPO3 übernimmt Redis die Caching-Framework-Backends. Bei eigenen Symfony-Anwendungen nutzen wir ihn zusätzlich als Transport für Symfony Messenger, damit Importe, Mailversand und ERP-Abgleiche nicht im Web-Request hängen.
Typisch sind Projekte mit mehreren Anwendungsservern hinter einem Loadbalancer. Sobald Sitzungen nicht mehr auf einer einzelnen Maschine liegen dürfen, braucht es einen gemeinsamen Speicher — dafür ist Redis der naheliegende Weg. Ebenso bei Shops mit vielen gleichzeitigen Zugriffen auf dieselben Kategorieseiten. Was sich dagegen nicht lösen lässt: Ein Cache hilft nur beim zweiten Aufruf. Der erste bleibt so langsam, wie die Anwendung ihn baut.
Wie wir Redis betreiben
Redis läuft bei uns in eigenen Containern auf dem Proxmox-Cluster, getrennt nach Verwendungszweck. Cache und Sessions teilen sich nicht dieselbe Instanz, weil sie unterschiedliche Regeln brauchen: Ein Cache darf Einträge verwerfen, eine Sitzung nicht. Genau daran scheitern viele Installationen. Steht maxmemory-policy auf allkeys-lru und liegen die Sessions in derselben Datenbank, werden Warenkörbe unter Last einfach entfernt — und niemand findet den Grund im Shop-Log.
Dazu gehören Persistenzeinstellungen, ein festes Speicherlimit und Monitoring auf Speicherauslastung, verworfene Schlüssel und Trefferquote. Redis ist außerdem nicht öffentlich erreichbar, sondern nur im internen Netz und mit Passwort. Bei Deployments prüfen wir, ob Cache-Schlüssel versioniert sind, damit ein Release nicht auf alte Strukturen trifft. Und wir leeren im Zweifel gezielt, statt pauschal alles zu verwerfen und den Shop kalt starten zu lassen.
Wann Sie Redis nicht brauchen
Ein einzelner Webserver mit überschaubarem Traffic kommt ohne Redis aus. Sessions im Dateisystem und der Datenbank-Cache reichen dann, und Sie sparen sich einen weiteren Dienst, der überwacht, aktualisiert und im Störungsfall verstanden werden muss. Redis wird oft verkauft, wo eine fehlende Index-Definition das eigentliche Problem war. Nach dem Index war die Abfrage schnell genug — der Cache hätte sie nur verdeckt.
Unsere Reihenfolge ist deshalb: erst messen, dann die Abfrage oder den Code reparieren, dann cachen. Wer zuerst cacht, verschiebt das Problem auf den Tag, an dem der Cache leer ist — nach einem Deployment, nach einem Neustart, nach einer Preisänderung im gesamten Sortiment. Dann trifft die volle Last eine Anwendung, die nie dafür gebaut wurde. Wir sagen Ihnen das lieber vorher.