Redis Cluster: Sharding-Grundlagen verstehen

1. Warum Sharding in Redis überhaupt nötig wird

Redis Cluster löst ein Problem, das reine Master-Replica-Replikation nicht lösen kann: Ein einzelner Redis-Prozess ist immer durch den Arbeitsspeicher und die Netzwerkbandbreite eines einzelnen Hosts begrenzt. Replicas erhöhen die Lesekapazität und die Ausfallsicherheit, aber jede Replica enthält eine vollständige Kopie derselben Daten, keine zusätzliche Kapazität für die Gesamtmenge. Wächst der Datensatz über die Größe des größten verfügbaren Hosts hinaus, oder übersteigt der Schreib-Durchsatz die Kapazität eines einzelnen Masters, bleibt nur eine Lösung: die Daten auf mehrere unabhängige Knoten aufzuteilen. Genau das ist Sharding, und Redis Cluster ist die eingebaute Implementierung dafür.

Der grundlegende Unterschied zu manuellem Sharding auf Anwendungsebene, bei dem eine Anwendung selbst entscheidet, welcher Key auf welchem Redis-Knoten liegt, ist, dass Redis Cluster diese Zuordnung transparent und automatisch verwaltet. Die Anwendung verbindet sich mit einem beliebigen Knoten des Clusters, und das Cluster selbst leitet Anfragen intern an den zuständigen Knoten weiter oder informiert den Client per Redirect über die korrekte Adresse. Das reduziert die Komplexität in der Anwendung erheblich, verlagert die Komplexität aber in die Cluster-Infrastruktur selbst, die verstanden werden muss, um Fehler zu vermeiden.

Das Kernkonzept, das Redis Cluster Sharding von naiven Ansätzen wie modulo-basiertem Hashing unterscheidet, sind die 16384 festen Hash Slots. Statt Keys direkt auf Knoten abzubilden, mappt Redis jeden Key zunächst auf einen von 16384 Slots, und jeder Slot wird anschließend genau einem Knoten zugewiesen. Diese Indirektionsebene ist der Grund, warum Knoten später hinzugefügt oder entfernt werden können, ohne die Hash-Funktion selbst zu ändern, dazu mehr in den folgenden Abschnitten.

2. Hash Slots: die 16384 Slots im Detail

Redis Cluster unterteilt den gesamten Keyspace in exakt 16384 Hash Slots, nummeriert von 0 bis 16383. Diese Zahl ist bewusst gewählt: Sie ist groß genug, um eine feingranulare Verteilung über hunderte Knoten zu erlauben, aber klein genug, dass die Bitmap zur Darstellung, welcher Knoten welche Slots besitzt, kompakt bleibt (16384 Bit entsprechen exakt 2 KB), was bei den regelmäßigen Gossip-Nachrichten zwischen den Knoten die Netzwerklast gering hält. Eine größere Slot-Anzahl, etwa 65536, würde diese Kompaktheit verschlechtern, ohne bei realistischen Clustergrößen einen praktischen Vorteil zu bringen.

Jeder Knoten im Cluster ist für eine zusammenhängende oder auch nicht zusammenhängende Teilmenge dieser 16384 Slots verantwortlich. Bei drei Master-Knoten könnte eine gleichmäßige Verteilung beispielsweise Slots 0 bis 5460 auf Knoten A, 5461 bis 10922 auf Knoten B und 10923 bis 16383 auf Knoten C zuweisen. Diese Zuordnung ist nicht statisch im Sinne einer festen Formel, sondern eine explizite Konfiguration, die im Cluster-Zustand jedes Knotens gespeichert ist und sich durch Resharding-Operationen ändern lässt, ohne dass sich die Gesamtzahl von 16384 Slots je ändert.

# Inspect current slot ownership across the cluster
redis-cli -c -p 7000 cluster slots

# Example output structure (simplified)
# 1) 1) (integer) 0        # slot range start
#    2) (integer) 5460     # slot range end
#    3) 1) "10.0.2.10"     # master node
#       2) (integer) 7000
#    4) 1) "10.0.2.13"     # replica node
#       2) (integer) 7000

# Check how many slots a specific node currently owns
redis-cli -c -p 7000 cluster nodes | grep myself

# Ask which slot a given key would map to
redis-cli -c -p 7000 cluster keyslot "order:48213"
# -> (integer) 9842

