Redis Cluster verstehen: Wie Clients auf den richtigen Shard zugreifen

Hintergrund: Warum brauchen wir Redis Cluster

Der Sentinel-Modus basiert auf dem Master-Slave-Modell und ermöglicht die Trennung von Lese- und Schreibvorgängen. Er unterstützt auch automatisches Failover, was die Systemverfügbarkeit verbessert. Da jedoch jeder Knoten die gleichen Daten speichert, wird Speicherplatz verschwendet und die Online-Skalierung erschwert.

Daher entstand Redis Cluster (eine Lösung zur Implementierung eines Sharded Clusters). Es wurde in Redis 3.0 eingeführt und ermöglicht die verteilte Speicherung in Redis. Es shardet Daten, was bedeutet, dass jeder Redis-Knoten unterschiedliche Inhalte speichert, wodurch das Problem der Online-Erweiterung gelöst wird. Zusätzlich kann es große Datenmengen speichern, indem es sie auf verschiedene Redis-Instanzen verteilt, und bietet gleichzeitig Replikations- und Failover-Funktionen.

Wenn beispielsweise eine einzelne Redis-Instanz 15 GB oder mehr Daten speichert, wird die Antwortzeit langsam. Dies liegt am RDB-Persistenzmechanismus von Redis. Redis forkt einen Kindprozess, um die RDB-Persistenz durchzuführen, und die Zeit, die der Fork-Vorgang benötigt, ist direkt proportional zur Größe der Redis-Daten.

An diesem Punkt könnten Sie natürlich denken: Warum verteilen wir die 15 GB Daten nicht einfach auf mehrere Knoten? Das ist genau die Motivation hinter Redis Sharded Clustern. Was genau ist also ein Sharded Cluster? Schauen wir uns ein Beispiel an. Wenn Sie 15 GB Daten mit Redis speichern möchten, können Sie entweder eine einzelne Redis-Instanz verwenden oder einen Sharded Cluster mit 3 Redis-Instanzen erstellen. Hier ist ein Vergleich:

Unterschied zwischen einem Sharded Cluster und Redis Cluster: Redis Cluster ist die offizielle Sharded Cluster-Implementierung, die in Redis 3.0 eingeführt wurde.

Da die Daten nun auf verschiedene Redis-Instanzen verteilt sind, woher weiß der Client, welche Instanz die Daten enthält, auf die er zugreifen möchte? Schauen wir uns an, wie Redis Cluster dies handhabt.

Woher weiß der Client, auf welchen Shard er zugreifen muss?

Redis Cluster verwendet Hash-Slots, um die Zuordnung zwischen Daten und Instanzen zu verwalten.

Ein Sharded Cluster ist in 16.384 Slots unterteilt. Jedes Key-Value-Paar, das in Redis eingeht, wird basierend auf seinem Schlüssel gehasht und einem dieser 16.384 Slots zugewiesen. Die Hashing-Methode ist einfach: Der CRC16-Algorithmus berechnet einen 16-Bit-Wert, der dann durch 16.384 geteilt wird. Jeder Schlüssel in der Datenbank gehört zu einem dieser 16.384 Slots, und jeder Knoten im Cluster verwaltet einen Teil davon.

Jeder Knoten im Cluster ist für einen Teil der Hash-Slots verantwortlich. Angenommen, der Cluster hat drei Knoten: A, B und C. Dann wäre jeder Knoten für ungefähr 16.384 / 3 Slots verantwortlich. Eine mögliche Verteilung könnte so aussehen:

Knoten A verwaltet die Hash-Slots 0–5460
Knoten B verwaltet die Hash-Slots 5461–10922
Knoten C verwaltet die Hash-Slots 10923–16383

Was passiert also, wenn der Client einen Lese-/Schreibvorgang an eine Redis-Instanz sendet, die nicht die entsprechenden Daten enthält? Hier kommen die MOVED- und ASK-Weiterleitungen ins Spiel.

3. Was passiert, wenn sich die Daten nicht auf der Zielinstanz befinden?

Im Redis Cluster-Modus verarbeitet ein Knoten Anfragen wie folgt:

