Verwenden Sie Docker, um einen Redis-Master-Slave-Replikationscluster zu erstellen

In einem Cluster mit Master-Slave-Replikationsmodus gibt es normalerweise einen Masterknoten und zwei oder mehr Slaveknoten. Auf den Masterknoten geschriebene Daten werden auf den Slaveknoten kopiert. Auf diese Weise kann das Anwendungssystem bei einem Ausfall des Masterknotens zum Lesen und Schreiben von Daten auf den Slaveknoten umschalten, was die Verfügbarkeit des Systems verbessern kann. Darüber hinaus kann die Lese-/Schreibleistung des System-Cache weiter verbessert werden, wenn der standardmäßige Lese-/Schreibtrennungsmechanismus im Master-Slave-Replikationsmodus übernommen wird. Daher ist für Systeme mit geringen Leistungs- und Echtzeitanforderungen der Master-Slave-Replikationsmodus ausreichend, um die allgemeinen Leistungs- und Sicherheitsanforderungen zu erfüllen.

1 Übersicht über den Master-Slave-Replikationsmodus

In tatsächlichen Anwendungen können die Daten nach dem Schreiben auf einen Redis-Server, sofern entsprechende Einstellungen vorhanden sind, auf einen anderen (oder mehrere) Redis-Server kopiert werden. Dabei wird der Datenquellenserver als Master-Server bezeichnet, und der Server, auf dem sich die kopierten Daten befinden, wird als Slave-Server bezeichnet.

Dieser Master-Slave-Replikationsmodus kann zwei Vorteile bringen. Erstens können Schreibvorgänge auf den Master-Server und Lesevorgänge auf den Slave-Server konzentriert werden, was die Lese- und Schreibleistung verbessern kann. Zweitens kann durch die Datensicherung die Datensicherheit verbessert werden. Wenn beispielsweise der Master-Redis-Server ausfällt, kann er schnell auf das Lesen von Daten vom Slave-Server umschalten.

Wenn die Parallelitätsanforderungen im Projekt nicht hoch sind oder die Daten selbst dann nicht aus dem Redis-Cache gelesen werden können, wird die Leistung dadurch nicht wesentlich beeinträchtigt. In diesem Fall kann ein Master-Slave-Replikationsmodus verwendet werden. Das Wirkungsdiagramm ist in der folgenden Abbildung dargestellt.

Sie können auch einen Ein-Master-Mehrere-Slave-Replikationseffekt einrichten. Die folgende Abbildung zeigt das entsprechende Effektdiagramm, d. h. die auf den Masterknoten geschriebenen Daten werden mit den beiden Slaveknoten synchronisiert. Andere Ein-Master-Mehrere-Slave-Modi sind dem sehr ähnlich.

Bezüglich des Master-Slave-Replikationsmodus beachten Sie bitte folgende Punkte.

Erstens kann ein Masterserver einen oder mehrere Slaveserver haben, und sogar ein Slaveserver kann einen weiteren Slaveserver haben, aber beim Kopieren von Daten können die Daten des Masterservers nur auf den Slaveserver kopiert werden, nicht umgekehrt.

Zweitens kann ein Slave-Server nur einem Master-Server folgen und ein Ein-Slave-Mehrere-Master-Modus ist nicht möglich.

Drittens wird in Versionen nach Redis 2.8 ein asynchroner Replikationsmodus verwendet, d. h. wenn eine Master-Slave-Replikation durchgeführt wird, hat dies keine Auswirkungen auf die Lese- und Schreibdatenvorgänge auf dem Masterserver.

2 Verwenden Sie Befehle, um einen Master-Slave-Cluster zu erstellen

Hier verwenden wir Docker-Container, um einen Cluster mit einem Master und zwei Slaves zu erstellen. Beim Konfigurieren der Master-Slave-Beziehung müssen Sie den Befehl „slaveof“ auf dem Slave-Knoten verwenden. Die spezifischen Schritte sind wie folgt.

Der erste Schritt besteht darin, ein Befehlsfenster zu öffnen und den folgenden Befehl auszuführen, um einen Redis-Container mit dem Namen redis-master zu erstellen. Beachten Sie, dass sein Port 6379 ist.

