1. Master-Slave-Replikation
Master-Slave-Replikationsprinzip:
Der Slave-Server verbindet sich mit dem Hauptserver und sendet den SYNC-Befehl
Nachdem der Hauptserver die SYNC-Benennung erhalten hat, beginnt er mit der Ausführung des BGSAVE-Befehls, um die RDB-Datei zu generieren und verwendet den Puffer, um alle danach ausgeführten Schreibbefehle aufzuzeichnen. Nachdem der Master-Server BGSAVE ausgeführt wurde, sendet er Snapshot-Dateien an alle Slave-Server und zeichnet währenddessen weiterhin die ausgeführten Schreibbefehle auf der Sendezeitraum;
Nach dem Empfang der Snapshot-Datei verwirft der Slave-Server alle alten Daten und lädt den empfangenen Snapshot
Nach dem Master Der Server-Snapshot wird gesendet, er beginnt mit dem Senden des Schreibbefehls im Puffer an den Slave-Server. Der Slave-Server schließt das Laden des Snapshots ab, beginnt mit dem Empfangen von Befehlsanfragen und führt Schreibbefehle aus der Master-Server-Puffer; (
Slave-Server-Initialisierung abgeschlossen)
Vorteile:
Unterstützt die Master-Slave-Replikation, der Host synchronisiert Daten automatisch mit dem Slave und liest und schreibt Trennung kann durchgeführt werden
Um den Lesevorgangsdruck des Masters zu entlasten, kann der Slave-Server den Client nur Lesebetriebsdienste bereitstellen, und der Schreibdienst muss noch abgeschlossen werden der Master
Slave kann auch Verbindungs- und Synchronisationsanfragen von anderen Slaves annehmen, wodurch der Synchronisationsdruck des Masters effektiv entlastet werden kann.
Master Server stellt Slaves Dienste auf nicht blockierende Weise bereit. Daher können Clients während der Master-Slave-Synchronisierung weiterhin Abfragen oder Änderungswünsche stellen.
Der Slave-Server führt auch die Datensynchronisierung auf nicht blockierende Weise durch. Wenn ein Client während der Synchronisierung eine Abfrageanforderung sendet, gibt Redis die Daten vor der Synchronisierung zurück
Vor dem Absturz konnten einige Daten nicht rechtzeitig mit dem Slave-Computer synchronisiert werden. Nach dem Wechsel der IP kommt es zu Dateninkonsistenzen, die die Verfügbarkeit verringern das System.
Redis unterstützt die Online-Erweiterung nur schwer. Wenn die Clusterkapazität die Obergrenze erreicht, wird die Online-Erweiterung sehr kompliziert.
Wenn der Master-Server den Dienst unterbricht, kann ein Slave-Server zum Master-Server aufgerüstet werden, um weiterhin Dienste bereitzustellen. Dieser Vorgang erfordert jedoch einen manuellen Vorgang. Zu diesem Zweck stellt Redis 2.8 das Sentinel-Tool zur Implementierung automatisierter Systemüberwachungs- und Fehlerbehebungsfunktionen bereit.
Die Rolle des Sentinels besteht darin, den Betriebsstatus des Redis-Systems zu überwachen. Zu seinen Funktionen gehören die folgenden zwei.
(1) Überwachen Sie, ob der Master-Server und der Slave-Server normal laufen.
(2) Wenn der Hauptserver ausfällt, wechselt er automatisch vom Slave-Server zum Hauptserver.
So funktioniert der Sentinel:
Jeder Sentinel-Prozess sendet einmal pro Sekunde eine Nachricht an den Master im gesamten Cluster einen PING-Befehl vom Server und anderen Sentinel-Prozessen.
Wenn die Zeit seit der letzten gültigen Antwort auf den PING-Befehl den durch die Option down-after-milliseconds angegebenen Wert überschreitet, wird die Instanz vom Sentinel-Prozess als subjektiv offline markiert (. SDOWN)
Wenn ein Master-Server als subjektiv offline (SDOWN) markiert ist, müssen alle Sentinel-Prozesse, die den Master-Server überwachen, einmal pro Sekunde bestätigen, dass der Master-Server tatsächlich eingetreten ist der subjektive Offline-Status
Wenn eine ausreichende Anzahl von Sentinel-Prozessen (größer oder gleich dem in der Konfigurationsdatei angegebenen Wert) im angegebenen Bereich vorhanden ist. Wenn bestätigt wird, dass es sich um den Master-Server handelt innerhalb des Zeitbereichs in den subjektiven Offline-Zustand (SDOWN) eingetreten ist, wird der Master-Server als objektiv offline (ODOWN) markiert.
Unter normalen Umständen sendet jeder Sentinel-Prozess INFO-Befehle einmal alle 10 Sekunden an alle Master-Server und Slave-Server im Cluster.
Wenn der Master-Server vom Sentinel-Prozess als objektiv offline (ODOWN) markiert wird, sendet der Sentinel-Prozess eine Nachricht an alle Slave-Slave-Server des Offline-Master-Servers Der INFO-Befehl ändert sich von einmal alle 10 Sekunden auf einmal jede Sekunde.
Wenn nicht genügend Sentinel-Prozesse vorhanden sind, um dem Offline-Schalten des Master-Servers zuzustimmen, wird der objektive Offline-Status des Master-Servers entfernt. Wenn der Master-Server den PING-Befehl erneut an den Sentinel-Prozess sendet und eine gültige Antwort zurückgibt, wird der subjektive Offline-Status des Master-Servers entfernt.
Vor- und Nachteile des Sentry-Modus
Vorteile:
Der Sentinel-Modus basiert auf dem Master-Slave-Modus und der Sentinel-Modus bietet alle Vorteile des Master-Slave-Modus.
Master und Slave können automatisch umgeschaltet werden, wodurch das System robuster und benutzerfreundlicher wird.
Nachteile:
Es ist schwierig, die Online-Erweiterung von Redis online zu unterstützen Die Erweiterung wird sehr kompliziert.
3.Redis-ClusterCluster
Der Sentry-Modus von Redis kann grundsätzlich eine hohe Verfügbarkeit und Lese-/Schreibtrennung erreichen, aber in In diesem Modus speichert jeder Redis-Server dieselben Daten, was eine Verschwendung von Speicher darstellt. Daher wird Redis 3.0 ein Cluster-Modus hinzugefügt, um die verteilte Speicherung von Redis zu implementieren, was bedeutet, dass jeder Redis-Knoten unterschiedliche Inhalte speichert.
Redis-Cluster nimmt eine zentrumslose Struktur an:
Alle Redis-Knoten sind miteinander verbunden (PING-PONG-Mechanismus) und binär Das Protokoll wird intern verwendet, um die Übertragungsgeschwindigkeit und Bandbreite zu optimieren.
Der Ausfall eines Knotens wird erst dann wirksam, wenn mehr als die Hälfte der Knoten im Cluster einen Ausfall erkennen.
Der Client ist direkt mit dem Redis-Knoten verbunden, ohne dass eine Zwischen-Proxy-Schicht erforderlich ist. Der Client muss sich nicht mit allen Knoten im Cluster verbinden, sondern nur mit allen verfügbaren Knoten im Cluster.
Arbeitsmethode:
Auf jedem Knoten von Redis gibt es zwei Dinge, eines ist der Slot. Sein Wertebereich ist: 0- 16383. Ein anderes ist Cluster, das als Cluster-Management-Plug-In verstanden werden kann. Wenn unser Zugriffsschlüssel eintrifft, erhält Redis ein Ergebnis basierend auf dem crc16-Algorithmus und berechnet dann den Rest des Ergebnisses auf 16384, sodass jeder Schlüssel einem Hash-Slot mit einer Nummer zwischen 0 und 16383 entspricht Dieser Wert wird verwendet Suchen Sie den Knoten, der dem entsprechenden Steckplatz entspricht, und springen Sie dann automatisch direkt zum entsprechenden Knoten, um Zugriffsvorgänge auszuführen.
Um eine hohe Verfügbarkeit zu gewährleisten, führt der Redis-Cluster-Cluster den Master-Slave-Modus ein. Ein Master-Knoten entspricht einem oder mehreren Slave-Knoten. Wenn der Master-Knoten ausfällt, werden die Slave-Knoten aktiviert. Wenn andere Master-Knoten einen Master-Knoten A anpingen und die Kommunikation zwischen mehr als der Hälfte der Master-Knoten und A abbricht, gilt der Master-Knoten A als ausgefallen. Wenn sowohl Master-Knoten A als auch sein Slave-Knoten A1 ausfallen, kann der Cluster keine Dienste mehr bereitstellen.
Weitere technische Artikel zu Redis finden Sie in der Spalte Redis-Tutorial, um mehr zu erfahren!
Das obige ist der detaillierte Inhalt vonSo implementieren Sie Clustering in Redis. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!