Detaillierte Erläuterung der Redis-Master-Slave-Synchronisation

Die wörtliche Bedeutung der Master-Slave-Synchronisation besteht darin, wer der Master und wer der Slave ist. Sie werden gleichzeitig ausgeführt, um einen Synchronisationseffekt zu erzielen. Wie viel wissen Sie über die Master-Slave-Synchronisation von Redis? In diesem Artikel wird hauptsächlich die Master-Slave-Synchronisationsanalyse von Redis vorgestellt. Ich hoffe, dass er allen helfen kann.

1. Redis-Master-Slave-Synchronisationsprinzip

1.1 Redis-Master-Slave-Synchronisationsprozess

Nach der Konfiguration des mit dem Slave-Server verbundenen Masters wird der Slave wird eingerichtet. Stellen Sie eine Verbindung zum Master her und senden Sie dann den Synchronisierungsbefehl. Unabhängig davon, ob die Verbindung für die erste Synchronisierung hergestellt wird oder wiederhergestellt wird, nachdem die Verbindung getrennt wurde, startet der Master einen Hintergrundprozess, um den Datenbank-Snapshot in einer Datei zu speichern. Gleichzeitig beginnt der Master-Hauptprozess mit der Erfassung neuer Schreibvorgänge Befehle abrufen und zwischenspeichern. Wenn der Hintergrundprozess das Schreiben der Datei abgeschlossen hat, sendet der Master die Snapshot-Datei an den Slave. Der Slave speichert die Datei auf der Festplatte und lädt sie dann in den Speicher, um den Datenbank-Snapshot auf dem Slave wiederherzustellen. Nachdem der Slave die Wiederherstellung der Snapshot-Datei abgeschlossen hat, leitet der Master alle zwischengespeicherten Befehle an den Slave weiter und der Slave aktualisiert die Speicherdatenbank. Nachfolgende vom Master empfangene Schreibbefehle werden über die ursprünglich aufgebaute Verbindung an den Slave gesendet. Die Befehle zum Synchronisieren von Daten vom Master zum Slave und die vom Client zum Master gesendeten Befehle verwenden dasselbe Protokollformat. Wenn die Verbindung zwischen Master und Slave getrennt wird, kann der Slave die Verbindung automatisch wiederherstellen. Wenn der Master gleichzeitig synchrone Verbindungsbefehle von mehreren Slaves empfängt, startet er lediglich einen Prozess zum Schreiben des Datenbankspiegels und sendet ihn dann an alle Slaves.

1.2 Merkmale der Redis-Master-Slave-Synchronisation

Die Master-Slave-Synchronisation weist offensichtliche verteilte Cache-Merkmale auf, die hauptsächlich die folgenden Aspekte umfassen:

1) Ein Master kann mehrere Slaves haben, und ein Slave kann auch mehrere Slaves haben.
2) Ein Slave kann sich nicht nur mit dem Master verbinden, sondern ein Slave kann sich auch mit anderen Slaves verbinden, um eine Baumstruktur zu bilden 🎜>3) Master-Slave-Synchronisation Der Master wird nicht blockiert, aber der Slave. Das heißt, wenn ein oder mehrere Slaves zum ersten Mal Daten mit dem Master synchronisieren, kann der Master weiterhin Anfragen des Clients bearbeiten. Im Gegenteil, wenn der Slave zum ersten Mal Daten synchronisiert, blockiert er die Anfrage des Clients und kann diese nicht verarbeiten Behandeln Sie speziell die Leseanforderung des Clients, oder wir können eine einfache Datenredundanz durchführen oder nur auf dem Slave verbleiben, um die Gesamtleistung des Clusters zu verbessern.


1.3 Einstellungsmethode für die aktive Redis-Synchronisierung

Es gibt zwei Möglichkeiten, die Synchronisierungseinstellung der Master- und Slave-Redis-Server abzuschließen. Alles muss auf dem Slave-Server durchgeführt werden, wobei der Redis-Server angegeben werden muss, mit dem der Slave eine Verbindung herstellen muss (es kann sich um den Master oder den Slave handeln).

1.3.1 In der Konfigurationsdatei festlegen

In der Konfigurationsdatei (redis.conf) des Redis-Servers als Slave festlegen.

Conf-Code

slaveof 10.1.1.102 6379 #指定master的ip和端口

Natürlich ist diese Einstellungsmethode sehr einfach, erfordert jedoch eine Änderung der Konfigurationsdatei und der Konfigurationsdatei befindet sich im Zustand „Geladen“, wenn der Server startet. Daher kann der Server nicht geändert werden, ohne ihn zu starten, und der Betrieb ist unflexibel.

Diese Konfigurationsmethode eignet sich als Erstkonfiguration während der Bereitstellung.

1.3.2 Einrichten im Redis-Client

Hier nehmen wir die von Redis offiziell empfohlenen Jedis als Beispiel. Die Tests im folgenden Artikel basieren ebenfalls Jedis. Die Jedis-Objektinstanz gehört hier zum Slave und die Parameter sind die Adresse und der Port des Servers.

Java-Code

slaveJdedis.slaveOf("10.1.1.102", 6379); #指定master的ip和端口 
slaveJdedis.slaveofNoOne(); #取消指定master，自己成为一个master了

Mit der angegebenen Methode können Sie den Master und Slave der Master- und Slave-Server problemlos ändern durch die Kundenbeziehung. Daher eignet sich diese Methode sehr gut, um die Master- und Slave-Server online nach Bedarf anzupassen.

1.3.3 Probleme mit der aktuellen Master-Slave-Synchronisation