docker run -itd --name redis-master -p 6379:6379 redis:latest

Öffnen Sie im zweiten Schritt ein neues Befehlsfenster und führen Sie den folgenden Befehl aus, um einen Container mit dem Namen redis-slave1 zu erstellen. Beachten Sie, dass sein Port 6380 ist. Bitte beachten Sie, dass dies auf einem Computer ausgeführt wird. Daher wird die Portnummer verwendet, um den Master-Redis-Container von den beiden anderen Slave-Redis-Containern zu unterscheiden. Wenn in einem realen Projekt mehrere Redis-Server auf verschiedenen Servern bereitgestellt werden, kann Port 6379 für alle verwendet werden.

docker run -itd --name redis-slave1 -p 6380:6380 redis:latest

Der dritte Schritt besteht darin, zum Befehlsfenster zurückzukehren, das den Redis-Master-Container enthält, und darin den Befehl docker inspect redis-master auszuführen, um die Informationen des Redis-Master-Containers anzuzeigen. Sie können die IP-Adresse des Containers über das Element IPAddress sehen, das hier 172.17.0.2 lautet. Wenn in einem realen Projekt die IP-Adresse des Redis-Servers fest ist und die IP-Adresse des vom Docker-Container gestarteten Redis-Servers dynamisch ist, wird der obige Befehl hier verwendet, um die IP-Adresse zu erhalten.

Schritt 4. Führen Sie im Befehlsfenster des Redis-Master-Containers den Befehl docker exec -it redis-master /bin/bash aus, um das Befehlszeilenfenster aufzurufen. Verwenden Sie den Befehl redis-cli, um die Befehlszeile des Redis-Clients aufzurufen, und verwenden Sie dann den Befehl info replication, um den Status des aktuellen Master-Slave-Modus anzuzeigen. Sie können einige Ergebnisse wie unten gezeigt sehen.

 c:\Arbeit>Docker exec -it redis-master /bin/bash
 root@9433cd584d80:/Daten# redis-cli
 127.0.0.1:6379> Info-Replikation
 # Replikation
 Rolle: Meister
 verbundene_Slaves:0

Aus der Ausgabe von Zeile 5 können wir erkennen, dass die Rolle des aktuellen Reids-Master-Containers im Master-Slave-Modus der „Master-Server“ ist. Aus der Ausgabe von Zeile 6 können wir erkennen, dass der Master-Server derzeit keinen Slave-Server hat.

Verwenden Sie im Befehlsfenster des Redis-Slave1-Containers den Befehl docker exec -it redis-slave1 /bin/bash, um das Befehlszeilenfenster des Containers aufzurufen, verwenden Sie den Befehl redis-cli, um die Client-Befehlszeile aufzurufen, und verwenden Sie den Befehl info replication, um den Master-Slave-Modusstatus des Redis-Servers anzuzeigen. Einige der Ergebnisse werden unten angezeigt.

 c:\work>docker exec -it redis-slave1 /bin/bash
 root@2e3237c60211:/Daten# redis-cli
 127.0.0.1:6379> Info-Replikation
 # Replikation
 Rolle: Meister
 verbundene_Slaves:0

Da der Master-Slave-Modus zu diesem Zeitpunkt nicht über die Befehlszeile festgelegt wurde, zeigen die Ausgabeergebnisse der Zeilen 5 und 6 weiterhin, dass der aktuelle Server der „Masterserver“ ist und es keinen Slave-Server gibt.

Schritt 5. Führen Sie im Befehlsfenster des Containers „redis-slave1“ den folgenden „slaveof“-Befehl aus, um den aktuellen Redis-Server als Slave-Server festzulegen. Das Format dieses Befehls ist „Slaveof-IP-Adress-Portnummer“, die auf den Master-Server bei 172.17.0.2:6379 verweist.

Slave von 172.17.0.2 6379

Führen Sie nach dem Ausführen des Befehls die Info-Replikation erneut im Redis-Slave1-Client aus. Sie sehen einige Ergebnisse wie unten dargestellt. Aus dem Ergebnis in Zeile 3 können wir erkennen, dass der Redis-Slave1-Server zu einem Slave-Server geworden ist, und aus der Ausgabe in den Zeilen 4 und 5 können wir bestätigen, dass der Slave-Server dem Redis-Master-Server unter 172.17.0.2:6379 untergeordnet ist.

