Ausführliche Erklärung des Redis-Shardings

Partitionierung ist der Prozess der Aufteilung Ihrer Daten in mehrere Redis-Instanzen, sodass jede Instanz nur eine Teilmenge aller Schlüssel enthält. Der erste Teil dieses Artikels führt Sie in das Konzept des Shardings ein und der zweite Teil zeigt Ihnen die Möglichkeiten des Redis-Shardings.

Was Sharding bewirken kann

Das Sharding von Redis hat zwei Hauptziele:

1. Die Nutzung ermöglichen. Viele Computer verfügen über das kombinierter Speicher zur Unterstützung größerer Datenbanken. Ohne Sharding sind Sie auf die Speichermenge beschränkt, die eine einzelne Maschine unterstützen kann.

2. Ermöglicht die Skalierung der Rechenleistung auf mehrere Kerne oder mehrere Server und die Skalierung der Netzwerkbandbreite auf mehrere Server oder mehrere Netzwerkadapter.

Sharding-Grundlagen

Es gibt viele verschiedene Sharding-Kriterien (Kriterien). Angenommen, wir haben 4 Redis-Instanzen R0, R1, R2, R3 und viele Schlüssel, die Benutzer darstellen, wie Benutzer:1, Benutzer:2 usw. Wir können verschiedene Möglichkeiten finden, einen bestimmten Schlüssel zum Speichern in welcher Instanz auszuwählen . Mit anderen Worten: Es gibt viele verschiedene Möglichkeiten, einen Schlüssel einem bestimmten Redis-Server zuzuordnen.

Eine der einfachsten Möglichkeiten, Sharding durchzuführen, ist die Bereichspartitionierung, die das Sharding vervollständigt, indem der Bereich eines Objekts einer bestimmten Redis-Instanz zugeordnet wird. Ich könnte beispielsweise annehmen, dass ein Benutzer Instanz R0 von ID 0 bis ID 10000 betritt, ein Benutzer Instanz R1 von ID 10001 bis ID 20000 betritt und so weiter.

Dieser Ansatz funktioniert und wird tatsächlich in der Praxis verwendet, hat jedoch den Nachteil, dass er eine Tabelle erfordert, die Bereiche zu Instanzen zuordnet. Diese Tabelle muss verwaltet werden, und verschiedene Arten von Objekten erfordern eine Tabelle. Daher ist Range Sharding in Redis oft nicht ratsam, da es für ihn viel weniger effizient ist als die Alternative des Shardings.

Eine Alternative zum Range Sharding ist die Hash-Partitionierung. Dieser Modus funktioniert mit jedem Schlüssel, es ist nicht erforderlich, dass der Schlüssel die Form object_name: hat, es ist so einfach:

1 Verwenden Sie zum Konvertieren eine Hash-Funktion (z. B. crc32-Hash-Funktion). der Schlüsselname zu einer Nummer. Wenn der Schlüssel beispielsweise foobar ist, gibt crc32(foobar) etwa 93024922 aus.

2. Modulieren Sie diese Daten, um sie in eine Zahl zwischen 0 und 3 umzuwandeln, damit diese Zahl einer meiner 4 Redis-Instanzen zugeordnet werden kann. 93024922 Modulo 4 ist gleich 2, daher weiß ich, dass meine Key-Foobar in der R2-Instanz gespeichert werden sollte. Hinweis: Die Modulo-Operation gibt den Rest der Divisionsoperation zurück, die in vielen Programmiersprachen immer als %-Operator implementiert ist.

Es gibt viele andere Möglichkeiten zum Sharding, wie Sie an diesen beiden Beispielen sehen können. Eine fortgeschrittene Form des Hash-Shardings wird als konsistentes Hashing bezeichnet und von einigen Redis-Kunden und -Brokern implementiert.

Verschiedene Implementierungen von Sharding

Sharding kann von verschiedenen Teilen des Software-Stacks durchgeführt werden.

1. Clientseitige Partitionierung bedeutet, dass der Client direkt den richtigen Knoten zum Schreiben und Lesen des angegebenen Schlüssels auswählt. Viele Redis-Clients implementieren clientseitiges Sharding.

