So stellen Sie einen Redis 6.x-Cluster über Docker bereit

Systemumgebung:

• Redis-Version: 6.0.8
• Docker-Version: 19.03.12
• Systemversion: CoreOS 7.8
• Kernelversion: 5.8.5-1.el7.elrepo.x86_64

1. Was ist der Redis-Clustermodus?

Der Redis-Clustermodus wurde offiziell nach der Redis-Version 3.0 eingeführt. Dieser Modus ist eine verteilte Lösung für Redis. Es handelt sich um eine Reihe von Programmen, die den Datenaustausch zwischen mehreren Redis-Knoten ermöglichen. Der Redis-Cluster ist dezentralisiert. Jeder seiner Master-Knoten kann Daten lesen und schreiben. Jeder Knoten hat eine gleichberechtigte Beziehung und jeder Knoten verwaltet seine eigenen Daten und den Status des gesamten Clusters.

Der Hauptzweck des Redis-Clusterdesigns besteht darin, eine lineare Skalierung des Redis-Datenspeichers zu ermöglichen und durch Partitionierung ein gewisses Maß an Verfügbarkeit bereitzustellen. In der tatsächlichen Umgebung kann es weiterhin Befehle verarbeiten, wenn ein Knoten ausfällt oder nicht erreichbar ist. Wenn jedoch ein schwerwiegender Fehler auftritt (z. B. wenn die meisten Masterstationen nicht verfügbar sind), wird der Cluster beendet. Dies bedeutet, dass der Redis-Cluster keine starke Datenkonsistenz garantieren kann.

2. Warum brauchen wir einen Redis-Cluster?

• Hohe Verfügbarkeit: Im Redis-Clustermodus befindet sich jeder Master im Master-Slave-Replikationsmodus. Die Daten auf dem Masterknoten werden in Echtzeit mit dem Slaveknoten synchronisiert. Wenn der Masterknoten nicht verfügbar ist, wird die entsprechende Slaveknotenidentität in den Masterknoten geändert, um die Verfügbarkeit des Clusters sicherzustellen.
• Horizontale Datenausweitung: Redis ist eine In-Memory-Datenbank. Alle Daten werden im Speicher abgelegt. Der Speicher, den der Server in einem einzelnen Knoten bereitstellen kann, ist begrenzt. Wenn die Datenmenge ein bestimmtes Niveau erreicht, reicht der Speicher nicht mehr aus, um die Speicherung dieser Datenmenge zu unterstützen. Zu diesem Zeitpunkt müssen die Daten in Shards gespeichert werden. Der Redis-Clustermodus speichert Daten in Shards, was für die horizontale Erweiterung sehr praktisch ist.

3. Daten-Sharding des Redis-Clusters

Der Redis-Cluster verwendet kein konsistentes Hashing, führt jedoch das Konzept des „Hash-Slots“ ein. Der Redis-Cluster verfügt über 16384 Hash-Slots. Jeder Schlüssel wird mit CRC16 und dann mit Modulo 16384 geprüft, um zu bestimmen, in welchen Slot er eingefügt werden soll. Jeder Knoten im Cluster ist für einen Teil der Hash-Slots verantwortlich.

Wenn der aktuelle Cluster beispielsweise über 3 Knoten verfügt, gilt Folgendes:

• Knoten A enthält die Hash-Slots 0 bis 5460;
• Knoten B enthält die Hash-Slots 5461 bis 10922;
• Knoten C enthält die Hash-Slots 10923 bis 16383;

Diese Struktur erleichtert das „Hinzufügen“ oder „Löschen“ von Knoten. Wenn ich beispielsweise einen neuen Knoten D hinzufügen möchte, muss ich einige Slots von den Knoten A, B und C auf Knoten D übertragen. Wenn ich Knoten A entfernen möchte, muss ich die Slots in A auf die Knoten B und C verschieben und dann den Knoten A ohne Slots aus dem Cluster entfernen. Da das Verschieben eines Hash-Slots von einem Knoten zu einem anderen den Dienst nicht stoppt, führt das Hinzufügen, Löschen oder Ändern der Anzahl von Hash-Slots auf einem Knoten nicht dazu, dass der Cluster nicht mehr verfügbar ist.

Redis unterstützt mehrere Schlüsseloperationen. Solange diese Schlüssel in einem einzelnen Befehl (oder einer Transaktion oder der Ausführung eines Lua-Skripts) ausgeführt werden, gehören sie zum selben Hash-Slot. Sie können auch den Hashtag-Befehl verwenden, um zu erzwingen, dass sich mehrere Schlüssel im selben Hash-Slot befinden.

4. Master-Slave-Replikation des Redis-Clusters

Master-Slave-Modell in einem Cluster

