Redis Key-Namespacing-Strategien für Multi-Tenancy im Vergleich

1. Warum Multi-Tenancy in Redis eine explizite Entscheidung braucht

Anders als relationale Datenbanksysteme mit eigenen Schemata pro Mandant oder dedizierten Zugriffsrechten pro Tabelle bietet Redis von Haus aus keine eingebaute Mandantentrennung. Jeder Schlüssel liegt in einem flachen, globalen Namensraum innerhalb der jeweiligen logischen Datenbank, und ohne bewusste Konvention können Schlüssel unterschiedlicher Mandanten kollidieren oder sich gegenseitig überschreiben.

Diese Offenheit ist einerseits ein Vorteil, weil sie maximale Flexibilität bei der Wahl der Isolationsstrategie erlaubt, andererseits aber auch ein Risiko, weil ohne dokumentierte Namenskonvention die Trennung stillschweigend aufweichen kann, sobald neue Entwickler oder neue Services hinzukommen. Genau deshalb muss die Namespacing-Strategie von Anfang an bewusst festgelegt und nicht nachträglich als Notlösung eingeführt werden.

2. Präfix-basierte Namensräume im Detail

Bei diesem Ansatz erhält jeder Mandant ein eindeutiges Präfix, das jedem Schlüssel vorangestellt wird, etwa tenant:123:cache:product:456 für Produkt 456 von Mandant 123. Alle Mandanten teilen sich dieselbe Redis-Instanz und dieselbe logische Datenbank, die Trennung existiert ausschließlich auf Anwendungsebene durch Konvention, nicht durch eine technische Barriere im Server selbst.

Der große Vorteil dieses Modells liegt in seiner uneingeschränkten Skalierbarkeit: Da alle Daten in einem einzigen flachen Schlüsselraum liegen, lässt sich die Instanz problemlos als Redis Cluster mit Hash-Slot-Sharding betreiben, was bei den beiden anderen Strategien deutlich komplizierter wird. Der Nachteil ist die fehlende technische Isolation: Ein Programmierfehler, der versehentlich ein falsches Präfix verwendet oder das Präfix ganz vergisst, kann Daten mehrerer Mandanten vermischen, ohne dass Redis selbst dies verhindert.

# Präfix-Konvention pro Mandant, gemeinsame Datenbank
SET tenant:123:cache:product:456 "..."
SET tenant:789:cache:product:456 "..."
SCAN 0 MATCH tenant:123:* COUNT 100

3. Logische Datenbanken über den SELECT-Index

Redis unterstützt standardmäßig sechzehn logische Datenbanken innerhalb einer einzigen Instanz, adressiert über einen numerischen Index von 0 bis 15, zwischen denen ein Client per SELECT-Befehl wechselt. Jeder Mandant bekäme in diesem Modell eine eigene Datenbanknummer zugewiesen, wodurch FLUSHDB gezielt nur die Daten dieses einen Mandanten löscht, ohne die übrigen zu berühren, was gegenüber dem reinen Präfix-Modell bereits einen echten Sicherheitsgewinn darstellt.

Die Grenzen dieses Ansatzes zeigen sich jedoch schnell: Redis Cluster unterstützt grundsätzlich nur die Datenbank 0 und verweigert die Nutzung mehrerer logischer Datenbanken vollständig, was diese Strategie für horizontal skalierte Cluster-Setups von vornherein ausschließt. Zusätzlich lässt sich pro logischer Datenbank kein eigenes ACL-Recht vergeben, sodass ein Benutzer entweder Zugriff auf alle sechzehn Datenbanken hat oder auf keine, was die Isolation auf Berechtigungsebene wieder aufweicht.

# Mandant 123 nutzt Datenbank 3, Mandant 789 nutzt Datenbank 7
redis-cli -n 3 SET cache:product:456 "..."
redis-cli -n 3 FLUSHDB
redis-cli -n 7 SET cache:product:456 ".."

4. Vollständig getrennte Instanzen pro Mandant

Die maximale Isolationsstufe besteht darin, jedem Mandanten eine eigene, vollständig unabhängige Redis-Instanz mit eigenem Prozess, eigenem Port und eigener Konfiguration zuzuweisen. Diese Trennung ist auf Betriebssystemebene real und lässt sich zusätzlich durch eigene Netzwerksegmente, eigene TLS-Zertifikate und eigene ACL-Benutzer weiter absichern, ohne auf anwendungsseitige Konventionen angewiesen zu sein.

Der Preis dafür ist ein deutlich höherer Betriebsaufwand: Jede Instanz muss einzeln überwacht, aktualisiert und dimensioniert werden, und die Anzahl der Instanzen wächst linear mit der Anzahl der Mandanten, was bei mehreren Dutzend oder gar hunderten Mandanten schnell zu einer kaum noch überschaubaren Infrastruktur führt. Zusätzlich verursacht jede Instanz einen fixen Speicher-Overhead für interne Datenstrukturen, der bei sehr vielen kleinen Mandanten anteilig ins Gewicht fällt.

5. Trade-offs bei Isolation und dem Noisy-Neighbor-Problem

Ein zentrales Risiko geteilter Instanzen, unabhängig davon ob über Präfixe oder logische Datenbanken getrennt, ist das Noisy-Neighbor-Problem: Da Redis intern weitgehend single-threaded arbeitet, kann ein rechenintensiver Befehl eines einzigen Mandanten, etwa ein unglücklich formulierter Lua-Skript-Aufruf oder eine große Sortieroperation, die gesamte Instanz für alle übrigen Mandanten spürbar verlangsamen.

