Wie Redis die Master-Slave-Replikation implementiert

　Bei der früheren Einführung von Redis arbeiten wir alle auf einem Server, was bedeutet, dass Lese-, Schreib- und Sicherungsvorgänge alle auf einem Redis-Server ausgeführt werden. Mit zunehmender Anzahl von Projektbesuchen werden auch die Vorgänge auf dem Redis-Server häufiger. Obwohl Redis beim Lesen und Schreiben sehr schnell ist, verursacht es in gewissem Maße auch eine gewisse Verzögerung. Um das Problem des großen Zugriffs zu lösen, wird normalerweise die Master/Slave-Architektur verwendet. und der Slave dient hauptsächlich zum Lesen. Nachdem der Master-Knoten aktualisiert wurde, synchronisiert er sich automatisch mit dem Slave-Slave-Knoten entsprechend der Konfiguration.

Als nächstes stellen wir vor, wie man die Master-Slave-Architektur aufbaut.

　ps: Hier simuliere ich mehrere Redis-Server auf einer Maschine. Im Vergleich zur tatsächlichen Produktionsumgebung ist die Grundkonfiguration dieselbe, nur die IP-Adresse und die Portnummer ändern sich.

　

1. Ändern Sie die Konfigurationsdatei

Kopieren Sie zunächst die Konfigurationsdatei redis.conf in drei Kopien und simulieren Sie drei Redis-Server, indem Sie die Ports ändern.

　

　 Dann ändern wir jeweils diese drei redis.conf-Dateien.

　①、Dämonisierung ändern ja

　

　Zeigt an, dass Redis als Daemon-Prozess gestartet wird (Start im Hintergrund)

　②、Konfigurieren Sie den PID-Dateipfad pidfile

　

　Zeigt an, wenn re dis wird als Daemon-Prozess ausgeführt. Wenn die PID-Standardeinstellung in die Datei /Var/redis/run/redis_6379.pid geschrieben wird

③, Port konfigurieren port

④, Protokolldateinamen konfigurieren

⑤ Konfigurieren Sie den RDB-Dateinamen

redis-cli -p 6379 redis-cli -p 6380 redis-cli -p 6381

🎜 🎜　🎜🎜🎜　 Konfigurieren Sie 6380redis.conf und 6381redis.conf einmal nacheinander, und die Konfiguration ist abgeschlossen. 🎜🎜 Als nächstes starten wir jeweils diese drei Dienste. 🎜🎜　🎜🎜🎜　 Überprüfen Sie, ob Redis über den Befehl gestartet wurde: 🎜🎜　🎜🎜🎜　 Geben Sie als Nächstes die drei Redis-Clients über die folgenden Befehle ein: 🎜🎜🎜🎜🎜🎜1🎜🎜2🎜🎜3 🎜🎜 🎜🎜redis-cli -p 6379🎜🎜redis-cli -p 6380🎜🎜redis-cli -p 6381🎜🎜🎜🎜🎜

2. Stellen Sie die Master-Slave-Beziehung ein ##🎜🎜 #　

Wir haben festgestellt, dass diese drei Knoten alle die Rolle des Meisters spielen. Wie konvertiert man die Knoten 6380 und 6381 in die Rolle eines Slave-Knotens?

　② Wählen Sie Port 6380 und Port 6381 aus und führen Sie den Befehl aus: SLAVEOF 127.0.0.1 6379

　

      

#🎜 🎜# Wir schauen uns die 6379-Knoteninformationen noch einmal an:

　

Sobald der Dienst neu gestartet wird, wird die zuvor über den Befehl festgelegte Master-Slave-Beziehung ungültig. Diese Beziehung kann durch die Konfiguration der Datei redis.conf dauerhaft gespeichert werden. 3. Testen Sie die Master-Slave-Beziehung

　

①, Inkrementelle Replikation

Der Masterknoten führt den Satz aus Kann der Befehl k1 v1 vom Knoten get k1 abgerufen werden?

　

#

　

　Es ist in Ordnung, Erhalten zu wissen.

　

②、Vollständige Kopie

Durch Ausführen von SLAVEOF 127.0.0.1 6379, wenn vor dem Masterknoten 6379 einige Schlüssel vorhanden sind, dann nach der Ausführung Kopiert der Slave-Knoten mit dem Befehl auch alle vorherigen Informationen?

Die Antwort ist ja, ich werde die Testergebnisse hier nicht veröffentlichen.

　

③、Master-Slave-Lese- und Schreibtrennung

Kann der Masterknoten Schreibbefehle ausführen und kann der Slaveknoten Schreibbefehle ausführen? 　