Um im Redis-Clustermodus zu verhindern, dass einige Knoten im Cluster aufgrund von Ausfallzeiten nicht verfügbar sind, verwendet der Redis-Cluster den Master-Slave-Replikationsmodus. In diesem Modus muss der Redis-Cluster mindestens sechs Knoten haben, von denen drei Masterknoten sind, die externes Lesen und Schreiben ermöglichen können. Es gibt außerdem drei Knoten, die Slave-Knoten sind, die die Daten ihrer entsprechenden Master-Knoten synchronisieren. Wenn bei einem Masterknoten ein Problem auftritt und er nicht mehr verfügbar ist, wählt Redis über einen Auswahlalgorithmus einen Knoten aus den Slaveknoten aus, die dem Masterknoten entsprechen (wenn es mehrere Slaveknoten für den Masterknoten gibt), ändert ihn in einen neuen Masterknoten und ermöglicht ihm, Dienste für die Außenwelt bereitzustellen.

Beispielsweise gibt es drei Masterknoten A, B und C und ihre entsprechenden sechs Slaveknoten (A1, A2), (B1, B2) und (C1, C2), also insgesamt neun Knoten. Wenn Knoten A ausfällt, verwenden seine entsprechenden Slaveknoten A1 und A2 den Auswahlalgorithmus, um einen der Knoten auszuwählen, der zum Masterknoten befördert werden soll, um sicherzustellen, dass der Cluster normale Dienste bereitstellen kann. Wenn jedoch die beiden Slave-Knoten A1 und A2 oder mehr als die Hälfte der Master-Knoten nicht verfügbar sind, ist auch der Cluster nicht verfügbar.

Beim Bereitstellen des Redis-Clustermodus sind mindestens sechs Knoten erforderlich, um einen Cluster zu bilden und die Verfügbarkeit des Clusters sicherzustellen.

Verwandte Konzepte der Master-Slave-Replikation

(1) Vollständige Replikation und inkrementelle Replikation

Bei der Redis-Master-Slave-Replikation gibt es zwei Methoden zur Datensynchronisierung: „Vollständige Replikation“ und „inkrementelle Replikation“:

• Vollständige Replikation: Wird für die anfängliche Replikation oder andere Situationen verwendet, in denen eine teilweise Replikation nicht möglich ist. Alle Daten im Masterknoten werden an den Slaveknoten gesendet. Wenn die Datenmenge zu groß ist, entsteht ein hoher Netzwerk-Overhead.
• Inkrementelle Replikation: Wird verwendet, um Datenverlustszenarien zu bewältigen, die durch Netzwerkabstürze und andere Gründe bei der Master-Slave-Replikation verursacht werden. Wenn der Slave-Knoten erneut eine Verbindung zum Master-Knoten herstellt, sendet der Master-Knoten die verlorenen Daten erneut an den Slave-Knoten, sofern die Bedingungen dies zulassen. Da die erneut gesendeten Daten viel kleiner sind als die vollständigen Daten, kann der übermäßige Aufwand einer vollständigen Replikation effektiv vermieden werden. Beachten Sie jedoch, dass, wenn die Netzwerkunterbrechung zu lange dauert und der Masterknoten die während der Unterbrechung ausgeführten Schreibbefehle nicht vollständig speichern kann, keine teilweise Replikation durchgeführt werden kann und weiterhin eine vollständige Replikation verwendet wird.

(2) Notieren Sie den Versatz der Kopierposition

• Die an der Replikation beteiligten Master- und Slave-Knoten behalten ihre eigenen Replikations-Offsets bei. Nach der Verarbeitung des Schreibbefehlsvorgangs zeichnet der Master-Knoten die Bytelänge des Befehls kumulativ auf. Sie können den Befehl info replication verwenden, um master_repl_offset abzufragen.
• Der Slave-Knoten meldet seinen eigenen Replikations-Offset jede Sekunde an den Master-Knoten, sodass der Master-Knoten auch den Replikations-Offset des Slave-Knotens speichert.
• Nach dem Empfang des vom Masterknoten gesendeten Befehls sammelt und zeichnet der Slaveknoten auch seinen eigenen Offset auf. Sie können den Befehl info replication verwenden, um slave_repl_offset abzufragen.

(3) Kopieren Sie den Backlog-Puffer

Der Replikations-Backlog-Puffer ist eine Warteschlange mit fester Länge, die auf dem Masterknoten gespeichert ist. Die Standardgröße beträgt 1 MB. Er wird erstellt, wenn der Masterknoten über einen verbundenen Slaveknoten verfügt. Wenn der Masterknoten auf einen Schreibbefehl antwortet, sendet er den Befehl nicht nur an den Slaveknoten, sondern schreibt ihn auch als Backup des Schreibbefehls in den Replikations-Backlog-Puffer.

Zusätzlich zur Speicherung von Schreibbefehlen speichert der Replikations-Backlog-Puffer auch den Replikations-Offset, der jedem darin enthaltenen Byte entspricht. Da der Replikations-Backlog-Puffer eine feste Länge und das First-In-First-Out-Prinzip hat, speichert er die zuletzt vom primären Knoten ausgeführten Schreibbefehle und ältere Schreibbefehle werden aus dem Puffer verdrängt.

(4) Knoten-Lauf-ID