Ein wichtiger Punkt: Jeder Slot muss im Cluster genau einem Master zugewiesen sein, ohne Lücken und ohne Überlappung, sonst gilt das Cluster als nicht vollständig abgedeckt und verweigert standardmäßig Schreibzugriffe. Der Parameter cluster-require-full-coverage kann das ändern, sollte aber mit Bedacht eingesetzt werden, denn er erlaubt dem Cluster, weiter Anfragen zu bedienen, obwohl ein Teil der Slots und damit ein Teil des Datenraums nicht erreichbar ist.

3. CRC16: wie Keys auf Slots gemappt werden

Die Zuordnung eines Keys zu einem Hash Slot in Redis Cluster erfolgt über eine deterministische Formel: HASH_SLOT = CRC16(key) mod 16384. CRC16 ist ein schneller, gut verteilender Prüfsummen-Algorithmus, der für jeden Key einen 16-Bit-Wert berechnet. Durch die Modulo-Operation mit 16384 wird dieser Wert auf den gültigen Slot-Bereich abgebildet. Wichtig dabei: Diese Berechnung ist rein clientseitig nachvollziehbar und deterministisch, jeder Client kann für einen gegebenen Key vorab berechnen, in welchem Slot er landet, ohne den Cluster fragen zu müssen.

Diese Eigenschaft macht Redis Cluster clients effizient: Statt bei jedem Zugriff blind einen zufälligen Knoten anzufragen und auf einen Redirect zu warten, berechnen moderne Cluster-fähige Client-Bibliotheken den Slot lokal, halten eine Slot-zu-Knoten-Zuordnungstabelle im Speicher und verbinden sich direkt mit dem richtigen Knoten. Diese Tabelle wird nur bei einem MOVED-Redirect aktualisiert, was signalisiert, dass sich die Cluster-Topologie geändert hat, etwa durch ein Resharding oder einen Failover.

# CRC16 slot calculation, conceptually (Redis uses CRC16-CCITT
# with a specific 256-entry lookup table, simplified here)
def key_hash_slot(key: str) -> int:
    # Only the substring inside {} matters if hash tags are used
    key_for_hashing = extract_hash_tag(key) or key
    return crc16(key_for_hashing.encode()) % 16384

# Real-world verification against a running cluster
redis-cli -c -p 7000 cluster keyslot "session:user:9931"
# -> (integer) 3300

redis-cli -c -p 7000 cluster keyslot "session:user:9932"
# -> (integer) 11821   # different key, likely different slot,
#                       # likely a different node

Ein häufiges Missverständnis: CRC16 sorgt nicht dafür, dass ähnliche Keys auf demselben Slot landen, im Gegenteil, es ist gerade das Ziel, dass selbst sehr ähnliche Keys wie user:1 und user:2 auf unterschiedliche, zufällig verteilte Slots abgebildet werden, um eine gleichmäßige Lastverteilung über alle Knoten zu erreichen. Wer stattdessen bewusst mehrere Keys auf denselben Knoten zwingen möchte, braucht dafür Hash Tags, das Thema des nächsten Abschnitts.

4. Hash Tags: Multi-Key-Operationen gezielt steuern

Redis Cluster unterstützt standardmäßig keine Multi-Key-Operationen wie MGET oder Transaktionen über MULTI/EXEC, wenn die beteiligten Keys auf unterschiedlichen Slots liegen, denn eine solche Operation würde mehrere Knoten gleichzeitig involvieren, was Redis Cluster architektonisch nicht unterstützt. Die Lösung dafür sind Hash Tags: Enthält ein Key geschweifte Klammern {...}, verwendet Redis Cluster für die Slot-Berechnung ausschließlich den Teil innerhalb der Klammern, nicht den gesamten Key.

Mit Keys wie {customer:4471}:orders und {customer:4471}:profile berechnet Redis Cluster den Hash Slot beider Keys nur aus customer:4471, wodurch garantiert beide auf demselben Slot und damit auf demselben Knoten landen. Das ermöglicht MGET {customer:4471}:orders {customer:4471}:profile in einem einzigen Aufruf sowie Transaktionen und Lua-Skripte, die mehrere zusammengehörige Keys gemeinsam bearbeiten, was ohne Hash Tags an der Cluster-Beschränkung scheitern würde.

