Redis Sentinel vs. Redis Cluster: Hochverfügbarkeit für den Shop-Cache

Warum braucht der Shop-Cache überhaupt Hochverfügbarkeit?

In modernen Shopsystemen wie Shopware, OXID, Magento oder Pimcore ist Redis längst mehr als ein optionaler Beschleuniger. Häufig laufen darüber: 

• der Objekt- und HTTP-Cache 
• Sessions der Besucherinnen und Besucher 
• Warenkörbe (in Shopware 6 optional direkt in Redis) 
• Locks, Nummernkreise und Zähler 
• Message-Queues für Hintergrundprozesse 

Fällt eine einzelne Redis-Instanz aus, ist die Wirkung sofort spürbar. Im besten Fall wird der Shop nur langsam, weil jede Anfrage wieder bis zur Datenbank durchgereicht wird. Im schlechteren Fall verlieren Kunden ihre Session oder ihren Warenkorb, oder der Shop antwortet gar nicht mehr, weil die Anwendung fest mit Redis rechnet.

Dabei lohnt sich eine Unterscheidung

• Cache-Daten lassen sich jederzeit neu aufbauen. Ein Verlust kostet Performance, aber keine Daten. 
• Sessions und Warenkörbe lassen sich nicht rekonstruieren. Ein Verlust kostet Umsatz und Vertrauen. 

Je mehr geschäftskritische Daten in Redis liegen, desto wichtiger wird eine hochverfügbare Architektur. 

Was ist Redis Sentinel? 

Redis Sentinel ist ein Überwachungs- und Failover-System für eine klassische Master-Replica-Konfiguration. Ein Master nimmt alle Schreibzugriffe an, ein oder mehrere Replikate halten eine Kopie der Daten. Separate Sentinel-Prozesse überwachen die Instanzen. 

So funktioniert ein Failover mit Sentinel: 

1. Die Sentinel-Prozesse prüfen laufend, ob der Master erreichbar ist. 
2. Meldet eine ausreichende Anzahl von Sentinels (das Quorum) den Master als ausgefallen, wird ein Failover eingeleitet. 
3. Die Sentinels bestimmen ein Replikat als neuen Master. 
4. Die übrigen Replikate werden auf den neuen Master umgestellt. 
5. Clients Fragen bei Sentinel nach, wer aktuell Master ist, und verbinden sich neu. 

Damit die Abstimmung zuverlässig funktioniert, sollten mindestens drei Sentinel-Instanzen auf getrennten Systemen laufen. So wird verhindert, dass ein einzelner Netzwerkfehler ein unnötiges Failover auslöst. 

Stärken und Schwächen von Sentinel

Stärken von Sentinel 

• Einfache Architektur: ein Datensatz, ein Master, klare Verhältnisse 
• Volle Redis-Funktionalität, inklusive mehrerer Datenbanken und Multi-Key-Operationen 
• Geringer Anpassungsaufwand in der Anwendung 
• Lesezugriffe können bei Bedarf auf Replikate verteilt werden 

Grenzen von Sentinel 

• Alle Daten müssen in den Arbeitsspeicher eines einzelnen Masters passen 
• Schreibzugriffe skalieren nur vertikal, also über einen stärkeren Server 
• Der Client muss Sentinel unterstützen oder über einen Proxy angebunden werden 
• Die Replikation erfolgt asynchron: Schreibvorgänge der letzten Millisekunden vor einem Ausfall können verloren gehen 

Was ist Redis Cluster?

Redis Cluster ist die verteilte Betriebsart von Redis. Der Datenbestand wird automatisch auf mehrere Master-Knoten aufgeteilt. Dazu nutzt Redis 16.384 sogenannte Hash-Slots: Jeder Schlüssel wird einem Slot zugeordnet, jeder Master verwaltet einen Teil der Slots. Jeder Master erhält in der Regel mindestens ein eigenes Replikat. 