• Nach dem Start jedes Redis-Knotens wird dynamisch eine 40-Bit-Hexadezimalzeichenfolge als laufende ID zugewiesen. Die Hauptfunktion der laufenden ID besteht darin, den Redis-Knoten eindeutig zu identifizieren. Beispielsweise speichert der Slave-Knoten die laufende ID des Master-Knotens, um zu identifizieren, welchen Master-Knoten er repliziert. Wenn nur IP + Port zur Identifizierung des Masterknotens verwendet werden, wird der Masterknoten neu gestartet und ändert den gesamten Datensatz (z. B. durch Ersetzen von RDB/AOF-Dateien). Für den Slaveknoten ist es unsicher, Daten basierend auf dem Offset zu kopieren. Wenn sich die laufende ID ändert, führt der Slaveknoten daher eine vollständige Kopie durch. Sie können die laufende ID des aktuellen Knotens mit dem Befehl „Infoserver“ anzeigen.
• Es ist zu beachten, dass sich die Lauf-ID entsprechend ändert, wenn Redis heruntergefahren und neu gestartet wird.

Ausführungsprozess der Master-Slave-Replikation

(1) psync-Befehl

Der Slave-Knoten verwendet psync, um die RunID und den Offset vom Master-Knoten zu erhalten.

Der Masterknoten gibt eine Antwortnachricht basierend auf seiner eigenen Situation zurück. Es kann sich um FULLRESYNC-Runid-Offset handeln, um eine vollständige Replikation auszulösen, oder um CONTINUE, um eine inkrementelle Replikation auszulösen.

(2) psync löst eine vollständige Replikation aus

Der Slave-Knoten verwendet den Befehl psync, um die Funktionen zur teilweisen und vollständigen Replikation abzuschließen:

Wenn der Slave-Knoten zum ersten Mal eine Verbindung zum Master-Knoten herstellt, wird eine vollständige Kopie durchgeführt:

① Der Slave-Knoten sendet den Befehl psync? - 1, um anzuzeigen, dass der Master eine Datensynchronisierung durchführen muss.

② Der Master erkennt, dass kein Offset vorhanden ist und führt zum ersten Mal eine Replikation durch. Er führt eine vollständige Replikation durch und sendet den Befehl FULLRESYNC {runid} {offset}, um die RunID und den Offset an den Slave-Knoten zu senden.

③ Der Slave-Knoten speichert die vom Master-Knoten übertragenen RunID- und Offset-Informationen.

④ Der Masterknoten führt bgsave aus, um eine RBD-Snapshot-Datei zu generieren, und verwendet einen Puffer, um alle von nun an ausgeführten Befehle aufzuzeichnen.

⑤ Der Master-Knoten sendet die RBD-Datei an den Slave-Knoten.

⑥ Der Masterknoten sendet den im Pufferbereich BUFFER aufgezeichneten Schreibbefehl an den Slaveknoten.

⑦ Der Slave-Knoten löscht die alten Daten.

⑧ Der Slave-Knoten lädt die vom Master-Knoten übergebene RBD-Datei.

(2) psync löst eine inkrementelle Replikation aus

Wenn der Slave-Knoten vom Master-Knoten getrennt wird, stellt der Slave-Knoten die Verbindung zum Master-Knoten wieder her, wodurch eine inkrementelle Replikation ausgelöst wird. Der Vorgang läuft wie folgt ab:

① Der Slave-Knoten verwendet psync, um RunID- und Offset-Werte zu senden.

② Der Masterknoten überprüft, ob die vom Slaveknoten gesendete RunID mit seiner eigenen übereinstimmt:

• Nicht gleich: Wenn sie nicht gleich sind, führen Sie eine vollständige Kopie durch.
• Dasselbe: Sie müssen auch überprüfen, ob der entsprechende Offset im Cache vorhanden ist. Wenn nicht, führen Sie eine vollständige Kopie durch, andernfalls eine inkrementelle Kopie.

③ Nachdem die entsprechende Offset-Bedingung erfüllt ist, überprüfen Sie, ob der Offset-Wert im Puffer mit dem vom Slave-Knoten gesendeten Offset übereinstimmt:

• Gleich: Der zurückgegebene Offsetwert ist derselbe und es wird kein Kopiervorgang ausgeführt.
• Anders: Senden Sie den Befehl CONTINUE Offset (Hinweis: Der Offset ist hier der im Cache des Masterknotens aufgezeichnete Offsetwert, nicht der vom Slave-Knoten übergebene Offsetwert).

④ Der Masterknoten kopiert Daten aus dem Replikationspuffer, beginnend mit dem vom Slaveknoten gesendeten Offset und endend mit dem im Masterknotenpuffer aufgezeichneten Offset, und gibt die Daten in diesem Bereich an den Slaveknoten weiter.

5. Redis Cluster-bezogene Konzepte

Konsistenz im Redis-Cluster