Der Grund hierfür ist die Konfiguration von Slave-Read-Only in der Konfigurationsdatei 6381redis.conf

　#🎜🎜 #

Wenn wir es auf „Nein“ ändern, ist es möglich, den Schreibbefehl auszuführen.

　

　Die vom Slave-Knoten geschriebenen Daten können jedoch nicht vom Slave-Knoten oder Master-Knoten abgerufen werden.

　

④、Master-Knoten ist ausgefallen

Wenn der Master-Knoten Master auflegt, ändern sich dann die Rollen der beiden Slave-Knoten?

　

　

Aus der obigen Abbildung ist ersichtlich, dass, nachdem der Masterknoten aufgelegt hat, der Die Rolle des Slave-Knotens ändert sich nicht.

　⑤ Wiederherstellung nach Ausfall des Masterknotens

Nachdem der Masterknoten aufgelegt hat, starten Sie den Host-Master sofort Ist der Masterknoten immer noch derselbe Master?

　

Das heißt, nachdem der Masterknoten aufgelegt hat, startet er neu und nimmt seine Rolle als Masterknoten wieder auf.

4. Sentinel-Modus

Durch die vorherige Konfiguration gibt es nur einen Master-Knoten. Sobald der Master-Knoten auflegt, kann der Slave-Knoten die Aufgabe des Master-Knotens nicht übernehmen Masterknoten Dann ist auch das gesamte System funktionsunfähig. Daraus entstand der Sentry-Modus, da der Slave-Knoten automatisch die Verantwortung des Master-Knotens übernehmen kann, wodurch das Problem der Ausfallzeit des Master-Knotens gelöst wird. Der Sentry-Modus dient dazu, von Zeit zu Zeit zu überwachen, ob Redis wie erwartet gut läuft (zumindest um sicherzustellen, dass der Masterknoten vorhanden ist, wenn es ein Problem mit einem Host gibt, wird der Sentry dies automatisch tun). Legen Sie die Slave-Maschine als neue Master-Maschine fest und lassen Sie andere Slave-Maschinen eine Master-Slave-Beziehung mit der neuen Master-Maschine aufbauen.

　

Schritte zum Erstellen des Sentinel-Modus:

　① Erstellen Sie eine neue sentinel.conf-Datei im Konfigurationsdateiverzeichnis Name darf nicht falsch sein. , und konfigurieren Sie dann den entsprechenden Inhalt

　

　

1

sentinel monitor Der Name der überwachten Maschine (benennen Sie ihn selbst) IP-Adresse Portnummer Anzahl der Stimmensentinel monitor 被监控机器的名字(自己起名字) ip地址 端口号 得票数

　　

　　分别配置被监控的名字，ip地址，端口号，以及得票数。当主机宕机时，从机需要投票决定谁接替成为主机，得票数达到1时不足以成为主机，必须超过1才可成为主机

　　②、启动哨兵

1	redis-sentinel /etc/redis/sentinel.conf

　🎜🎜　 Konfigurieren Sie jeweils den überwachten Namen, die IP-Adresse, die Portnummer und die Anzahl der Stimmen. Wenn der Master untergeht, müssen die Slaves darüber abstimmen, wer die Rolle des Masters übernimmt. Wenn die Anzahl der Stimmen 1 erreicht, reicht es nicht aus, Master zu werden. Sie muss 1 überschreiten, um Master zu werden. Starten Sie den Wachposten🎜

🎜1🎜🎜🎜🎜 redis-sentinel /etc/redis/sentinel.conf🎜🎜🎜🎜🎜

　Startschnittstelle:

　

　 Als nächstes töten wir den Host 6379 und sehen dann, welche Änderungen auf dem Slave-Knoten auftreten.

　

Nachdem wir den Masterknoten getötet hatten, überprüften wir das Hintergrunddruckprotokoll und stellten fest, dass 6381 dafür gestimmt hatte, der Masterknoten zu werden.

　　

　Zu diesem Zeitpunkt überprüfen wir die Knoteninformationen des Slave-Knotens 6381:

　

　Der 6381-Knoten ist automatisch zum Masterknoten geworden.

PS: Der Sentinel-Modus hat auch ein Single-Point-of-Failure-Problem, wenn die Sentinel-Maschine hängen bleibt. Die Lösung besteht darin, dass der Sentinel-Modus auch Cluster erstellt.

5. Master-Slave-Replikationsprinzip

Die Replikationsfunktion von Redis umfasst zwei Vorgänge: Synchronisierung (Sync) und Befehlsweitergabe (Befehlsweitergabe).

　①、Alte Versionssynchronisierung