127.0.0.1:6379> Info-Replikation
 # Replikation
 Rolle: Sklave
 master_host:172.17.0.2
 Master-Port: 6379

Kehren Sie nun zum Befehlsfenster des Redis-Master-Containers zurück und führen Sie den Befehl „info replication“ erneut im Redis-Client aus, um den Master-Slave-Status anzuzeigen. Sie können einige Ergebnisse wie unten gezeigt sehen. Aus der Ausgabe von Zeile 4 können wir erkennen, dass der Redis-Masterserver bereits über einen Slave-Server verfügt.

 127.0.0.1:6379> Info-Replikation
 # Replikation
 Rolle: Meister
 verbundene_Slaves:1

Schritt 6. Öffnen Sie ein neues Befehlsfenster und führen Sie darin den folgenden Befehl aus, um einen neuen Redis-Container mit dem Namen redis-slave2 zu starten. Beachten Sie, dass sein Port 6381 ist.

docker run -itd --name redis-slave2 -p 6381:6381 redis:latest

Führen Sie dann den Befehl docker exec -it redis-slave2 /bin/bash aus, um das Befehlszeilenfenster des Containers aufzurufen, verwenden Sie dann den Befehl redis-cli, um den Client aufzurufen, führen Sie den Befehl slaveof 172.17.0.2 6379 aus, legen Sie diesen Redis-Server als Slave-Server fest und verbinden Sie ihn mit dem Master-Redis-Server, auf dem sich der Redis-Master-Container befindet.

Kehren Sie nach Abschluss der Verbindung zum Befehlszeilenfenster zurück, in dem sich der Redis-Master-Container befindet, und führen Sie den Befehl „info replication“ aus. Sie können die folgende Teilausgabe sehen. Aus der Ausgabe von Zeile 4 können Sie ersehen, dass der Master-Server derzeit mit zwei Slave-Servern verbunden ist.

127.0.0.1:6379> Info-Replikation
 # Replikation
 Rolle: Meister
 verbundene_Slaves:2

Bisher wurde der Master-Slave-Modus mit einem Master und zwei Slaves konfiguriert. Wenn Sie zu diesem Zeitpunkt den Befehl „get name“ auf den beiden Slave-Servern ausführen, ist der Rückgabewert leer. Wenn Sie zum Befehlszeilenfenster gehen, in dem sich der Redis-Master-Container befindet, führen Sie darin „set name Peter“ aus und führen Sie dann den Befehl „get name“ auf den beiden Slave-Servern aus. Sie können den Rückgabewert sehen. Dies bedeutet, dass der Master-Slave-Modus erfolgreich konfiguriert wurde und die Daten im Master-Server automatisch mit jedem Slave-Server synchronisiert werden.

3. Erstellen Sie durch Konfiguration einen Master-Slave-Cluster

Im Projekt können Sie den Befehl „slaveof“ verwenden, um einen Master-Slave-Cluster zu erstellen, oder Sie können Konfigurationsparameter verwenden, um ihn zu erstellen. Die spezifischen Schritte sind wie folgt.

Der erste Schritt besteht darin, den Befehl für den Hauptserver Redis-Master zu erstellen. Der folgende Befehl wird immer noch verwendet, und hier wird immer noch Port 6379 verwendet.

docker run -itd --name redis-master -p 6379:6379 redis:latest

Verwenden Sie den Befehl „Docker Inspection Redis-Master“, um zu bestätigen, dass die IP-Adresse des Containers, in dem sich der Redis-Server befindet, weiterhin 172.17.0.2 ist.

Der zweite Schritt besteht darin, in das Verzeichnis C:\work\redis\redisConf zu gehen, eine Konfigurationsdatei redisSlave1.conf zu erstellen und den folgenden Inhalt hineinzuschreiben.

Port 6380

Slave von 172.17.0.2 6379

Stellen Sie den Redis-Port über den Befehl in Zeile 1 auf 6380 ein. Stellen Sie den Redis-Server über die Slaveof-Konfiguration in Zeile 2 auf „Slave-Modus“ ein und stellen Sie eine Verbindung zum Master-Server her, auf dem sich Redis-Master befindet.

