Um eine hohe Verfügbarkeit (HA) in Redis zu erreichen, werden die folgenden zwei Methoden verwendet:
Master-Slave-Replikation von Daten.
Verwenden Sie Sentinels, um den Betrieb von Datenknoten zu überwachen. Sobald ein Problem mit dem Master-Knoten auftritt, wird der Dienst von der Spitze des Slave-Knotens aus fortgesetzt.
Master-Slave-Replikation
In Redis können die vom Master-Slave-Knoten replizierten Daten in vollständige Replikation und teilweise Replikation unterteilt werden.
Implementierung der vollständigen Kopierfunktion in der alten Version
Die vollständige Kopie wird mit dem Befehl snyc implementiert. Der Vorgang ist:
Senden Sie den Synchronisierungsbefehl vom Server an den Hauptserver.
Nach dem Empfang des Synchronisierungsbefehls ruft der Hauptserver den Befehl bgsave auf, um die ***rdb-Datei zu generieren, und synchronisiert diese Datei mit dem Slave-Server. Auf diese Weise wird der Status angezeigt, nachdem der Slave-Server die RDB-Datei geladen hat wird mit dem Master-Server ausgeführt. bgsave Konsistenz bei der Befehlserteilung.
Der Master-Server synchronisiert die im Befehlspuffer gespeicherten Schreibbefehle mit dem Slave-Server und der Slave-Server führt diese Befehle aus, sodass der Status des Slave-Servers mit dem aktuellen Status des Master-Servers übereinstimmt.
Das Hauptproblem bei der vollständigen Kopierfunktion der alten Version besteht darin, dass beim Trennen und erneuten Verbinden des Slave-Servers eine vollständige Kopie durchgeführt werden muss, selbst wenn bereits einige Daten auf dem Slave-Server vorhanden sind Daher hat die neue Version von Redis in diesem Teil Verbesserungen vorgenommen.
Implementierung der vollständigen Kopierfunktion in der neuen Version
Die neueste Version von Redis verwendet den Befehl psync, um den Befehl sync zu ersetzen. Der Befehl psync kann nicht nur eine vollständige Synchronisierung erreichen, sondern auch eine teilweise Synchronisierung.
Kopierversatz
Die beiden Parteien, die die Replikation durchführen, der Master- und der Slave-Server, behalten jeweils einen Replikationsversatz bei:
Jedes Mal, wenn der Master-Server N Bytes an Daten mit dem Slave-Server synchronisiert, ändert er sich selbst Der Kopierversatz + N.
Jedes Mal, wenn der Slave-Server N Datenbytes vom Master-Server synchronisiert, ändert er seinen eigenen Replikationsoffset +N.
Backlog-Puffer kopieren
Der Hauptserver verwaltet intern eine First-In-First-Out-Warteschlange fester Länge als Replikations-Backlog-Puffer mit einer Standardgröße von 1 MB.
Wenn der Master-Server die Befehlsweitergabe durchführt, synchronisiert er nicht nur den Schreibbefehl mit dem Slave-Server, sondern schreibt den Schreibbefehl auch in den Replikations-Backlog-Puffer.
Server-Lauf-ID
Jeder Redis-Server hat seine eigene Lauf-ID. Die laufende ID wird vom Server automatisch generiert, wenn er gestartet wird. Der Master-Server sendet seine eigene laufende ID an den Slave-Server Der Master-Server Die Lauf-ID wird gespeichert.
Bei der Synchronisierung, nachdem die Verbindung zum Slave-Server Redis getrennt und wieder hergestellt wurde, wird der Synchronisierungsfortschritt anhand der laufenden ID beurteilt:
Wenn die auf dem Slave-Server gespeicherte laufende ID des Hauptservers mit der aktuellen laufenden ID des Hauptservers übereinstimmt, Diesmal wird davon ausgegangen, dass der Hauptserver, der getrennt und wieder verbunden wurde, der zuvor replizierte Hauptserver ist, und der Hauptserver kann weiterhin teilweise Synchronisierungsvorgänge versuchen.
Andernfalls wird davon ausgegangen, dass der vollständige Synchronisierungsprozess abgeschlossen ist, wenn sich die laufende ID des Hauptservers zwischen den beiden vorher und nachher unterscheidet.
psync-Befehlsprozess
Mit den vorherigen Vorbereitungen beginnen wir mit der Analyse des psync-Befehlsprozesses:
Wenn der Slave-Server noch keinen Master-Server kopiert hat oder der Slave noch keinen Befehl ausgeführt hat , dann sendet der Slave-Server den Befehl psync ? -1 an den Master-Server und fordert den Master-Server auf, alle Daten zu synchronisieren.
Wenn der Slave-Server bereits zuvor einige Daten synchronisiert hat, sendet der Slave-Server den Befehl pync an den Master-Server, wobei runid die letzte laufende ID des Master-Servers ist Offset ist der aktuelle Slave-Server.
Nachdem der Master-Server in den ersten beiden Fällen den psync-Befehl empfangen hat, treten die folgenden drei Möglichkeiten auf:
Der Master-Server gibt eine +fullresync -Antwort zurück, was darauf hinweist, dass der Master Der Server erfordert die Kommunikation mit dem Slave-Server. Vollständiger Datensynchronisierungsvorgang. Die aktuell laufende ID des Hauptservers ist runid und der Replikationsoffset ist offset.
Wenn der Hauptserver mit + Weiter antwortet, bedeutet dies, dass der Hauptserver und der Slave-Server teilweise Datensynchronisierungsvorgänge durchführen und die fehlenden Daten vom Slave-Server synchronisiert werden können.
Wenn der Master-Server mit -err antwortet, bedeutet dies, dass die Version des Master-Servers niedriger als 2.8 ist und den psync-Befehl nicht erkennen kann. Zu diesem Zeitpunkt sendet der Slave-Server einen Synchronisierungsbefehl an den Master-Server, um ihn abzuschließen vollständige Datensynchronisierung.
Übersicht über den Sentinel-Mechanismus
Redis verwendet den Sentinel-Mechanismus, um eine hohe Verfügbarkeit (HA) zu erreichen:
Redis verwendet eine Reihe von Sentinel-Knoten, um die Verfügbarkeit des Masters zu überwachen -Slave-Redis-Dienst.
Sobald festgestellt wird, dass der Redis-Masterknoten ausgefallen ist, wird ein Sentinel-Knoten zum Leiter gewählt.
Sentinel*** wählt dann einen Redis-Knoten aus den verbleibenden Slave-Redis-Knoten als neuen primären Redis-Knoten zur Bereitstellung externer Dienste aus.
Das Obige unterteilt Redis-Knoten in zwei Kategorien:
Sentinel-Knoten (Sentinel): Verantwortlich für die Überwachung des Betriebs des Knotens.
Datenknoten: der Redis-Knoten, der normalerweise Clientanfragen bearbeitet, unterteilt in Master und Slave.
Das Obige ist der allgemeine Prozess, der die folgenden Probleme lösen muss:
Anleitung Redis Data-Knoten zur Überwachung verwenden?
Wie kann festgestellt werden, ob ein Redis-Datenknoten ungültig ist?
Wie wähle ich einen Sentinel-***-Knoten aus?
Auf welcher Grundlage wählt der Sentinel-Knoten den neuen primären Redis-Knoten aus?
Beantworten wir diese Fragen einzeln.
Drei Überwachungsaufgaben
Der Sentinel-Knoten überwacht die Dienstverfügbarkeit des Redis-Datenknotens durch drei geplante Überwachungsaufgaben.
Info-Befehl
Alle 10 Sekunden sendet jeder Sentinel-Knoten den Info-Befehl an die Master- und Slave-Redis-Datenknoten, um eine neue Topologie zu erhalten Information.
Redis-Topologieinformationen umfassen:
Auf diese Weise kann der Sentinel-Knoten die Slave-Knoteninformationen automatisch aus dem Info-Befehl abrufen, sodass die später hinzugefügten Slave-Knoteninformationen nicht explizit sein müssen Wahrnehmung konfiguriert.
Informationen mit __sentinel__:hello-Kanal synchronisieren
Alle 2 Sekunden sendet jeder Sentinel-Knoten __sentinel__ an den Redis-Datenknoten. Der :hello-Kanal Synchronisiert die von ihm selbst erhaltenen Masterknoteninformationen mit den aktuellen Sentinelknoteninformationen. Da auch andere Sentinelknoten diesen Kanal abonniert haben, kann dieser Vorgang tatsächlich Informationen über den Masterknoten und Sentinelknoten zwischen Sentinelknoten austauschen.
Dieser Vorgang bewirkt tatsächlich zwei Dinge: * Erkennen eines neuen Sentinel-Knotens: Wenn ein neuer Sentinel-Knoten beitritt, werden die Informationen des neuen Sentinel-Knotens zu diesem Zeitpunkt gespeichert und anschließend die Kommunikation mit dem Sentinel-Knoten hergestellt eine Verbindung. Schreiben Sie es folgendermaßen um:
* Tauschen Sie die Statusinformationen des Masterknotens aus, damit wir später objektiv feststellen können, ob der Masterknoten offline ist.
Heartbeat-Erkennung an Datenknoten durchführen
Alle 1 Sekunde sendet jeder Sentinel-Knoten eine Nachricht an den Master, die Slave-Datenknoten und andere Sentinel Knoten Der Ping-Befehl führt eine Heartbeat-Erkennung durch. Diese Heartbeat-Erkennung ist die Grundlage für nachfolgende subjektive Beurteilungen, dass der Datenknoten offline ist.
Subjektiv offline und objektiv offline
Subjektiv offline
Wenn der dritte Wenn die Heartbeat-Erkennungsaufgabe unter den drei oben genannten Überwachungsaufgaben nach der konfigurierten Ausfallzeit nach Millisekunden keine gültige Antwort erhält, wird der Datenknoten als „subjektiv offline (Sdown)“ betrachtet.
Warum heißt es „subjektiv offline“? Da in einem verteilten System mehrere Maschinen zusammenarbeiten, können im Netzwerk verschiedene Situationen auftreten. Die Beurteilung eines Knotens allein reicht nicht aus, um davon auszugehen, dass ein Datenknoten offline ist. .
Ziel offline
Wenn ein Sentinel-Knoten denkt, dass der Master-Knoten subjektiv offline ist, muss der Sentinel-Knoten „Sentinel ist Master“ übergeben - down-by addr“-Befehl, um andere Sentinel-Knoten abzufragen, ob der Master-Knoten offline ist. Wenn mehr als die Hälfte der Sentinel-Knoten antworten, dass sie offline sind, wird der Master-Knoten zu diesem Zeitpunkt als „objektiv offline“ betrachtet.
Sentinels auswählen***
Wenn der Master-Knoten objektiv offline geht, muss ein Sentinel-Knoten als Sentinel ausgewählt werden*** Um die anschließende Arbeit der Auswahl eines neuen Masterknotens abzuschließen.
Die allgemeine Idee dieser Wahl ist:
Jeder Sentinel-Knoten sendet „Sentinel is-master-down-by“ an den anderen sentinel nodes addr“-Befehl, um sich als Sentinel*** zu bewerben.
Wenn jeder Sentinel-Knoten den Befehl „Sentinel is-master-down-by addr“ erhält, darf er nur für ***-Knoten und andere stimmen Dies Der Befehl vom Knoten wird abgelehnt.
Wenn ein Sentinel-Knoten mehr als die Hälfte der Zustimmungsstimmen erhält, wird er zu einem Sentinel***.
Wenn in den ersten drei Schritten nicht innerhalb einer bestimmten Zeitspanne ein Wächter*** ausgewählt wird, beginnt die nächste Wahl erneut.
Wie Sie sehen können, ist dieser Wahlprozess dem Leiterwahlprozess in Raft sehr ähnlich.
Wählen Sie einen neuen Masterknoten aus
Wählen Sie unter den verbleibenden Redis-Slaveknoten einen neuen Masterknoten in der folgenden Reihenfolge aus:# 🎜🎜#
- Filtern Sie „ungesunde“ Datenknoten heraus: z. B. subjektiv offline, getrennte Slave-Knoten, Knoten, die nicht innerhalb von fünf Sekunden auf den Sentinel-Knoten-Ping-Befehl geantwortet haben, und Knoten, mit denen eine Verbindung besteht Der Master-Knoten ist vom Slave-Knoten getrennt.
- Wenn es einen Slave-Knoten mit Slave-Priorität *** gibt, geben Sie den Knoten zurück; andernfalls fahren Sie mit der Ausführung des nachfolgenden Prozesses fort.
- Wählen Sie den Slave-Knoten mit dem Kopieroffset *** aus, was bedeutet, dass die Daten auf diesem Slave-Knoten am vollständigsten sind. Wenn vorhanden, geben Sie sie zurück, wenn sie vorhanden sind nicht vorhanden, und fahren Sie mit dem nächsten Schritt fort.
- Zu diesem Zeitpunkt ist der Status aller verbleibenden Slave-Knoten gleich. Wählen Sie den Slave-Knoten mit der kleinsten Runid aus.
Neuen Masterknoten bewerben
Nach der Auswahl des neuen Masterknotens benötigen Sie noch*** Der Prozess, diesen Knoten zum neuen Masterknoten zu machen:
Sentinel*** gibt den Befehl „slaveof no one“ an den im vorherigen Schritt ausgewählten Slave-Knoten aus, um diesen Knoten zum Master-Knoten zu machen.
Sentinel*** sendet Befehle an die verbleibenden Slave-Knoten, um sie zu Slave-Knoten des neuen Master-Knotens zu machen.
Der Sentinel-Knotensatz aktualisiert den ursprünglichen Masterknoten auf den Slave-Knoten und wird bei der Wiederherstellung angewiesen, die Daten des neuen Masterknotens zu kopieren.
Das obige ist der detaillierte Inhalt vonWelche beiden Implementierungslösungen gibt es für Redis-Hochverfügbarkeit?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