Mithilfe der Hash-Slot-Zuordnung prüft der Knoten, ob der angeforderte Redis-Schlüssel zum aktuellen Knoten gehört.
Wenn der Hash-Slot nicht von diesem Knoten verwaltet wird, gibt er eine MOVED-Weiterleitung zurück.
Wenn der Hash-Slot tatsächlich von diesem Knoten verwaltet wird und der Schlüssel im Slot vorhanden ist, gibt er das entsprechende Ergebnis zurück.
Wenn der Redis-Schlüssel im Slot nicht vorhanden ist, prüft er, ob der Hash-Slot gerade migriert wird (MIGRATING).
Wenn der Redis-Schlüssel migriert wird, gibt er einen ASK-Fehler zurück und leitet den Client an den Zielserver weiter, auf den der Schlüssel verschoben wird.
Wenn der Hash-Slot nicht migriert wird, prüft er, ob der Slot importiert wird.
Wenn der Slot importiert wird und das ASKING-Flag gesetzt ist, wird der Vorgang direkt fortgesetzt; andernfalls wird eine MOVED-Weiterleitung zurückgegeben.

3.1 MOVED-Weiterleitung

Wenn ein Client einen Lese-/Schreibvorgang an eine Redis-Instanz sendet und der berechnete Slot nicht zu diesem Knoten gehört, gibt Redis einen MOVED-Weiterleitungsfehler zurück. Diese Antwort enthält die IP-Adresse und den Port des korrekten Redis-Knotens, auf dem sich der Slot befindet. Dies ist der MOVED-Weiterleitungsmechanismus, der von Redis Cluster verwendet wird.

3.2 ASK-Weiterleitung

Die ASK-Weiterleitung tritt typischerweise während des Cluster-Reshardings auf. Resharding führt dazu, dass Slots migriert werden. Wenn ein Client versucht, auf den Quellknoten zuzugreifen, wurden die Daten möglicherweise bereits zum Zielknoten verschoben. Die ASK-Weiterleitung hilft, dieses Szenario zu bewältigen, indem sie den Client während des Migrationsprozesses an den neuen Knoten weiterleitet.

4. Wie kommunizieren Knoten miteinander?

Ein Redis-Cluster besteht aus mehreren Knoten. Wie kommunizieren sie? Durch das Gossip-Protokoll. Gossip ist ein Nachrichtenverteilungsprotokoll, bei dem jeder Knoten regelmäßig k Knoten aus der Knotenliste auswählt und die von ihm gehaltenen Informationen verbreitet, bis alle Knoten einen Konsens erzielen – dies wird als Algorithmuskonvergenz bezeichnet.

Grundidee des Gossip-Protokolls: Ein Knoten möchte einige Informationen mit anderen Knoten im Netzwerk teilen. Er wählt regelmäßig und zufällig einige Knoten aus und sendet ihnen die Informationen. Diese Knoten tun ihrerseits dasselbe – sie verbreiten die Informationen an andere zufällig ausgewählte Knoten. Typischerweise werden die Informationen an N Knoten weitergegeben, nicht nur an einen. Dieses N wird als Fanout bezeichnet.

Redis Cluster verwendet das Gossip-Protokoll, um Informationen zwischen Knoten auszutauschen. Dazu gehören Daten über Knotenausfälle, neue Knotenhinzufügungen, Master-Slave-Änderungen, Slot-Zuweisung und mehr. Das Gossip-Protokoll umfasst verschiedene Arten von Nachrichten, darunter ping, pong, meet und fail:

Meet-Nachricht: Benachrichtigt einen neuen Knoten, dem Cluster beizutreten. Der Absender teilt dem Empfänger mit, dem aktuellen Cluster beizutreten. Nachdem die meet-Nachricht erfolgreich empfangen wurde, tritt der empfangende Knoten dem Cluster bei und beginnt mit dem regelmäßigen Austausch von ping und pong.
Ping-Nachricht: Jeder Knoten sendet jede Sekunde eine ping-Nachricht an andere Knoten im Cluster. Die Nachricht enthält Informationen über zwei bekannte Knoten – wie ihre Adressen, Slots, Status und letzte Kommunikationszeit.
Pong-Nachricht: Wird als Antwort auf ping- oder meet-Nachrichten gesendet, um die erfolgreiche Kommunikation zu bestätigen. Sie enthält auch Informationen über zwei bekannte Knoten.
Fail-Nachricht: Wenn ein Knoten feststellt, dass ein anderer Knoten im Cluster offline ist, sendet er eine fail-Nachricht an den gesamten Cluster. Nach Erhalt dieser Nachricht markieren andere Knoten den entsprechenden Knoten als offline.