Der dritte Schritt besteht darin, den folgenden Befehl in einem neuen Befehlsfenster auszuführen, um einen Redis-Server mit dem Namen redids-slave1 zu erstellen. Der Arbeitsport des Servers ist 6380, und der Parameter nach „redis-server“ gibt an, dass beim Starten des Redis-Servers die Konfigurationsdatei redisSlave1.conf geladen werden soll.

docker run -itd --name redis-slave1 -v C:\work\redis\redisConf:/redisConfig:rw -p 6380:6380 redis:latest redis-server /redisConfig/redisSlave1.conf

Verwenden Sie dann den Befehl docker exec -it redis-slave1 /bin/bash, um die Befehlszeile des Containers aufzurufen. Da der Redis-Arbeitsport hier 6380 geworden ist, müssen Sie den Befehl redis-cli -h 127.0.0.1 -p 6380 verwenden, um den Redis-Client aufzurufen. Wenn Sie darin den Befehl info replication ausführen, können Sie die folgenden Teilergebnisse sehen, die weiter bestätigen können, dass der redis-slave1-Server dem redis-master-Server untergeordnet ist.

 root@80e7ae14a322:/Daten# redis-cli -h 127.0.0.1 -p 6380
 127.0.0.1:6380> Info-Replikation
 # Replikation
 Rolle: Sklave
 master_host:172.17.0.2
 Master-Port: 6379

Schritt 4. Gehen Sie zum Verzeichnis C:\work\redis\redisConf, erstellen Sie eine Konfigurationsdatei redisSlave2.conf und schreiben Sie den folgenden Inhalt hinein.

Port 6381

Slave von 172.17.0.2 6379

Hier wird Port 6381 verwendet und der Befehl „slaveof“ wird auch verwendet, um eine Verbindung mit dem Redis-Master-Server herzustellen. Führen Sie dann den folgenden Befehl in einem neuen Befehlsfenster aus, um einen Redis-Server mit dem Namen redids-slave2 zu erstellen. Der Arbeitsport des Servers ist 6381, und die Parameter nach „redis-server“ werden verwendet, um anzugeben, dass die Konfigurationsdatei „redisSlave2.conf“ beim Start des Redis-Servers geladen wird.

docker run -itd --name redis-slave2 -v C:\work\redis\redisConf:/redisConfig:rw -p 6381:6381 redis:latest redis-server /redisConfig/redisSlave2.conf

Verwenden Sie dann den Befehl docker exec -it redis-slave2 /bin/bash, um die Befehlszeile des Containers aufzurufen. Da der Redis-Arbeitsport nun 6381 ist, müssen Sie den Befehl redis-cli -h 127.0.0.1 -p 6381 verwenden, um den Redis-Client aufzurufen. Hier können Sie den Befehl info replication verwenden, um den Konfigurationseffekt zu bestätigen. Einige der laufenden Ergebnisse werden unten angezeigt.

root@6017108b97c4:/Daten# redis-cli -h 127.0.0.1 -p 6381
 127.0.0.1:6381> Info-Replikation
 # Replikation
 Rolle: Sklave
 master_host:172.17.0.2
 Master-Port: 6379

Bisher wurde die Konfiguration des Master-Slave-Replikationsclusters mithilfe der Konfigurationsdatei abgeschlossen. Wenn Sie zu diesem Zeitpunkt den Befehl set age 18 auf dem Client ausführen, auf dem sich der Masterserver redis-master befindet, und dann den Befehl get age auf den beiden Slave-Servern redis-slave1 und redis-slave2 ausführen, können Sie den Wert von age sehen, was erneut bestätigen kann, dass die Daten zwischen dem Master- und dem Slave-Server synchronisiert werden können.

4 Konfigurieren des Lese-/Schreibtrennungseffekts

Wenn Sie den Befehl info replication auf den beiden oben konfigurierten Slave-Servern redis-slave1 und redis-slave2 ausführen, können Sie auch die Konfiguration „slave_read_only:1“ sehen, was bedeutet, dass der Slave-Server standardmäßig „schreibgeschützt“ ist. Wenn Sie in der Redis-Client-Befehlszeile von redis-slave1 set val 1 eingeben, wird der in der zweiten Zeile unten angezeigte Fehler angezeigt, der das „schreibgeschützte“ Attribut des Redis-Servers weiter verifizieren kann.