# Without hash tags: keys likely land on different slots
redis-cli -c -p 7000 cluster keyslot "customer:4471:orders"
# -> (integer) 2145
redis-cli -c -p 7000 cluster keyslot "customer:4471:profile"
# -> (integer) 9903   # different slot, different node

# With hash tags: only the part inside {} is hashed
redis-cli -c -p 7000 cluster keyslot "{customer:4471}:orders"
# -> (integer) 6672
redis-cli -c -p 7000 cluster keyslot "{customer:4471}:profile"
# -> (integer) 6672   # identical slot, guaranteed same node

# Now multi-key operations work in a single call
redis-cli -c -p 7000 mget "{customer:4471}:orders" "{customer:4471}:profile"

# Transactions across related keys become possible
redis-cli -c -p 7000 <<'EOF'
MULTI
HSET {customer:4471}:profile status active
LPUSH {customer:4471}:orders order-88213
EXEC
EOF

Ein Risiko bei übermäßigem Einsatz von Hash Tags ist eine ungleichmäßige Verteilung: Werden zu viele Keys mit demselben Hash Tag versehen, konzentriert sich die Last auf einen einzigen Slot und damit auf einen einzigen Knoten, was den eigentlichen Sinn von Sharding untergräbt. Hash Tags sollten deshalb gezielt für kleine, logisch zusammengehörige Gruppen von Keys eingesetzt werden, etwa alle Daten eines einzelnen Kunden, nicht für ganze Entitätstypen mit Millionen von Datensätzen.

5. Cluster-Topologie: Master, Replicas und Gossip

Eine Redis Cluster-Topologie besteht aus mehreren Master-Knoten, die jeweils eine Teilmenge der 16384 Slots besitzen, sowie optionalen Replica-Knoten, die jeweils einen bestimmten Master replizieren. Fällt ein Master aus, kann das Cluster automatisch eine seiner Replicas befördern, ähnlich wie bei Sentinel, aber ohne separate Sentinel-Prozesse, da diese Logik direkt in jeden Cluster-Knoten eingebaut ist. Für Produktionssetups gilt die Faustregel: mindestens drei Master-Knoten, jeder mit mindestens einer Replica, verteilt über unterschiedliche Hosts oder Availability Zones.

Die Knoten kommunizieren untereinander über das Cluster-Bus-Protokoll, das auf Gossip basiert. Jeder Knoten tauscht periodisch mit einer zufälligen Teilmenge anderer Knoten Informationen über den bekannten Cluster-Zustand aus, welche Slots wem gehören, welche Knoten erreichbar sind, welche als ausgefallen gelten. Dieser Cluster-Bus läuft auf einem separaten Port, standardmäßig der Client-Port plus 10000, muss also zwischen allen Knoten zusätzlich zum normalen Redis-Port erreichbar sein.

# redis.conf: cluster-mode node configuration
port 7000
cluster-enabled yes
cluster-config-file nodes-7000.conf
cluster-node-timeout 15000
cluster-require-full-coverage yes

# The cluster bus uses port 7000+10000 = 17000, must be open
# between all nodes in addition to the client port itself

# Inspect the gossip-derived view of the whole cluster
redis-cli -c -p 7000 cluster nodes
# <id> <ip:port@bus-port> <flags> <master> <ping-sent> <pong-recv>
# <config-epoch> <link-state> <slot> <slot> ...

Der Parameter cluster-node-timeout bestimmt, wie lange ein Knoten als nicht erreichbar toleriert wird, bevor er als ausgefallen gilt und ein Failover ausgelöst wird. Ein zu kurzer Wert führt zu unnötigen Failovers bei kurzen Netzwerkschwankungen, ein zu langer Wert verlängert echte Ausfallzeiten. In den meisten Produktionsumgebungen hat sich ein Wert zwischen 10 und 15 Sekunden bewährt, abhängig von der Stabilität des zugrunde liegenden Netzwerks.

6. Cluster einrichten: redis-cli --cluster create

Das Einrichten eines Redis Cluster beginnt mit dem Starten einzelner Redis-Instanzen im Cluster-Modus, gefolgt vom Zusammenschluss dieser Instanzen zu einem Cluster. Der Befehl redis-cli --cluster create übernimmt dabei automatisch die initiale Verteilung der 16384 Slots über alle angegebenen Master-Knoten und ordnet Replicas den Mastern so zu, dass keine Replica auf demselben Host wie ihr Master liegt, sofern genug Hosts zur Verfügung stehen.