Beachtenswert ist, dass jeder Knoten mit anderen über einen Cluster-Bus kommuniziert. Diese Kommunikation verwendet einen speziellen Port, der der reguläre Redis-Port plus 10.000 ist. Wenn beispielsweise der Service-Port eines Knotens 6379 ist, dann ist sein Cluster-Kommunikationsport 16379. Die Knoten verwenden ein spezielles binäres Protokoll für die Kommunikation.

5. Was passiert, wenn ein Knoten im Cluster ausfällt?

Redis Cluster unterstützt hohe Verfügbarkeit. Wenn ein Knoten im Cluster ausfällt, verwendet das System Failover, um sicherzustellen, dass der Cluster weiterhin ordnungsgemäß externe Dienste bereitstellt.

Knoten offline

Redis Cluster verwendet ping/pong-Nachrichten zur Fehlererkennung. Dies umfasst subjektive und objektive Offline-Status:

Subjektiver Offline-Status (pfail): Ein Knoten glaubt, dass ein anderer Knoten nicht erreichbar ist, und markiert ihn als offline. Dies ist jedoch kein endgültiges Fehlerurteil – es spiegelt nur die Perspektive eines Knotens wider und kann ungenau sein.
Objektiver Offline-Status (fail): Markiert einen Knoten als wirklich offline, wenn mehrere Knoten im Cluster übereinstimmen, dass er nicht erreichbar ist. Dies ist eine konsensbasierte Entscheidung. Wenn der Offline-Knoten ein Master ist, dem Hash-Slots gehören, wird ein Failover-Prozess ausgelöst, um ihn zu ersetzen.

Wenn beispielsweise Knoten A Knoten B als subjektiv offline markiert, sendet er die Statusinformationen von Knoten B an andere Knoten. Wenn Knoten C diese Nachricht empfängt und analysiert und feststellt, dass Knoten B als pfail markiert ist, löst er den objektiven Offline-Prozess aus.

Wenn der Offline-Knoten ein Master ist, initiiert der Redis Cluster einen Abstimmungsprozess unter allen Mastern, denen Slots gehören. Wenn mehr als die Hälfte ihn als offline meldet, wird er offiziell als objektiv offline markiert.

Failover-Wiederherstellung

Sobald ein Fehler erkannt wurde, muss, wenn der Offline-Knoten ein Master ist, ein Replikat (Slave) gewählt werden, um ihn zu ersetzen, um eine hohe Verfügbarkeit zu gewährleisten. Der Failover-Prozess umfasst die folgenden Schritte:

Eignungsprüfung: Bestimmt, ob das Replikat die Bedingungen erfüllt, um den ausgefallenen Master zu ersetzen.
Vorbereitung der Failover-Verzögerung: Wenn das Replikat geeignet ist, legt es eine Verzögerungszeit fest, bevor das Failover initiiert wird.
Wahl einleiten: Wenn die Failover-Verzögerung abläuft, startet das Replikat den Wahlprozess.
Abstimmungssammlung: Nur Master, die Hash-Slots halten, dürfen abstimmen. Das Kandidatenreplikat muss genügend Stimmen (mehr als die Hälfte) sammeln, um mit dem Ersetzen des Masters fortzufahren.

Wir sind Leapcell, Ihre erste Wahl für das Hosting von Backend-Projekten.

Leapcell ist die Next-Gen Serverless Plattform für Web Hosting, Async Tasks und Redis:

Multi-Language Support

Entwickeln Sie mit Node.js, Python, Go oder Rust.

Stellen Sie unbegrenzt Projekte kostenlos bereit

Zahlen Sie nur für die Nutzung — keine Anfragen, keine Gebühren.

Unschlagbare Kosteneffizienz

Pay-as-you-go ohne Leerlaufgebühren.
Beispiel: 25 $ unterstützen 6,94 Millionen Anfragen bei einer durchschnittlichen Antwortzeit von 60 ms.

Optimierte Entwicklererfahrung

Intuitive Benutzeroberfläche für mühelose Einrichtung.
Vollautomatische CI/CD-Pipelines und GitOps-Integration.
Echtzeitmetriken und -protokollierung für umsetzbare Erkenntnisse.

Mühelose Skalierbarkeit und hohe Leistung

Auto-Skalierung zur einfachen Bewältigung hoher Parallelität.
Null Betriebsaufwand — konzentrieren Sie sich einfach auf das Bauen.

Erfahren Sie mehr in der Dokumentation!

Folgen Sie uns auf X: @LeapcellHQ