127.0.0.1:6380> Wert 1 setzen

(Fehler) NUR-LESEN. Sie können nicht auf eine schreibgeschützte Replik schreiben.

Für den Redis-Slave-Server wird empfohlen, die Standardkonfiguration "Nur Lesen" zu verwenden, da im Projekt Daten im Allgemeinen nicht auf den "Slave-Server" als Datensynchronisierungsziel geschrieben werden. Wenn es für geschäftliche Zwecke wirklich notwendig ist, können Sie mit den folgenden Schritten den Effekt „lesbar und beschreibbar“ einstellen.

Der erste Schritt besteht darin, der oben erwähnten Konfigurationsdatei redisSlave2.conf eine Konfigurationszeile „slave-read-only no“ hinzuzufügen, um anzugeben, dass der Server lesbar und beschreibbar ist.

Wenn im zweiten Schritt der oben erwähnte Redis-Slave2-Container noch aktiv ist, müssen Sie den Container mit „docker stop redis-slave2“ stoppen und anschließend den Container mit dem Befehl „docker rm redis-slave2“ löschen. Anschließend können Sie den Redis-Slave2-Container mit dem folgenden Befehl erneut erstellen.

docker run -itd --name redis-slave2 -v C:\work\redis\redisConf:/redisConfig:rw -p 6381:6381 redis:latest redis-server /redisConfig/redisSlave2.conf

In der Konfigurationsdatei redisSlave2.conf nach dem Befehl redis-server wurde das Konfigurationselement „slave-read-only no“ verwendet, um den Modus „lesbar und beschreibbar“ einzustellen.

Verwenden Sie im dritten Schritt den Befehl docker exec -it redis-slave2 /bin/bash, um die Befehlszeile des Containers aufzurufen, und verwenden Sie dann den Befehl redis-cli -h 127.0.0.1 -p 6381, um den Redis-Client aufzurufen. Wenn Sie zu diesem Zeitpunkt den Befehl set val 1 erneut ausführen, können Sie erfolgreich Daten schreiben.

5. Verwenden Sie den Heartbeat-Mechanismus, um die Zuverlässigkeit der Master-Slave-Replikation zu verbessern

Wenn im Redis-Master-Slave-Replikationsmodus eine Datensynchronisierung zwischen dem Master- und dem Slave-Server stattfindet, sendet der Slave-Server standardmäßig einmal pro Sekunde einen REPLCONF ACK-Befehl an den Master-Server, um eine reibungslose Verbindung zwischen den beiden sicherzustellen. Dieser Mechanismus periodischer interaktiver Befehle zur Sicherstellung der Verbindung wird als „Heartbeat“-Mechanismus bezeichnet. Wenn Sie in der Befehlszeile des oben geöffneten Redis-Master-Masterservers den Befehl „info replication“ ausführen, können Sie den „Heartbeat“-Status seiner Slave-Server sehen.

 127.0.0.1:6379> Info-Replikation
 2 # Replikation
 3 Rolle: Meister
 4 verbundene_Slaves:2
 5 Slave0: IP = 172.17.0.3, Port = 6380, Status = online, Offset = 16185, Verzögerung = 1
 6 Slave1:IP=172.17.0.4,Port=6381,Status=online,Offset=16185,Lag=1

In den Zeilen 5 und 6 kann die Zeit, die der Slave-Server zum Senden des Befehls REPLCONF ACK benötigt, durch eine Verzögerung dargestellt werden. Diese beträgt 1 Sekunde und zeigt an, dass die Verbindung zwischen den beiden Slave-Servern und dem Master-Server reibungslos verläuft.

Sie können sich vorstellen, dass die Master-Slave-Replikation bedeutungslos wird, wenn der Slave-Server ausfällt. Zu diesem Zweck können die folgenden Schritte verwendet werden, um den Heartbeat-Mechanismus mit der aktiven Replikationsaktion zu verknüpfen.

Der erste Schritt besteht darin, eine neue Datei redisMaster.conf im Verzeichnis C:\work\redis\redisConf zu erstellen und den folgenden Code hineinzuschreiben.

