Redis-Sharding (verteilter Cache)

Partitionierung ist der Prozess der Aufteilung Ihrer Daten in mehrere Redis-Instanzen, sodass jede Instanz nur eine Teilmenge aller Schlüssel enthält (Verwandte Empfehlungen: Redis-Tutorial)

1 Wozu dient Sharding?

Das Sharding von Redis hat zwei Hauptziele:

• Ermöglicht das Kombinieren Speicher vieler Computer zur Unterstützung größerer Datenbanken genutzt werden. Ohne Sharding sind Sie auf die Speichermenge beschränkt, die eine einzelne Maschine unterstützen kann.

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

2 Sharding-Grundlagen

Es gibt viele verschiedene Sharding-Kriterien (Kriterien).

Angenommen, wir haben 4 Redis-Instanzen R0, R1, R2, R3 und viele weitere Schlüssel, die Benutzer repräsentieren, wie Benutzer:1, Benutzer:2 usw. Wir können verschiedene Möglichkeiten finden, auszuwählen, in welcher Instanz ein bestimmter Schlüssel gespeichert wird. 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 kann zum Beispiel davon ausgehen, dass der Benutzer die Instanz R0 von der ID 0 bis zur ID 10000 betritt, und der Benutzer die Instanz R1 von der ID 10001 bis zur ID 20000 betritt.

Dieser Ansatz funktioniert und wird in der Praxis tatsächlich verwendet. Dies hat den Nachteil, dass eine Tabelle erforderlich ist, die Bereiche Instanzen zuordnet.

Diese Tabelle muss verwaltet werden, und verschiedene Arten von Objekten erfordern eine Tabelle, daher ist Bereichssharding in Redis oft nicht ratsam, da dies viel ist weniger effizient als andere Sharding-Alternativen.

Eine Alternative zum Bereichs-Sharding ist die Hash-Partitionierung

Dieser Modus funktioniert mit jedem Schlüssel und erfordert nicht, dass der Schlüssel die Form „Objektname:“ hat, es ist einfach so einfach

• Verwenden Sie eine Hash-Funktion (z. B. crc32-Hash-Funktion), um den Schlüsselnamen in eine Zahl umzuwandeln. Wenn der Schlüssel beispielsweise foobar ist, gibt crc32(foobar) etwa 93024922 aus.

• 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 entspricht 2, daher weiß ich, dass meine Schlüssel-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.

3 Sharding-Implementierung (Theorie)

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

• Clientseitige Partitionierung

Der Client wählt direkt den richtigen Knoten aus, um den angegebenen Schlüssel zu schreiben und zu lesen. Viele Redis-Clients implementieren clientseitige Partitionierung.

• Proxy-unterstützte Partitionierung

Unser Client sendet die Anfrage an einen Proxy, der das Redis-Protokoll versteht, anstatt die Anfrage direkt an die Redis-Instanz zu senden.

Der Proxy stellt sicher, dass unsere Anfragen an das richtige Redis weitergeleitet werden Instanz entsprechend dem konfigurierten Sharding-Modus und gibt eine Antwort an den Client zurück

Twemproxy, der Proxy von Redis und Memcached, implementiert Proxy-unterstütztes Splitting-Tablet.

• Abfragerouting

Sie können Ihre Anfrage an eine zufällige Instanz senden, und diese Instanz garantiert, dass Ihre Anfrage an den richtigen Knoten weitergeleitet wird.

Redis Cluster implementiert eine hybride Form der Abfrageweiterleitung mit Hilfe von Clients (Anfragen nicht). wird direkt von der Redis-Instanz an eine andere weitergeleitet, aber der Client erhält eine Weiterleitung zum richtigen Knoten). mit Sharding

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

• 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

• Wenn Sharding verwendet wird, wird die Datenverarbeitung komplexer. Sie müssen beispielsweise mehrere RDB/AOF-Dateien verarbeiten und beim Sichern von Daten müssen Sie persistente Dateien von mehreren Instanzen und Hosts aggregieren

• Das Hinzufügen und Entfernen von Kapazität ist ebenfalls komplex. 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.

Obwohl Redis-Sharding konzeptionell dasselbe ist, unabhängig davon, ob Sie Redis als Datenspeicher oder Cache verwenden, gibt es bei der Verwendung als Datenspeicher eine wichtige Einschränkung. 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:

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

• 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 der Redis-Cluster.

6 Pre-Sharding

Wir kennen bereits ein Problem mit Sharding. Sofern wir Redis nicht als Cache verwenden, ist das Hinzufügen und Entfernen von Knoten viel einfacher.

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:

• Starten Sie eine leere Instanz auf Ihrem neuen Server.

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

• Stoppen Sie Ihren Kunden.

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

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

• Starten Sie Ihren Client mit der neuen aktualisierten Konfiguration.

• Fahren Sie abschließend die Instanzen auf dem alten Server herunter, die nicht mehr verwendet werden.

7 Sharding-Implementierung (Praxis)

Bisher haben wir Redis-Sharding theoretisch besprochen, aber wie sieht es mit der Praxis aus? Welches System sollten Sie verwenden?

7.1 Redis-Cluster

Redis-Cluster ist die bevorzugte Methode für automatisches Sharding und hohe Verfügbarkeit.

Sobald Redis-Cluster verfügbar ist und Redis-Cluster unterstützt Sobald der Client verfügbar ist, wird Redis Cluster zum De-facto-Standard für Redis-Sharding.

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

7.2 Twemproxy

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. Open-Source-Projekt unter der Apache 2.0-Lizenz.

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.

Grundsätzlich ist Twemproxy eine mittlere Schicht zwischen dem Client und der Redis-Instanz, die es uns ermöglicht, unsere Shards zuverlässig und mit minimaler zusätzlicher Komplexität zu verwalten. Dies ist die derzeit empfohlene Methode zur Handhabung von Redis-Sharding.

7.3 Clients, die konsistentes Hashing unterstützen

Eine Alternative zu Twemproxy ist die Verwendung der Implementierungs-Clients mit clientseitigem Sharding , durch konsistentes Hashing oder andere ähnliche Algorithmen. Es gibt mehrere Redis-Clients, die konsistentes Hashing unterstützen, beispielsweise redis-rb und Predis.

Bitte überprüfen Sie die vollständige Liste der Redis-Clients, um zu sehen, ob es einen ausgereiften Client gibt, der Ihre Programmiersprache unterstützt und konsistentes Hashing implementiert.

Das obige ist der detaillierte Inhalt vonRedis-Sharding (verteilter Cache). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!