Redis erwähnt in der offiziellen Dokumentation, dass es keine starke Datenkonsistenz garantieren kann, d. h. die in den Redis-Cluster geschriebenen Daten können unter bestimmten Bedingungen verloren gehen. Der Hauptgrund ist, dass der Redis-Cluster den asynchronen Replikationsmodus verwendet. Der Schreibvorgang ist wie folgt:

Die Ausführungsreihenfolge ist wie folgt:

① Der Client schreibt einen Befehl an einen beliebigen Masterknoten.

② Der Masterknoten antwortet dem Client mit dem Status der Befehlsausführung.

③ Der Masterknoten übergibt den Schreibvorgangsbefehl an seinen Slaveknoten.

Der Redis-Cluster schafft ein Gleichgewicht zwischen Leistung und Konsistenz. Der Masterknoten ist so eingestellt, dass er den ausgeführten Befehl nach Erhalt des Client-Schreibbefehls zur Synchronisierung an jeden Slaveknoten sendet. Dieser Vorgang ist ein asynchroner Vorgang, und der Masterknoten wartet nicht auf die Antwort des Slaveknotens, sondern antwortet sofort auf den Ausführungsstatus des Client-Befehls. Durch die Reduzierung der Synchronisierungsvorgänge kann die Ausführungsgeschwindigkeit des Systems erheblich verbessert werden. Außerdem wird vermieden, dass das Warten auf die Antwort der Slave-Knoten auf Nachrichten zu einem Engpass bei der Systemleistung wird.

Da der Masterknoten dem Client jedoch mit dem Befehlsausführungsstatus antwortet, ohne auf die Antwort des Slaveknotens nach Erhalt der Informationen zu warten, kommt es wahrscheinlich zu Datenverlusten, wenn im Knoten ein Problem auftritt. Beispielsweise sendet der Client einen Befehl an den Masterknoten, und dann sendet der Masterknoten den Befehl asynchron an seinen Slaveknoten zur Datensicherung und antwortet dem Client dann sofort mit dem Befehlsausführungsstatus. Wenn während dieses Vorgangs beim Masterknoten ein Problem auftritt und er abstürzt, tritt beim Slaveknoten ebenfalls ein Fehler bei der Verarbeitung der vom Masterknoten gesendeten Synchronisierungsdaten auf. Wenn der Masterknoten zu diesem Zeitpunkt ausfällt oder nicht verfügbar ist, wird der Slave-Knoten in den neuen Masterknoten umgewandelt und die auf dem vorherigen Masterknoten ausgeführten Befehle gehen verloren.

Redis-Kommunikationsmechanismus zwischen Clustern

Im Redis-Cluster stellt der Datenknoten zwei TCP-Ports bereit. Beim Konfigurieren der Firewall müssen Sie die folgenden beiden Porttypen gleichzeitig öffnen:

• Gemeinsamer Port: der Client-Zugriffsport, beispielsweise der Standardport 6379;
• Cluster-Port: normale Portnummer plus 10000, z. B. 6379. Der Cluster-Port ist 16379 und wird für die Kommunikation zwischen Cluster-Knoten verwendet.

Das Gossip-Protokoll wird für die Kommunikation zwischen Knoten im Cluster verwendet. Knoten treffen Entscheidungen auf der Grundlage geplanter Aufgaben in einer festen Frequenz (10 Mal pro Sekunde). Wenn sich der Clusterstatus ändert, z. B. durch Hinzufügen oder Löschen von Knoten oder Ändern des Slot-Status, wird der Clusterstatus durch Kommunikation zwischen Knoten synchronisiert, um die Konvergenz des Clusters zu erreichen. Es gibt fünf Arten von Gossip-Nachrichten, die zwischen Clustern gesendet werden:

• MEET: Während der Knoten-Handshake-Phase wird eine Meet-Nachricht an den neu beigetretenen Knoten gesendet, mit der Aufforderung, dem aktuellen Cluster beizutreten. Der neue Knoten antwortet nach Erhalt der Nachricht mit einer Pong-Nachricht.
• PING: Knoten senden einander Ping-Nachrichten und diejenigen, die die Nachrichten empfangen, antworten mit Pong-Nachrichten. Der Inhalt der Ping-Nachricht enthält die Statusinformationen dieses Knotens und anderer Knoten, um eine Statussynchronisierung zu erreichen.
• PONG: Die Pong-Nachricht enthält ihre eigenen Statusdaten. Beim Empfang einer Ping- oder Meet-Nachricht antwortet sie mit einer Pong-Nachricht und sendet außerdem aktiv eine Pong-Nachricht an den Cluster.
• FAIL: Wenn ein Masterknoten feststellt, dass ein anderer Masterknoten in den Fehlerzustand geraten ist, sendet er diese Nachricht an den Cluster. Die empfangenden Knoten speichern die Nachricht und treffen eine Statusbestimmung für den ausgefallenen Knoten.
• PUBLISH: Wenn ein Knoten einen Veröffentlichungsbefehl empfängt, führt er zuerst den Befehl aus und sendet dann die Veröffentlichungsnachricht an den Cluster. Die Knoten, die die Nachricht empfangen, führen auch den Veröffentlichungsbefehl aus.