min-Slaves zum Schreiben 2

Min-Slaves-Max-Lag 15

Die Parameter in der ersten Zeile geben an, dass die Mindestanzahl an Slave-Servern, die zur Implementierung der Master-Slave-Replikation erforderlich ist, 2 beträgt. Die Parameter in der zweiten Zeile geben an, dass die Master-Slave-Replikation nicht durchgeführt wird, wenn die Heartbeat-Verzögerung (d. h. der Lag-Wert) der durch die Parameter in der ersten Zeile angegebenen Anzahl an Slave-Servern (hier 2) größer als 15 Sekunden ist.

Diese beiden Bedingungen stehen in einer „oder“-Beziehung, d. h., solange die Anzahl der Slave-Server kleiner als 2 ist oder die Heartbeat-Verzögerung zwischen den beiden Slave-Servern größer als 15 Sekunden ist, stoppt der Master-Server den Master-Slave-Replikationsvorgang.

Starten Sie im zweiten Schritt den Redis-Master-Container mit dem folgenden Befehl. Da die obige Konfiguration beim Start des Redis-Servers zu diesem Zeitpunkt geladen wurde, erkennt der Redis-Master-Server bei der Durchführung der Master-Slave-Replikation die im ersten Schritt festgelegten Bedingungen. Dies kann die Zuverlässigkeit der Master-Slave-Replikation verbessern.

docker run -itd --name redis-master -v C:\work\redis\redisConf:/redisConfig:rw -p 6379:6379 redis:latester redis-server /redisConfig/redisMaster.conf

6 Verwenden Sie den Offset, um die Datenkonsistenz zu überprüfen

Wenn Sie in der oben geöffneten Befehlszeile des Redis-Master-Masterservers den Befehl „info replication“ ausführen, können Sie auch die Daten „master_repl_offset“ sehen, die den Offset der replizierten Daten darstellen, wie in Zeile 6 unten gezeigt. Der Wert hier beträgt 276 und gibt die Anzahl der Datenbytes an, die vom Masterserver an den Slaveserver gesendet werden.

127.0.0.1:6379> Info-Replikation
 # Replikation
 Rolle: Meister
 verbundene_Slaves:1
 …
 master_repl_offset:276

Wenn Sie zur Befehlszeile des Redis-Slave1-Slave-Servers gehen, können Sie den Offset auch über die Info-Replikation anzeigen, wie in Zeile 7 unten gezeigt.

127.0.0.1:6380> Info-Replikation
 # Replikation
 Rolle: Sklave
 master_host:172.17.0.2
 Master-Port: 6379
 …
 Slave_Repl_Offset: 276

Im Slave-Server geben diese Daten die Anzahl der vom Master-Server empfangenen Datenbytes an. Wenn die Daten im Master- und Slave-Server konsistent sind, bedeutet dies, dass die Daten zwischen dem Master- und dem Slave-Server synchronisiert sind.

Nachdem Sie den Befehl „set nextVal 1“ auf dem Masterserver redis-master ausgeführt und dann „info replication“ verwendet haben, um den Wert „master_repl_offset“ anzuzeigen, werden Sie feststellen, dass eine Änderung vorliegt. Führen Sie zu diesem Zeitpunkt den Befehl „info replication“ auf dem Slaveserver redis-slave1 aus und Sie werden feststellen, dass der Wert „master_repl_offset“ des Slaveservers immer noch mit dem des Masterservers übereinstimmt. Dies zeigt, dass die mit dem Befehl „set nextVal 1“ im Masterserver hinzugefügten Daten erfolgreich mit dem Slaveserver synchronisiert wurden. Mit anderen Worten, wenn ein Redis-Problem auftritt, können Sie den Wert master_repl_offset verwenden, um zu überprüfen, ob die synchronisierten Daten korrekt sind, und dann das Problem weiter beheben.

Zusammenfassen

Dies ist das Ende dieses Artikels über die Verwendung von Docker zum Erstellen eines Redis-Master-Slave-Replikationsclusters. Weitere Informationen zur Verwendung von Docker zum Erstellen eines Redis-Master-Slave-Replikationsclusters 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!