2. Proxy-unterstützte Partitionierung bedeutet, dass unser Client Anfragen an einen Proxy sendet, der das Redis-Protokoll verstehen kann, anstatt Anfragen direkt an die Redis-Instanz zu senden. Der Proxy stellt sicher, dass unsere Anfragen entsprechend dem konfigurierten Sharding-Modus an die richtige Redis-Instanz weitergeleitet werden und eine Antwort an den Client zurücksendet. Twemproxy, ein Proxy für Redis und Memcached, implementiert Proxy-unterstütztes Sharding.

3. Abfrageweiterleitung bedeutet, dass Sie Ihre Anfrage an eine zufällige Instanz senden können, und diese Instanz stellt sicher, dass Ihre Anfrage an den richtigen Knoten weitergeleitet wird. Redis Cluster implementiert eine hybride Form des Abfrageroutings mit Hilfe von Clients (Anfragen werden nicht direkt von einer Redis-Instanz an eine andere weitergeleitet, sondern der Client erhält eine Weiterleitung an den richtigen Knoten).

Nachteile von Sharding

Einige Funktionen von Redis funktionieren nicht gut mit Sharding:

1. Vorgänge mit mehreren Schlüsseln werden grundsätzlich nicht unterstützt. Sie können beispielsweise keine Schnittmenge für Schlüssel durchführen, die auf zwei verschiedenen Redis-Instanzen zugeordnet sind (es gibt tatsächlich eine Möglichkeit, dies zu tun, aber nicht direkt).

2. Transaktionen mit mehreren Schlüsseln können nicht verwendet werden.

3. Die Granularität des Shardings ist der Schlüssel, daher können Sie keinen großen Schlüssel zum Sharding des Datensatzes verwenden, z. B. einen großen geordneten Satz.

4. Wenn Sharding verwendet wird, wird die Datenverarbeitung komplexer. Beispielsweise müssen Sie beim Sichern von Daten persistente Dateien von mehreren Instanzen und Hosts zusammenfassen.

5. Das Hinzufügen und Löschen von Kapazitäten ist ebenfalls kompliziert. Beispielsweise verfügt Redis Cluster über die Möglichkeit, Knoten zur Laufzeit dynamisch hinzuzufügen und zu entfernen, um eine transparente Neuverteilung von Daten zu unterstützen. Andere Methoden wie clientseitiges Sharding und Proxys unterstützen diese Funktion jedoch nicht. Es gibt jedoch eine Technologie namens Presharding, die an dieser Stelle helfen kann.

Datenspeicher oder Cache

Obwohl Redis-Sharding konzeptionell dasselbe ist, unabhängig davon, ob Sie Redis als Datenspeicher oder Cache verwenden, ist es für Daten wichtig Einschränkung bei der Lagerung. Wenn Redis als Datenspeicher verwendet wird, wird ein bestimmter Schlüssel immer derselben Redis-Instanz zugeordnet. Wenn Redis als Cache verwendet wird, ist es kein großes Problem, wenn ein Knoten nicht verfügbar ist und ein anderer Knoten verwendet wird. Das Ändern der Zuordnung von Schlüsseln und Instanzen gemäß unseren Wünschen verbessert die Verfügbarkeit des Systems (d. h. die Fähigkeit des Systems). Beantworten Sie unsere Fragen).

Konsistente Hashing-Implementierungen sind häufig in der Lage, zu anderen Knoten zu wechseln, wenn der bevorzugte Knoten für einen bestimmten Schlüssel nicht verfügbar ist. Wenn Sie einen neuen Knoten hinzufügen, werden ebenfalls einige Daten in diesem neuen Knoten gespeichert.

Die Hauptkonzepte hier sind wie folgt:

1. Wenn Redis als Cache verwendet wird, ist es einfach, konsistentes Hashing zu verwenden, um eine Skalierung nach oben und unten zu erreichen.

2. Wenn Redis als Speicher verwendet wird, wird eine feste Schlüssel-zu-Knoten-Zuordnung verwendet, sodass die Anzahl der Knoten festgelegt sein muss und nicht geändert werden kann. Andernfalls benötigen Sie beim Hinzufügen oder Löschen von Knoten ein System, das die Neuverteilung von Schlüsseln zwischen Knoten unterstützt. Derzeit kann dies nur Redis Cluster, aber Redis Cluster befindet sich noch in der Betaphase und wurde noch nicht für den Einsatz in einer Produktionsumgebung in Betracht gezogen.