Für ein Setup mit drei Mastern und drei Replicas, also sechs Knoten insgesamt, teilt redis-cli --cluster create die Slots automatisch möglichst gleichmäßig auf, sodass jeder Master rund 5461 Slots besitzt. Diese initiale Verteilung lässt sich später jederzeit über Resharding anpassen, etwa wenn Knoten mit unterschiedlicher Hardware-Kapazität ungleich viele Slots tragen sollen.

# Start six Redis instances in cluster mode (ports 7000-7005)
for port in 7000 7001 7002 7003 7004 7005; do
  redis-server --port "$port" \
    --cluster-enabled yes \
    --cluster-config-file "nodes-${port}.conf" \
    --cluster-node-timeout 15000 \
    --daemonize yes
done

# Form the cluster: 3 masters, each with 1 replica
redis-cli --cluster create \
  10.0.2.10:7000 10.0.2.11:7001 10.0.2.12:7002 \
  10.0.2.13:7003 10.0.2.14:7004 10.0.2.15:7005 \
  --cluster-replicas 1

# Verify the cluster is healthy and fully covered
redis-cli -c -p 7000 cluster info
# cluster_state:ok
# cluster_slots_assigned:16384
# cluster_slots_ok:16384
# cluster_known_nodes:6
# cluster_size:3

Nach dem Setup ist es wichtig, mit cluster info zu prüfen, dass cluster_state auf ok steht und cluster_slots_assigned exakt 16384 zeigt. Steht der Zustand auf fail, sind meist nicht alle Slots zugewiesen, etwa weil ein Knoten während der Einrichtung nicht erreichbar war. In diesem Fall müssen die fehlenden Slots manuell per redis-cli --cluster fix nachgetragen werden, bevor das Cluster produktiv genutzt werden kann.

7. Slot-Verteilung und Rebalancing-Grundlagen

Die initiale Slot-Verteilung von Redis Cluster ist selten die finale. Wächst ein Teil des Datensatzes schneller als andere, oder werden neue Knoten mit mehr Kapazität hinzugefügt, muss die Verteilung der 16384 Slots angepasst werden. Der Befehl redis-cli --cluster rebalance berechnet automatisch eine gleichmäßigere Verteilung basierend auf der aktuellen Anzahl der Master-Knoten und verschiebt Slots entsprechend, während redis-cli --cluster reshard für gezielte, manuell definierte Verschiebungen einzelner Slot-Bereiche gedacht ist.

Wichtig zu verstehen: Die Slot-Verteilung muss nicht zwingend gleichmäßig sein. Redis Cluster erlaubt explizit, einem leistungsstärkeren Knoten mehr Slots zuzuweisen als einem schwächeren, über den --cluster-weight-Parameter beim Rebalancing. Das ist besonders bei heterogener Hardware relevant, etwa wenn ein Cluster über Jahre gewachsen ist und neuere Knoten mehr Arbeitsspeicher besitzen als die ursprünglichen.

# Automatic rebalance across all master nodes, weighted equally
redis-cli --cluster rebalance 10.0.2.10:7000

# Rebalance with custom weights (node with more RAM gets more slots)
redis-cli --cluster rebalance 10.0.2.10:7000 \
  --cluster-weight abc123def=2 \
  --cluster-weight 456ghi789=1

# Simulate the rebalance first without moving anything
redis-cli --cluster rebalance 10.0.2.10:7000 --cluster-simulate

# Check current slot distribution per node
redis-cli --cluster check 10.0.2.10:7000

Rebalancing ist ein Live-Vorgang, der während des laufenden Betriebs ausgeführt werden kann, verursacht aber zusätzliche Netzwerklast und CPU-Last auf den betroffenen Knoten, während Daten migriert werden. In produktiven Umgebungen empfiehlt es sich, Rebalancing außerhalb von Lastspitzen einzuplanen und den Fortschritt aktiv über cluster nodes zu beobachten, statt den Vorgang unbeaufsichtigt im Hintergrund laufen zu lassen.

8. Redirects: MOVED und ASK verstehen

Fragt ein Client einen Knoten nach einem Key, dessen Slot dieser Knoten nicht besitzt, antwortet Redis Cluster mit einem MOVED-Redirect, der die korrekte Knotenadresse für diesen Slot enthält. Cluster-fähige Clients folgen diesem Redirect automatisch und aktualisieren ihre lokale Slot-Tabelle, sodass zukünftige Anfragen für denselben Slot direkt an den richtigen Knoten gehen, ohne erneuten Umweg.