Ein typisches Minimal-Setup besteht aus drei Mastern und drei Replikaten, also sechs Knoten. Fällt ein Master aus, übernimmt sein Replikat automatisch. Ein separates Sentinel-System ist nicht nötig, die Überwachung ist im Cluster integriert. 

Stärken und Schwächen von Redis Cluster

Stärken von Redis Cluster 

• Horizontale Skalierung: mehr Speicher und mehr Schreibleistung durch zusätzliche Knoten 
• Integriertes Failover ohne zusätzliche Sentinel-Prozesse 
• Ein Ausfall betrifft nur den Teil der Daten, der auf dem betroffenen Knoten liegt, bis das Replikat übernommen hat 
• Geeignet für sehr große Datenmengen und hohe Last 

Grenzen von Redis Cluster 

• Operationen über mehrere Schlüssel funktionieren nur, wenn alle Schlüssel im selben Hash-Slot liegen (steuerbar über sogenannte Hash-Tags) 
• Es gibt nur eine Datenbank (Datenbank 0), eine Trennung per SELECT entfällt 
• Client, Framework und Plugins müssen den Cluster-Modus unterstützen 
• Höherer Betriebsaufwand bei Monitoring, Resharding und Fehleranalyse 
• Auch hier ist die Replikation asynchron 

Redis Sentinel und Redis Cluster im direkten Vergleich 

Datenverteilung 

• Sentinel: alle Daten auf einem Master 
• Cluster: Daten verteilt auf mehrere Master 

Skalierung 

• Sentinel: vertikal (größerer Server), Lesezugriffe über Replikate 
• Cluster: horizontal (zusätzliche Knoten) 

Failover 

• Sentinel: über separate Sentinel-Prozesse 
• Cluster: integriert 

Minimale Knotenzahl für echte Ausfallsicherheit 

• Sentinel: ein Master, ein bis zwei Replikate, drei Sentinels 
• Cluster: in der Regel drei Master und drei Replikate 

Kompatibilität mit Shop-Software 

• Sentinel: breit unterstützt, wenig Anpassung nötig 
• Cluster: Unterstützung im Einzelfall prüfen, vor allem bei Plugins und Erweiterungen 

Betriebsaufwand 

• Sentinel: überschaubar 
• Cluster: höher 

Typischer Einsatz 

• Sentinel: kleine bis große Shops, deren Redis-Daten auf einen Server passen 
• Cluster: sehr große Plattformen, Marktplätze, SaaS-Anwendungen mit hohem Schreibvolumen 

Welche Variante passt zu Ihrem Online-Shop?

Die Entscheidung hängt weniger von der Shopgröße ab als von zwei Fragen: Passt Ihr Redis-Datenbestand in den Arbeitsspeicher eines Servers? Und reicht die Schreibleistung eines einzelnen Masters? 

Redis Sentinel ist die richtige Wahl, wenn: 

• Ihr Redis-Speicherbedarf im Bereich weniger bis einiger Dutzend Gigabyte liegt 
• Sie Ausfallsicherheit wollen, aber keine horizontale Skalierung brauchen 
• Ihre Shop-Software und Ihre Plugins nicht explizit für den Cluster-Modus getestet sind 
• Sie eine schlanke, gut beherrschbare Architektur bevorzugen 

Redis Cluster ist die richtige Wahl, wenn: 

• der Datenbestand dauerhaft größer ist als der sinnvoll nutzbare Arbeitsspeicher eines Servers 
• ein einzelner Master beim Schreibdurchsatz nachweislich an seine Grenzen kommt 
• Ihre Anwendung von Anfang an auf Cluster-Betrieb ausgelegt ist 
• Sie über das Know-how oder einen Partner verfügen, der den Cluster betreibt 

Praxisbeispiel: Ein mittelgroßer Shopware-Shop mit einigen Tausend Besuchern pro Stunde nutzt Redis für Cache, Sessions und Warenkörbe. Der Speicherbedarf liegt bei rund 8 GB. Hier bringt ein Cluster keinen messbaren Vorteil, erhöht aber Komplexität und Kosten. Ein Setup aus Master, Replikat und drei Sentinels deckt den Bedarf an Ausfallsicherheit vollständig ab. 