　Wenn der Slave-Knoten den SLAVEOF-Befehl ausgibt, um den Slave-Server zum Kopieren des Master-Servers aufzufordern, schließt der Slave-Server dies ab, indem er einen SYNC-Befehl an den Master-Server sendet. Die Befehlsausführungsschritte sind:

　1. Senden Sie den SYNC-Befehl vom Server an den Master-Server

　2. Der Master-Server, der den SYNC-Befehl empfängt, führt den BGSAVE-Befehl aus, generiert im Hintergrund eine RDB-Datei und verwendet einen Puffer um alle Ausführungen von Anfang an aufzuzeichnen. Befehl schreiben

　　3. Wenn der BGSAVE-Befehl des Master-Servers ausgeführt wird, sendet der Master-Server die durch den BGSAVE-Befehl generierte RDB-Datei an den Slave-Server. Der Slave-Server empfängt die RDB-Datei und aktualisiert sie den Serverstatus auf den in der RDB-Datei aufgezeichneten Status.

　4. Der Master-Server sendet außerdem alle Schreibbefehle im Puffer an den Slave-Server und der Slave-Server führt die entsprechenden Befehle aus.

　②、Befehlsweitergabe

　 Wenn der Synchronisierungsvorgang abgeschlossen ist, führt der Master-Server entsprechende Änderungsbefehle aus. Zu diesem Zeitpunkt ist der Status des Slave-Servers und des Master-Servers inkonsistent.

　Um den Status des Master-Servers und des Slave-Servers konsistent zu halten, muss der Master-Server Befehlsweitergabevorgänge auf dem Slave-Server durchführen. Der Master-Server sendet seine eigenen Schreibbefehle zur Ausführung an den Slave-Server. Nachdem der Slave-Server den entsprechenden Befehl ausgeführt hat, bleibt der Status des Master- und Slave-Servers weiterhin konsistent.

Zusammenfassung: Durch synchrone Operationen und Befehlsweitergabefunktionen kann die Master-Slave-Konsistenzfunktion gut gewährleistet werden.

Aber wir betrachten ein Problem, wenn der Slave-Server während der Synchronisierung mit dem Master-Server plötzlich die Verbindung trennt und zu diesem Zeitpunkt einige Schreibvorgänge ausführt und der Slave-Server die Verbindung wiederherstellt. Wenn wir synchronisieren, müssen wir Generieren Laden Sie eine RDB-Datei vom Master-Server herunter und laden Sie sie auf den Slave-Server. Obwohl die Konsistenz sichergestellt werden kann, ist der Status des Master- und Slave-Servers vor der Trennung tatsächlich konsistent. Die Inkonsistenz besteht darin, dass der Slave-Server die Verbindung trennt und der Master-Server die Wiederherstellung durchführt Können wir bei der Verbindung vom Server nur die Schreibbefehle trennen und nicht den gesamten RDB-Snapshot?

　 Der Synchronisierungsvorgang ist tatsächlich ein sehr zeitaufwändiger Vorgang. Der Master-Server muss zunächst eine RDB-Datei über den BGSAVE-Befehl generieren und diese dann an den Slave-Server senden lädt dann die Datei und lädt sie. Während dieser Zeit kann der Slave-Server keine anderen Befehle verarbeiten.

　Um dieses Problem zu lösen, verwendet Redis einen neuen Synchronisierungsbefehl PSYNC, der den SYNC-Befehl ab Version 2.8 ersetzt. Die teilweise Neusynchronisierungsfunktion dieses Befehls wird verwendet, um das Effizienzproblem der erneuten Replikation nach der Trennung zu lösen. Das heißt, wenn der Slave-Server nach der Trennung wieder eine Verbindung zum Master-Server herstellt, sendet der Master-Server nur die nach der Trennung ausgeführten Schreibbefehle an den Slave-Server. Der Slave-Server muss diese Schreibbefehle nur empfangen und ausführen, um den Master aufrechtzuerhalten -Slave-Konsistenz.

6. Nachteile der Master-Slave-Replikation

Obwohl die Master-Slave-Replikation das Single-Point-of-Failure-Problem des Master-Knotens löst, gibt es welche, da alle Schreibvorgänge auf dem Master-Knoten ausgeführt und dann mit dem Slave-Knoten synchronisiert werden Es kommt zu einer gewissen Verzögerung, wenn das System sehr ausgelastet ist. Das Verzögerungsproblem wird umso schwerwiegender, je größer die Anzahl der Slave-Knoten ist.

Das obige ist der detaillierte Inhalt vonWie Redis die Master-Slave-Replikation implementiert. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!