Redis-Cluster-Fehlerstatus

Es ist auch unmöglich, im Redis-Clustermodus eine 100%ige Clusterverfügbarkeit zu garantieren. Wenn ein unvorhersehbares Ereignis eintritt, wechselt der Redis-Cluster in einen Fehlerzustand. In diesem Fall kann der Redis-Cluster keine normalen Dienste bereitstellen. Die Bedingungen für den Eintritt des Fehlerzustands sind im Wesentlichen:

① Wenn alle Knoten ausgefallen sind, wechselt der Cluster in den Fehlerzustand.

② Wenn mehr als die Hälfte der Masterknoten nicht verfügbar sind, wechselt der Cluster in den Fehlerzustand.

③ Wenn ein beliebiger Masterknoten ausfällt und der Masterknoten keinen entsprechenden Slaveknoten hat oder alle Slaveknoten ausfallen, wechselt der Cluster in den Fehlerzustand.

Redis-Cluster-Resharding-Mechanismus

Mechanismus zum Resharding (Hinzufügen/Entfernen von Knoten) des Redis-Clusters:

Neuen Knoten hinzufügen: Einige Slots von anderen Knoten dem neuen Knoten zuweisen

Knoten löschen: Löscht den Slot des Knotens und weist ihn einem anderen Knoten zu

Diese Vorgänge müssen jedoch manuell ausgeführt werden und können durchgeführt werden, ohne den Server anzuhalten.

Nachteile von Redis Cluster

Die Replikationsstruktur unterstützt nur einschichtige Strukturen, keine Baumstrukturen.

Es werden keine mehreren Datenbanken unterstützt. Sie können nur Datenbank 0 verwenden und den Befehl „select 0“ ausführen.

Der Schlüssel ist die Mindestgranularität der Datenpartitionierung. Ein großes Schlüssel-Wert-Paar kann nicht verschiedenen Knoten zugeordnet werden.

Die Unterstützung für Schlüsseltransaktionen ist eingeschränkt. Wenn mehrere Schlüssel auf verschiedene Knoten verteilt sind, können keine Transaktionen verwendet werden. Transaktionen können nur auf demselben Knoten unterstützt werden.

Batch-Schlüsseloperationen werden nur eingeschränkt unterstützt, z. B. die Befehle mset und mget. Wenn mehrere Schlüssel in verschiedenen Steckplätzen zugeordnet sind, können diese Befehle nicht normal verwendet werden.

Redis-Cluster-Konfigurationsparameter

Wir sind dabei, eine Beispielclusterbereitstellung zu erstellen. Bevor wir fortfahren, behandeln wir die Konfigurationsparameter, die Redis Cluster in der Datei redis.conf einführt.

cluster-config-file: Legt den Speicherort der Konfigurationsinformationen und des Status des Redis-Clusters fest. Diese Datei wird vom Redis-Cluster generiert und wir können nur ihren Speicherort angeben.

cluster-node-timeout: Legen Sie das Kommunikations-Timeout der Redis-Clusterknoten fest.

cluster-migration-barrier: Die Mindestanzahl an Slave-Knoten, die der Master-Knoten benötigt. Erst wenn diese Zahl erreicht ist, werden die Slave-Knoten migriert, wenn der Master-Knoten ausfällt.

cluster-enabled: Gibt an, ob der Redis-Clustermodus aktiviert werden soll.

ja: Redis-Cluster aktivieren;

nein: Clustermodus nicht aktivieren;

cluster-require-full-coverage: Legt die Clusterverfügbarkeit fest.

ja: Gibt an, dass der Cluster nicht verfügbar ist, wenn die für einen Steckplatz verantwortliche Master-Bibliothek offline geht und keine entsprechende Slave-Bibliothek zur Fehlerbehebung vorhanden ist. Diese Situation wird unten dargestellt.

no: Gibt an, dass der Cluster weiterhin verfügbar ist, wenn die für einen Steckplatz verantwortliche Master-Bibliothek offline geht und keine entsprechende Slave-Bibliothek zur Fehlerbehebung vorhanden ist. Diese Situation wird unten dargestellt.

Cluster-Slave-Gültigkeitsfaktor:

0: Unabhängig davon, wie lange der Slave-Knoten die Verbindung zum Master-Knoten verliert, versucht der Slave-Knoten, ein Upgrade auf den Master-Knoten durchzuführen.

Positive Zahl: Die durch cluster-node-timeout * cluster-slave-validity-factor ermittelte Zeit ist die maximale Zeit, die die Slave-Knotendaten gültig sind, nachdem der Slave-Knoten die Verbindung zum Master-Knoten verloren hat. Wenn diese Zeit überschritten wird, startet der Slave-Knoten kein Failover. Unter der Annahme von cluster-node-timeout=5 , cluster-slave-validity-factor=10 kann der Slave-Knoten nicht zum Master-Knoten werden, wenn er länger als 50 Sekunden die Verbindung zum Master-Knoten verliert.

6. Redis-Cluster mit Docker bereitstellen