Anders sieht es bei einer Plattform mit mehreren Storefronts, Millionen Artikeln und einem großen Anteil an personalisierten Inhalten aus. Wächst der Cache hier auf eine dreistellige Gigabyte-Zahl und laufen parallel viele Schreibprozesse, spielt Redis Cluster seine Stärken aus.

Best Practices für einen hochverfügbaren Shop-Cache 

Unabhängig von der gewählten Architektur haben sich in der Praxis einige Grundregeln bewährt: 

1. Cache und Sessions trennen: Betreiben Sie Cache-Daten und persistente Daten wie Sessions oder Warenkörbe in getrennten Redis-Instanzen. So kann der Cache Daten verdrängen, ohne dass Sessions verloren gehen. 
2. Eviction-Policy passend wählen: Für reine Cache-Instanzen eignet sich meist allkeys-lru oder volatile-lru. Für Session-Instanzen ist noeviction sinnvoll, damit keine Sessions stillschweigend gelöscht werden. 
3. Persistenz gezielt einsetzen: Für Sessions und Warenkörbe lohnt sich Persistenz (AOF oder RDB-Snapshots). Für den reinen Cache ist sie meist überflüssig. 
4. Knoten räumlich trennen: Master, Replikate und Sentinels gehören auf unterschiedliche physische Systeme, idealerweise mit getrennter Stromversorgung und Netzanbindung. 
5. Clients korrekt konfigurieren: Prüfen Sie, ob Ihre Shop-Software die Sentinel- bzw. Cluster-Verbindung unterstützt, und testen Sie Timeouts und Reconnect-Verhalten. 
6. Failover regelmäßig testen: Ein Failover, das nie geprobt wurde, funktioniert im Ernstfall selten reibungslos. Testen Sie gezielt vor Lastspitzen wie Black Friday. 
7. Monitoring einrichten: Überwachen Sie Speicherauslastung, Replikationsverzögerung, Verbindungszahlen und Hit-Rate. 

Typische Fehler, die Sie vermeiden sollten

• Nur zwei Sentinel-Instanzen: Ohne ungerade Anzahl und ausreichendes Quorum ist kein zuverlässiges Failover möglich. 
• Sentinels auf demselben Server wie der Master: Fällt der Server aus, fehlen auch die Wächter. 
• Cluster aus reiner Vorsicht: Wer Cluster einsetzt, ohne ihn zu brauchen, handelt sich Komplexität ein, die im Alltag mehr Fehler verursacht als verhindert. 
• Plugins ungetestet lassen: Einzelne Erweiterungen greifen direkt auf Redis zu und brechen im Cluster-Modus bei Multi-Key-Operationen. 
• Alles in einer Instanz: Cache, Sessions, Queues und Locks in einer einzigen Instanz erschweren sowohl die Skalierung als auch die Fehlersuche. 

Hochverfügbares Redis ohne eigenen Betriebsaufwand

Beide Architekturen verlangen Erfahrung beim Aufbau und vor allem im laufenden Betrieb: Updates, Monitoring, Failover-Tests und Kapazitätsplanung. Genau hier setzt der Redis FlexServer von profihost an. 

Das bietet Ihnen der Redis FlexServer: 

• Dedizierte Redis-Umgebung, die Ihre Datenbank entlastet und Zugriffszeiten deutlich verkürzt 
• Hochverfügbarkeit mit 3-fach redundanter Architektur, automatischem Failover und Datenreplikation 
• Flexible Konfiguration, abgestimmt auf Ihren Shop und Ihre Lastprofile 
• Betrieb in deutschen Rechenzentren 
• Persönliche Betreuung durch unser Managed-Support-Team statt Callcenter 

Gemeinsam mit Ihnen klären wir, welche Architektur für Ihren Shop sinnvoll ist, wie Cache und Sessions am besten getrennt werden und wie sich die Anbindung an Shopware, OXID, Magento oder Pimcore sauber umsetzen lässt.