Pre-Sharding

Wir wissen bereits, dass es ein Problem mit dem Sharding gibt, es sei denn, wir verwenden Redis als Cache, indem wir Knoten hinzufügen und löschen ist ein schwieriges Unterfangen, es ist viel einfacher, eine feste Schlüssel- und Instanzzuordnung zu verwenden.

Die Anforderungen an die Datenspeicherung können sich jedoch ständig ändern. Heute kann ich mit 10 Redis-Knoten (Instanzen) leben, aber morgen benötige ich möglicherweise 50 Knoten.

Da Redis einen relativ geringen Speicherbedarf hat und leichtgewichtig ist (eine inaktive Instanz verbraucht nur 1 MB Speicher), besteht eine einfache Lösung darin, viele Instanzen von vorne zu starten. Selbst wenn Sie mit nur einem Server beginnen, können Sie sich vom ersten Tag an für eine verteilte Welt entscheiden und mithilfe von Sharding mehrere Redis-Instanzen auf einem einzigen Server ausführen.

Sie können von Anfang an eine große Anzahl von Instanzen auswählen. Beispielsweise werden 32 oder 64 Instanzen die meisten Benutzer zufriedenstellen und ausreichend Raum für zukünftiges Wachstum bieten.

Wenn Ihr Datenspeicher wachsen muss und Sie mehr Redis-Server benötigen, müssen Sie auf diese Weise lediglich die Instanzen von einem Server auf einen anderen verschieben. Wenn Sie den ersten Server hinzufügen, müssen Sie die Hälfte der Redis-Instanzen vom ersten Server auf den zweiten verschieben und so weiter.

Mit der Redis-Replikation können Sie Daten mit geringer oder keiner Ausfallzeit verschieben:

1. Starten Sie eine leere Instanz auf Ihrem neuen Server.

2. Verschieben Sie Daten und konfigurieren Sie die neue Instanz als Slave-Dienst der Quellinstanz.

3. Stoppen Sie Ihren Kunden.

4. Aktualisieren Sie die Server-IP-Adresskonfiguration der verschobenen Instanz.

5. Senden Sie den Befehl SLAVEOF NO ONE an den Slave-Knoten auf dem neuen Server.

6. Starten Sie Ihren Client mit der neuen aktualisierten Konfiguration.

7. Schließen Sie abschließend die Instanzen auf dem alten Server, die nicht mehr verwendet werden.

Implementierung von Redis-Sharding

Redis-Cluster ist die bevorzugte Methode für automatisches Sharding und hohe Verfügbarkeit. Es ist noch nicht vollständig für den Produktionseinsatz verfügbar, befindet sich jedoch in der Beta-Phase.

Sobald Redis Cluster verfügbar ist und Clients verfügbar sind, die Redis Cluster unterstützen, wird Redis Cluster zum De-facto-Standard für Redis-Sharding.

Redis Cluster ist ein Hybridmodell aus Abfragerouting und Client-Sharding.

Twemproxy ist ein von Twitter entwickelter Proxy, der die Protokolle Memcached ASCII und Redis unterstützt. Es ist Single-Threaded, in C geschrieben und läuft sehr schnell. Es handelt sich um ein Open-Source-Projekt, das unter der Apache 2.0-Lizenz lizenziert ist.

Twemproxy unterstützt automatisches Sharding über mehrere Redis-Instanzen und optionale Knotenausschlussunterstützung, wenn der Knoten nicht verfügbar ist (dadurch wird die Zuordnung von Schlüsseln zu Instanzen geändert, daher sollten Sie Redis nur als Cache verwenden. Verwenden Sie nur diese Funktion) .

Dies ist kein Single Point of Failure, da Sie mehrere Proxys starten und Ihre Clients mit dem ersten verbinden können, der die Verbindung akzeptiert.

Eine Alternative zu Twemproxy besteht darin, einen Client zu verwenden, der clientseitiges Sharding durch konsistentes Hashing oder andere ähnliche Algorithmen implementiert. Es gibt mehrere Redis-Clients, die konsistentes Hashing unterstützen, beispielsweise redis-rb und Predis.

Weitere Redis-Kenntnisse finden Sie in der Spalte Redis-Datenbank-Tutorial.

Das obige ist der detaillierte Inhalt vonAusführliche Erklärung des Redis-Shardings. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!