Getrennte Instanzen lösen dieses Problem strukturell, weil jeder Mandant seine eigene Rechenkapazität und seinen eigenen Ereignisloop erhält. Innerhalb einer geteilten Instanz lässt sich das Risiko nur durch sorgfältiges Command-Filtering über ACL-Kategorien, konsequente Verwendung nicht-blockierender Befehlsvarianten wie SCAN statt KEYS und ein striktes Monitoring rechenintensiver Operationen pro Mandant begrenzen, jedoch nie vollständig eliminieren.

6. Backup-Granularität je nach Strategie

Bei getrennten Instanzen ist ein selektives Backup oder eine selektive Wiederherstellung eines einzelnen Mandanten trivial, weil RDB-Snapshot oder AOF-Datei ohnehin ausschließlich Daten dieses Mandanten enthalten. Bei logischen Datenbanken lässt sich zumindest über DUMP und RESTORE pro Schlüssel oder über SELECT in Kombination mit einem externen Skript ein gezielter Export einer einzelnen Datenbank realisieren, wenn auch mit spürbar mehr eigenem Aufwand als bei getrennten Instanzen.

Beim reinen Präfix-Modell ist eine gezielte Wiederherstellung eines einzelnen Mandanten am aufwändigsten, weil weder RDB noch AOF eine native Filterung nach Präfix unterstützen. In der Praxis bleibt dann nur ein SCAN über das entsprechende Präfixmuster mit anschließendem DUMP jedes gefundenen Schlüssels, ein Verfahren, das bei sehr vielen Schlüsseln spürbar Zeit kostet und für ein regelmäßiges, automatisiertes Backup pro Mandant eigens implementiert werden muss.

7. Skalierung: Sharding pro Mandant versus globales Cluster

Präfix-basierte Namensräume lassen sich am elegantesten mit Redis Cluster und Hash-Tags kombinieren: Ein Hash-Tag wie {tenant:123} innerhalb des Schlüsselnamens sorgt dafür, dass alle Schlüssel desselben Mandanten demselben Hash-Slot und damit demselben Cluster-Knoten zugeordnet werden, was Multi-Key-Operationen innerhalb eines Mandanten weiterhin erlaubt, während die Gesamtlast über viele Knoten verteilt wird.

Logische Datenbanken scheiden für Cluster-Setups praktisch aus, da Redis Cluster nur Datenbank 0 unterstützt, und getrennte Instanzen skalieren zwar pro Mandant unabhängig, erfordern aber eine eigene Orchestrierungsschicht, die entscheidet, welcher Mandant auf welcher physischen oder virtuellen Maschine läuft, was bei starkem Mandantenwachstum zu einem eigenständigen, nicht zu unterschätzenden Betriebsprojekt wird.

8. Migration zwischen den Modellen ohne Datenverlust

Ein häufiger Auslöser für einen Strategiewechsel ist die geplante Umstellung auf Redis Cluster, wenn ein bisher über logische Datenbanken getrenntes Multi-Tenant-Setup an seine Grenzen stößt. Da Cluster nur Datenbank 0 unterstützt, müssen alle Schlüssel aus den Datenbanken 1 bis 15 vor der Umstellung mit einem passenden Präfix versehen und in Datenbank 0 zusammengeführt werden, bevor der Cluster-Modus überhaupt aktiviert werden kann.

In der Praxis läuft diese Migration am sichersten über eine Übergangsphase mit doppelter Schreibung: Die Anwendung schreibt neue Daten bereits parallel unter dem neuen Präfix-Schema in Datenbank 0, während Lesezugriffe zunächst weiterhin bevorzugt aus der alten logischen Datenbank bedient werden, bis ein Hintergrundprozess per SCAN und MIGRATE sämtliche verbliebenen Altdaten schrittweise überträgt und die Anwendung anschließend vollständig auf das neue Schema umschaltet.

# Schlüssel aus Datenbank 3 mit neuem Präfix nach Datenbank 0 migrieren
redis-cli -n 3 --scan MATCH "*" | while read -r key; do
  redis-cli -n 3 MIGRATE 127.0.0.1 6379 "tenant:123:$key" 0 5000
done

9. Praktische Empfehlung für Multi-Store-Magento-Setups

Für ein Magento-Setup mit mehreren Store-Views, die sich denselben Cache-Layer teilen, hat sich in der Praxis eine Kombination bewährt: Für den Full-Page-Cache und den Objekt-Cache empfiehlt sich ein präfix-basiertes Namensschema pro Store-View, weil Magento diese Präfixierung über die Cache-ID-Präfixe ohnehin schon nativ unterstützt und die spätere Cluster-Fähigkeit dadurch nicht verbaut wird.

Für Sessions dagegen, die pro Mandant klar abgegrenzt und regelmäßig gezielt bereinigt werden müssen, bietet sich eine eigene logische Datenbank an, solange keine Cluster-Topologie im Einsatz ist, weil FLUSHDB dort ein gezieltes und risikoarmes Werkzeug für das Zurücksetzen einzelner Store-Sessions liefert. Erst bei einer sehr großen Anzahl unabhängiger Mandanten mit eigenen Compliance-Anforderungen, etwa bei einem White-Label-Betrieb mit rechtlich getrennten Kunden, rechtfertigt sich der Mehraufwand vollständig getrennter Instanzen.

10. Zusammenfassung

11. FAQ: Key-Namespacing in Redis: Das Wichtigste auf einen Blick