Da die Master- und Slave-Server nicht automatisch von Redis ausgewählt werden und eine manuelle Teilnahme erfordern, erfolgt die Master-Slave-Umschaltung kann nicht automatisch beendet werden. Dabei stellt sich die Frage, wann und wer den Wechsel auslösen soll. Ich habe überprüft, dass der Client nicht über diese Funktion verfügt. Bei Bedarf müssen Sie sie selbst hinzufügen.

Jedis wählt derzeit zufällig aus, von welchem ​​Redis-Server gelesen werden soll. Um also automatisches verteiltes Lesen zu implementieren, müssen wir Jedis neu kapseln.

1) Es muss ein Mechanismus entwickelt werden, um den Arbeitsstatus von Master und Slave so schnell wie möglich zu erkennen.

Diese Funktionen können auf der Clientseite implementiert werden, der Effekt ist jedoch nicht sehr gut. Es wäre perfekt, wenn der Server selbst dies unterstützen könnte. Der Einführung auf der offiziellen Redis-Website zufolge scheint jedoch noch niemand eine solche Forderung gestellt zu haben, und es gibt keinen solchen Plan.

2. Einführung in Redis-Mainstream-Clients

Auf der offiziellen Website von Redis sind 5 Java-Client-Software für Redis aufgeführt. Unter ihnen ist Jedis der von Redis offiziell empfohlene Java-Client, der gepflegt und aktualisiert wurde. Derzeit ist die neueste stabile Version des Servers Redis2.4.17 und die neueste Testversion ist Redis 2.6.0 RC7.

2.1 Jedis

Jedis ist die offiziell empfohlene Java-Client-Version von Redis. Die neueste Version ist derzeit Jedis 2.1.0-5, die vollständig kompatibel mit Redis Version 2.0.0 ist. Dieser Client wird ständig gepflegt und aktualisiert.

2.2 JRedis

JRedis wurde schon lange nicht mehr aktualisiert und ist vollständig kompatibel mit der Redis 2.0.0-Version. Heute, nach der Aktualisierung vor Mai, kann es mit der neuesten Testversion Redis2.6.0 kompatibel sein.

2.3 JDBC-Redis

JDBC-Redis ist der JDBC-Treiber für die NoSQL-Datenbank Redis. Sie können nur die im März 2009 veröffentlichte Version jdbc-redis_0.1_beta herunterladen, die derzeit nicht mehr gepflegt wird.

2.4 RJC

RJC bietet Verbindungspooling im Apache DBCP-Stil. Updates wurden vor einem Jahr gestoppt und sind vollständig kompatibel mit der Redis 2.0.0-Version.

2.5 Redis-Protokoll

Dieses Update ist das schnellste und häufigste und ist mit der neuesten Redis 2.6.0-Version kompatibel. Es ist jedoch so positioniert, dass es das Redis-Protokoll vollständig unterstützt und effizienter mit dem Redis-Server interagiert. Daher werden die Funktionen des Redis-Servers nicht vollständig genutzt.

2.6 Gesamtbewertung jedes Java-Clients

Insgesamt implementiert jeder Client grundsätzlich die durch das Redis-Protokoll definierten Grundfunktionen. Das jüngste Redis-Protokoll-Update bietet die umfassendste Unterstützung für das Redis-Protokoll; Jedis bietet mehr Konfigurationsvorgänge für den Redis-Server und ist am bequemsten zu verwenden. Andere Clients werden selten gewartet und ihre Funktionen sind durchschnittlich.

Wenn Sie die Funktionalität des Clients ein wenig erweitern möchten, ist die Entwicklung auf Basis von Jedis der schnellste Weg.

Wenn Sie die Kompatibilität maximieren und Client-Funktionen erweitern möchten, ist das Redis-Protokoll die beste Wahl.

3. Vorschläge für die Verwendung der Redis-Master-Slave-Synchronisierung

Die Redis-Master-Slave-Synchronisierung wird nicht von allen aktuellen Java-Clients gut unterstützt. Der Hauptgrund dürfte in den Einschränkungen des Implementierungsmechanismus des Redis-Servers selbst liegen. Es ist möglich, wenn Sie es tun müssen, aber die Wirkung kann dadurch beeinträchtigt werden.

3.1 Durch Kapselung von Jdedis implementiert

1) Fügen Sie eine Verwaltungsklasse hinzu, die für die Aufrechterhaltung der Servertopologiebeziehung des Redis-Serverclusters verantwortlich ist.
2) Fügen Sie a hinzu neu Die Überwachungsklasse ist für die Überwachung und Aufrechterhaltung des Serverbetriebsstatus im Redis-Servercluster verantwortlich
3) Fügen Sie eine neue Master-Auswahlstrategieklasse hinzu, die für die Bestimmung des Umschaltzeitpunkts zwischen Master und Slave und die Auswahl der meisten verantwortlich ist Der entsprechende Redis-Server fungiert als Master.
4) Fügen Sie eine Proxy-Klasse hinzu, um die Lese- und Schreibvorgänge des aktuellen Jedis-Clients auf dem Redis-Server zu übernehmen. Die Anwendungsschicht nutzt den Jedis-Client über die Proxy-Klasse. Die Proxy-Klasse muss sicherstellen, dass der Redis-Servercluster für die Anwendungsschicht transparent ist.

Verwandte Empfehlungen:

Detaillierte Erläuterung des Beispielcodes für die MySQL-Master-Slave-Synchronisationskonfiguration

Detaillierte Einführung in die Implementierung von MySQL-Master- Slave-Synchronisationsprinzip (Bilder und Texte) )

Shell-Skript zur Überwachung der MySQL-Master-Slave-Synchronisation unter Linux

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung der Redis-Master-Slave-Synchronisation. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!