1. Redis-Bereitstellungsmaschinenzuordnung

Hier teilen wir die Knoten des zu deployenden Redis-Clusters auf und verteilen sie auf unterschiedliche Rechner. Die Anordnung sieht wie folgt aus:

2. Erstellen Sie ein Datenspeicherverzeichnis

Erstellen Sie vorab ein Verzeichnis zum Speichern von Redis-Konfigurationsdateien und persistenten Daten:

Führen Sie den Befehl aus, um ein Speicherverzeichnis auf dem ersten Server 192.168.2.11 zu erstellen:

$ mkdir -p /var/lib/redis/7000 & mkdir -p /var/lib/redis/7003

Führen Sie den Befehl aus, um ein Speicherverzeichnis auf dem zweiten Server 192.168.2.12 zu erstellen:

$ mkdir -p /var/lib/redis/7001 & mkdir -p /var/lib/redis/7004

Führen Sie den Befehl aus, um ein Speicherverzeichnis auf dem dritten Server 192.168.2.13 zu erstellen:

$ mkdir -p /var/lib/redis/7002 & mkdir -p /var/lib/redis/7005

3. Erstellen Sie eine Redis-Konfigurationsdatei

Erste Konfigurationsdatei des Servers 192.168.2.11 :

## 7000-Port-Konfigurationsdatei $ cat > /var/lib/redis/7000/redis.conf << EOF
Hafen 7000
Clusterfähig ja
Cluster-Konfigurationsdatei nodes.conf
Cluster-Knoten-Timeout 5000
nur anhängen ja
dämonisieren nein
geschützter Modus nein
PID-Datei /data/redis.pid
Ende der Laufzeit
 
## 7003 Port-Konfigurationsdatei $ cat > /var/lib/redis/7003/redis.conf << EOF
Port 7003
Clusterfähig ja
Cluster-Konfigurationsdatei nodes.conf
Cluster-Knoten-Timeout 5000
nur anhängen ja
dämonisieren nein
geschützter Modus nein
PID-Datei /data/redis.pid
Ende der Laufzeit

Zweite Serverkonfigurationsdatei 192.168.2.12

## 7001 Portkonfiguration: redis.conf
$ cat > /var/lib/redis/7001/redis.conf << EOF
Port 7001
Clusterfähig ja
Cluster-Konfigurationsdatei nodes.conf
Cluster-Knoten-Timeout 5000
nur anhängen ja
dämonisieren nein
geschützter Modus nein
PID-Datei /data/redis.pid
Ende der Laufzeit
 
## 7004-Portkonfiguration: redis-7004.conf
$ cat > /var/lib/redis/7004/redis.conf << EOF
Port 7004
Clusterfähig ja
Cluster-Konfigurationsdatei nodes.conf
Cluster-Knoten-Timeout 5000
nur anhängen ja
dämonisieren nein
geschützter Modus nein
PID-Datei /data/redis.pid
Ende der Laufzeit

Die dritte Serverkonfigurationsdatei 192.168.2.13

## 7002-Portkonfiguration: redis-7002.conf
$ cat > /var/lib/redis/7002/redis.conf << EOF
Port 7002
Clusterfähig ja
Cluster-Konfigurationsdatei nodes.conf
Cluster-Knoten-Timeout 5000
nur anhängen ja
dämonisieren nein
geschützter Modus nein
PID-Datei /data/redis.pid
Ende der Laufzeit
 
## 7005-Portkonfiguration: redis-7005.conf
$ cat > /var/lib/redis/7005/redis.conf << EOF
Port 7005
Clusterfähig ja
Cluster-Konfigurationsdatei nodes.conf
Cluster-Knoten-Timeout 5000
nur anhängen ja
dämonisieren nein
geschützter Modus nein
PID-Datei /data/redis.pid
Ende der Laufzeit

4. Ziehen Sie das Redis-Image im Voraus

Rufen Sie das Redis-Image im Voraus von den drei Servern ab, um zu vermeiden, dass Sie das Image während der Ausführung abrufen müssen, was den Betrieb verlangsamen würde.

$ docker pull redis:6.0.8

5. Ausführen und Starten des Redis-Image

Die drei Server führen den Docker-Befehl „run“ aus, um das Redis-Image zu starten. Hierbei ist zu beachten, dass Docker auf verschiedenen Servern nicht miteinander kommunizieren können. Daher setzen wir hier den Netzwerkmodus des gestarteten Containers auf den Host-Modus, damit der Container keine virtuelle Netzwerkkarte erstellt, sondern das Netzwerk des Hosts verwendet.

• -d: Stellt den Container so ein, dass er im Hintergrund läuft;
• -v: gibt das gemountete Host-Speicherverzeichnis an;
• --name: gibt den Namen des Containers nach dem Ausführen an;
• --cpus: gibt die Anzahl der vom Container verwendeten CPUs an;
• --memory: Begrenzen Sie die vom Container verwendete Speichermenge.
• --memory-swap: gibt die Größe des Swap-Speichers an, die hier auf 0 gesetzt ist, was bedeutet, dass kein Swap-Speicher verwendet wird;
• --net: gibt den von Docker verwendeten Netzwerkmodus an;
• --restart: Gibt die Neustartstrategie des Containers an, wenn Docker neu gestartet wird.
• --privileged: Richten Sie den Container so ein, dass er über Privilegien verfügt und die Root-Berechtigungen des Hostcomputers abrufen kann.