Während einer laufenden Slot-Migration, etwa während eines Resharding-Vorgangs, kann ein Slot vorübergehend teilweise auf dem alten und teilweise auf dem neuen Knoten liegen. In dieser Übergangsphase antwortet der alte Knoten mit einem ASK-Redirect statt MOVED, wenn der angefragte Key bereits migriert wurde. Der entscheidende Unterschied: ASK aktualisiert die lokale Slot-Tabelle des Clients nicht dauerhaft, es signalisiert nur für diese eine Anfrage, wohin sie umgeleitet werden soll, weil die Migration noch nicht final abgeschlossen ist.

# MOVED: permanent redirect, client should update its slot table
redis-cli -p 7000 get "order:99120"
# (error) MOVED 12539 10.0.2.12:7002

# Cluster-mode redis-cli follows redirects automatically with -c
redis-cli -c -p 7000 get "order:99120"
# -> "shipped"   # transparently redirected to 10.0.2.12:7002

# ASK: temporary redirect during an in-progress slot migration
# 1. Client must first send ASKING to the target node
redis-cli -p 7002 asking
redis-cli -p 7002 get "order:99120"
# (error) ASK 12539 10.0.2.13:7003   # if still mid-migration

Anwendungen, die eine eigene, nicht cluster-fähige Client-Bibliothek nutzen, müssen diese Redirect-Logik selbst implementieren, sonst schlagen Zugriffe während eines Resharding-Vorgangs fehl. Deshalb ist die Wahl einer nachweislich cluster-fähigen Client-Bibliothek für Redis Cluster keine Nebensächlichkeit, sondern eine der wichtigsten Entscheidungen beim Einstieg in gesharded Redis.

9. Grenzen und Fallstricke von Redis Cluster Sharding

Trotz aller Vorteile hat Redis Cluster klare architektonische Grenzen. Multi-Key-Operationen über Keys hinweg, die nicht per Hash Tag demselben Slot zugeordnet sind, funktionieren grundsätzlich nicht, das betrifft auch Datenbankauswahl über SELECT, die in Cluster-Modus komplett deaktiviert ist, alle Daten liegen faktisch in Datenbank 0. Auch KEYS * und FLUSHALL müssen auf jedem Knoten einzeln ausgeführt werden, es gibt keinen zentralen Befehl, der über das gesamte Cluster hinweg wirkt.

Ein weiterer Fallstrick betrifft Lua-Skripte und Transaktionen: Beide funktionieren in Redis Cluster nur, wenn alle referenzierten Keys im selben Slot liegen, was konsequente Nutzung von Hash Tags im Anwendungsdesign von Anfang an erfordert. Wer ein bestehendes Standalone-System nachträglich auf Redis Cluster migriert, muss deshalb oft das Key-Schema überarbeiten, nicht nur die Infrastruktur austauschen. Diese Migrationskosten sollten in jede Entscheidung für Sharding von Anfang an eingerechnet werden.

10. Zusammenfassung

Redis Cluster Sharding-Grundlagen lassen sich auf ein Kernprinzip reduzieren: 16384 feste Hash Slots bilden die Indirektionsebene zwischen Keys und physischen Knoten. CRC16 berechnet für jeden Key deterministisch den zuständigen Slot, während Hash Tags gezielt erlauben, mehrere zusammengehörige Keys auf denselben Slot und damit denselben Knoten zu zwingen, wenn Multi-Key-Operationen oder Transaktionen nötig sind. Diese drei Mechanismen zusammen ermöglichen horizontale Skalierung, ohne dass Anwendungen die Zuordnung von Keys zu Knoten selbst verwalten müssen.

Wer Redis Cluster einsetzt, muss von Anfang an mit den architektonischen Einschränkungen planen: kein SELECT, Multi-Key-Operationen nur mit passenden Hash Tags, und ein cluster-fähiger Client als Voraussetzung. Die initiale Slot-Verteilung über redis-cli --cluster create ist selten final, Rebalancing und Resharding gehören zum normalen Betrieb eines wachsenden Clusters dazu, nicht zu Ausnahmesituationen.

11. FAQ: Redis Cluster Sharding-Grundlagen