Der erste Server 192.168.2.11 führt den folgenden Befehl aus

## Redis-Image auf Port 7000 ausführen
 $ docker run -d -v /var/lib/redis/7000:/data \
--cpus=1 --memory=2GB --memory-swap=0 \
--privilegiert=true \
--restart=immer \
--net Host \
--name redis-7000 \
redis:6.0.8 redis-server /data/redis.conf
 
## Redis-Image auf Port 7003 ausführen
 $ docker run -d -v /var/lib/redis/7003:/data \
--cpus=1 --memory=2GB --memory-swap=0 \
--privilegiert=true \
--restart=immer \
--net Host \
--name redis-7003 \
redis:6.0.8 redis-server /data/redis.conf

Der zweite Server 192.168.2.12 führt den folgenden Befehl aus

## Redis-Image auf Port 7001 ausführen
 $ docker run -d -v /var/lib/redis/7001:/data \
--cpus=1 --memory=2GB --memory-swap=0 \
--privilegiert=true \
--restart=immer \
--net Host \
--name redis-7001 \
redis:6.0.8 redis-server /data/redis.conf
 
## Redis-Image auf Port 7004 ausführen
 $ docker run -d -v /var/lib/redis/7004:/data \
--cpus=1 --memory=2GB --memory-swap=0 \
--privilegiert=true \
--restart=immer \
--net Host \
--name redis-7004 \
redis:6.0.8 redis-server /data/redis.conf

Der dritte Server 192.168.2.13 führt den folgenden Befehl aus:

## Redis-Image auf Port 7002 ausführen
 $ docker run -d -v /var/lib/redis/7002:/data \
--cpus=1 --memory=2GB --memory-swap=0 \
--privilegiert=true \
--restart=immer \
--net Host \
--name redis-7002 \
redis:6.0.8 redis-server /data/redis.conf
 
## Redis-Image auf Port 7005 ausführen
 $ docker run -d -v /var/lib/redis/7005:/data \
--cpus=1 --memory=2GB --memory-swap=0 \
--privilegiert=true \
--restart=immer \
--net Host \
--name redis-7005 \
redis:6.0.8 redis-server /data/redis.conf

6. Erstellen Sie einen Redis-Cluster

Geben Sie einen beliebigen Server ein, verwenden Sie das Redis-CLI-Tool des Redis-Images, um den Befehl „Cluster erstellen“ auszuführen, damit aus jedem Redis ein Cluster gebildet wird. Hier gebe ich den ersten Server 192.168.2.11 ein, verwende das Redis -End-Image mit Port 7000 und führe den folgenden Befehl aus:

-p: gibt den Port für die Verbindung mit Redis an;

erstellen: Erstellen Sie einen Redis-Cluster;

--cluster: Verwenden Sie Befehle im Redis-Clustermodus.

--cluster-replicas: gibt die Anzahl der Replikate an (Slave-Nummer);

$ docker exec -it redis-7000 \
redis-cli -p 7000 --cluster erstellen \
192.168.2.11:7000 192.168.2.12:7001 192.168.2.13:7002 \
192.168.2.11:7003 192.168.2.12:7004 192.168.2.13:7005 \
--cluster-replicas 1

Anschließend werden Ihnen folgende Informationen angezeigt:

>>> Hash-Slot-Zuweisung auf 6 Knoten wird durchgeführt …
Master[0] -> Steckplätze 0 - 5460
Master[1] -> Steckplätze 5461 - 10922
Master[2] -> Plätze 10923 - 16383
Replikat 192.168.2.12:7004 zu 192.168.2.11:7000 hinzufügen
Replikat 192.168.2.13:7005 zu 192.168.2.12:7001 hinzufügen
Replikat 192.168.2.11:7003 zu 192.168.2.13:7002 hinzufügen
M: 5e50824c55d4df42db4d2987796f0c0b468c273f 192.168.2.11:7000
   Steckplätze:[0-5460] (5461 Steckplätze) Master
M: 36565e0273fd62921aa1f2d85c5f7ac98a5b9466 192.168.2.12:7001
   Steckplätze:[5461-10922] (5462 Steckplätze) Master
M: 0cc1aaf960defae7332e9256dd25ee5e5c99e65f 192.168.2.13:7002
   Steckplätze:[10923-16383] (5461 Steckplätze) Master
S: 42d6e3979395ba93cd1352b6d17044f6b25d9379 192.168.2.11:7003
   Replikate 0cc1aaf960defae7332e9256dd25ee5e5c99e65f
S: ac5d34b57a8f73dabc60d3a56469055ec64fcde7 192.168.2.12:7004
   Replikate 5e50824c55d4df42db4d2987796f0c0b468c273f
S: 470b7ff823f10a309fb07311097456210506f6d8 192.168.2.13:7005
   Replikate 36565e0273fd62921aa1f2d85c5f7ac98a5b9466
Kann ich die obige Konfiguration festlegen? (Geben Sie „Ja“ ein, um zu akzeptieren): ja
>>> Knotenkonfiguration aktualisiert
>>> Jedem Knoten eine andere Konfigurationsepoche zuweisen
>>> Senden von CLUSTER MEET-Nachrichten zum Beitritt zum Cluster
Warten auf den Beitritt zum Cluster
.
>>> Clusterprüfung durchführen (mit Knoten 192.168.2.11:7000)
M: 5e50824c55d4df42db4d2987796f0c0b468c273f 192.168.2.11:7000
   Steckplätze:[0-5460] (5461 Steckplätze) Master
   1 zusätzliche Replik(en)
S: 470b7ff823f10a309fb07311097456210506f6d8 192.168.2.13:7005
   Steckplätze: (0 Steckplätze) Slave
   Replikate 36565e0273fd62921aa1f2d85c5f7ac98a5b9466
S: 42d6e3979395ba93cd1352b6d17044f6b25d9379 192.168.2.11:7003
   Steckplätze: (0 Steckplätze) Slave
   Replikate 0cc1aaf960defae7332e9256dd25ee5e5c99e65f
S: ac5d34b57a8f73dabc60d3a56469055ec64fcde7 192.168.2.12:7004
   Steckplätze: (0 Steckplätze) Slave
   Replikate 5e50824c55d4df42db4d2987796f0c0b468c273f
M: 0cc1aaf960defae7332e9256dd25ee5e5c99e65f 192.168.2.13:7002
   Steckplätze:[10923-16383] (5461 Steckplätze) Master
   1 zusätzliche Replik(en)
M: 36565e0273fd62921aa1f2d85c5f7ac98a5b9466 192.168.2.12:7001
   Steckplätze:[5461-10922] (5462 Steckplätze) Master
   1 zusätzliche Replik(en)
[OK] Alle Knoten stimmen der Slot-Konfiguration zu.
>>> Nach freien Plätzen suchen...
>>> Slot-Abdeckung prüfen...
[OK] Alle 16384 Slots abgedeckt.

7. Clusterinformationen anzeigen

Geben Sie das Redis-Image ein und führen Sie den Befehl „redis-cli“ aus:

-p: gibt den Endpunkt für die Verbindung mit Redis an;

-c: Clustermodus verwenden;

$ docker exec -it redis-7000 redis-cli -p 7000 -c

Clusterinformationen anzeigen:

> Cluster-Info
 
cluster_state: ok
Zugewiesene Clusterslots: 16384
cluster_slots_ok:16384
cluster_slots_pfail:0
Fehler bei Clusterslots: 0
Bekannte Clusterknoten: 6
Clustergröße: 3
cluster_current_epoch:6
cluster_meine_Epoche:1
cluster_stats_messages_ping_sent:866
cluster_stats_messages_pong_sent:854
cluster_stats_messages_sent:1720
cluster_stats_messages_ping_received:849
cluster_stats_messages_pong_received:866
cluster_stats_messages_meet_received:5
cluster_stats_messages_received:1720

Clusterknoteninformationen anzeigen:

> Clusterknoten
 
470b7ff823f10a309fb07311097456210506f6d8 192.168.2.13:7005@17005 Slave 36565e0273fd62921aa1f2d85c5f7ac98a5b9466 0 1600267217000 2 verbunden
42d6e3979395ba93cd1352b6d17044f6b25d9379 192.168.2.11:7003@17003 Slave 0cc1aaf960defae7332e9256dd25ee5e5c99e65f 0 1600267218171 3 verbunden
ac5d34b57a8f73dabc60d3a56469055ec64fcde7 192.168.2.12:7004@17004 Slave 5e50824c55d4df42db4d2987796f0c0b468c273f 0 1600267216161 1 verbunden
0cc1aaf960defae7332e9256dd25ee5e5c99e65f 192.168.2.13:7002@17002 Master - 0 1600267218070 3 verbunden 10923-16383
36565e0273fd62921aa1f2d85c5f7ac98a5b9466 192.168.2.12:7001@17001 Master - 0 1600267217163 2 verbunden 5461-10922
5e50824c55d4df42db4d2987796f0c0b468c273f 192.168.2.11:7000@17000 ich selbst, Master - 0 1600267217000 1 verbunden 0-5460

Referenzadresse:

http://www.redis.cn/topics/cluster-tutorial.html

http://www.redis.cn/topics/cluster-spec.html

https://jasonkayzk.github.io

https://www.cnblogs.com/kevingrace/p/5685332.html

Dies ist das Ende dieses Artikels zum Bereitstellen eines Redis 6.x-Clusters über Docker. Weitere Informationen zum Bereitstellen eines Redis 6.x-Clusters mit Docker finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!