Detaillierte Erläuterung des Redis-Mechanismus für hohe Verfügbarkeit und hohe Parallelität

1. Mechanismus mit hoher Parallelität

Wir wissen, dass Redis auf einem einzelnen Thread basiert und im Standalone-Modus nur Zehntausende übertragen kann. Wie kann die Kapazität von Hunderttausenden im Folgenden verbessert werden? Big Data Durch die Master-Slave-Architektur von Redis und die Trennung von Lesen und Schreiben werden hohe gleichzeitige Anforderungen erreicht.

Video-Kursempfehlung →: „Millionen von Daten-Parallelitätslösungen (Theorie + Praxis)“

1. Die Konfiguration der Redis-Master-Slave-Replikation wird nicht betont, sie hängt hauptsächlich davon ab zur Master-Slave-Konfiguration Prinzip und Prozess der Replikation: Im Prozess der Master-Slave-Replikation von Redis ist ein Master-Host als Administrator erforderlich, um mehrere Slave-Maschinen zu erstellen. Wenn der Slave-Slave zu starten versucht, sendet er einen PSYNC-Befehl an den Master-Host. Wenn der Slave-Slave zu diesem Zeitpunkt erneut verbunden ist, werden die Daten, die der Slave-Slave nicht hat, vom Master-Host kopiert Zum ersten Mal wird eine Verbindung hergestellt, dann wird eine vollständige Neusynchronisierung ausgelöst. Nach dem Auslösen startet der Master-Host im Hintergrund einen Prozess zum Generieren einer RDB-Snapshot-Datei und speichert gleichzeitig die Schreibvorgänge in diesem Zeitraum im Cache. Wenn die RDB-Datei generiert wird, wird die RDB-Datei gesendet an den Slave-Computer, und der Slave-Computer erhält die Datei. Anschließend wird sie zuerst auf die Festplatte geschrieben und dann in den Speicher geladen. Schließlich sendet der Master-Host auch die im Speicher zwischengespeicherten Daten an den Slave-Computer zur gleichen Zeit. Wenn ein Master-Slave-Netzwerkfehler auftritt und mehrere Slaves sich wieder verbinden, startet der Master nur eine RDB neu, um alle Slaves zu bedienen. [Verwandte Empfehlungen:

Redis-Video-Tutorial

]Haltepunkt-Resume: Es gibt einen Replikat-Offset im Master und im Slave und eine Master-ID darin. Der Offset wird im Backlog gespeichert, wenn die Master-Slave-Maschine wieder eine Verbindung herstellt Bei einem Netzwerkfehler wird der entsprechende letzte Replikat-Offset gefunden und kopiert. Wenn der entsprechende Offset nicht gefunden wird, wird eine vollständige Neusynchronisierung ausgelöst.

①Der vollständige Replikationsprozess

(1) Der Slave-Knoten wird gestartet und nur die Informationen des Masterknotens werden gespeichert, einschließlich Host und IP des Masterknotens, aber der Replikationsprozess hat noch nicht begonnen

Wohin? Master-Host und IP stammen von Redis. Die Slaveof-Konfiguration in conf

(2) Es gibt eine geplante Aufgabe im Slave-Knoten, die jede Sekunde prüft, ob ein neuer Master-Knoten zum Verbinden und Kopieren vorhanden ist Socket-Netzwerkverbindung mit dem Master-Knoten

(3) Slave-Knoten Senden Sie den Ping-Befehl an den Master-Knoten

(4) Passwortauthentifizierung, wenn der Master „requirepass“ festlegt, muss der Slave-Knoten das Masterauth-Passwort zur Authentifizierung senden
(5) Die Der Master-Knoten führt zum ersten Mal eine vollständige Replikation durch und sendet alle Daten an den Slave-Knoten.
(6) Der Master-Knoten schreibt weiterhin Befehle und kopiert sie asynchron auf den Slave-Knoten Die vollständige Kopie wird ausgeführt, wenn der Slave zum ersten Mal eine Verbindung zu msater herstellt. In diesem Prozess werden einige detaillierte Mechanismen ausgeführt.

(1) Sowohl der Master als auch der Slave behalten einen Offset bei wird auch kontinuierlich Offsets auf sich selbst akkumulieren

Der Slave meldet dem Master jede Sekunde seinen eigenen Offset, und der Master speichert auch den Offset jedes Slaves

Dies bedeutet nicht, dass er speziell für die vollständige Replikation verwendet wird. Der Hauptgrund ist, dass sowohl der Master als auch der Slave den Offset ihrer eigenen Daten kennen müssen, um die Inkonsistenz der Daten untereinander zu erkennen Wenn der Master-Knoten Daten auf den Slave-Knoten kopiert, schreibt er auch synchron eine Kopie der Daten in das Backlog. Das Backlog wird hauptsächlich zum inkrementellen Kopieren verwendet, wenn die vollständige Replikation unterbrochen ist.

(3) Master-Lauf-ID. Infoserver , können Sie die Master-Lauf-ID sehen.

Wenn Sie den Master-Knoten anhand von Host + IP lokalisieren, ist er unzuverlässig. Wenn der Master-Knoten neu startet oder sich die Daten ändern, sollte der Slave-Knoten anhand einer anderen Lauf-ID unterschieden werden. Wenn die Ausführungs-ID unterschiedlich ist, erstellen Sie eine vollständige Kopie

Wenn Sie Redis neu starten müssen, ohne die Ausführungs-ID zu ändern, können Sie den Befehl redis-cli debug reload verwenden

(4) pync

Verwenden Sie pync vom Slave-Knoten zum Kopieren vom Masterknoten, Pync-Runid-Offset

Der Masterknoten gibt Antwortinformationen entsprechend seiner eigenen Situation zurück. Es kann sich um den Runid-Offset FULLRESYNC handeln, der eine vollständige Kopie auslöst, oder um CONTINUE, der eine inkrementelle Kopie auslöst

③Vollständige Kopie

(1) Der Master führt bgsave aus und generiert lokal eine RDB-Snapshot-Datei.
(2) Der Master-Knoten sendet die RDB-Snapshot-Datei an den Slave-Knoten. Wenn die RDB-Kopierzeit 60 Sekunden überschreitet (Repl-Timeout), dann an den Slave-Knoten wird denken Wenn das Kopieren fehlschlägt, können Sie diesen Parameter entsprechend anpassen
(3) Bei Maschinen mit Gigabit-Netzwerkkarten werden im Allgemeinen 100 MB, 6G-Dateien pro Sekunde übertragen, was wahrscheinlich 60 Sekunden überschreitet
(4) Wenn der Masterknoten RDB generiert , alle neuen Schreibvorgänge werden im Speicher zwischengespeichert. Nachdem der Salve-Knoten die RDB gespeichert hat, wird der neue Schreibbefehl in den Salve-Knoten kopiert. (5) client-output-buffer-limit Slave 256 MB 64 MB 60. Wenn der Speicher Puffer wird während des Kopierens weiterhin verbraucht. Wenn er 64 MB oder 256 MB auf einmal überschreitet, stoppen Sie den Kopiervorgang und der Kopiervorgang schlägt fehl
(6) Nachdem der Slave-Knoten die RDB empfangen hat, löscht er seine alten Daten und lädt dann die RDB neu seinen eigenen Speicher und stellt ihn basierend auf der alten Datenversion der Außenwelt zur Verfügung
(7) Wenn der Slave-Knoten AOF aktiviert hat, führt er sofort BGREWRITEAOF aus und schreibt die AOF

rdb-Generierung neu, wobei rdb über das Netzwerk kopiert wird , Slave alte Daten bereinigen, Slave aof Neuschreiben, was sehr zeitaufwändig ist

Wenn die kopierten Daten Die Menge liegt zwischen 4G und 6G, dann dauert die vollständige Kopierzeit wahrscheinlich eineinhalb bis 2 Minuten

④Inkrementelles Kopieren

(1) Wenn die Master-Slave-Netzwerkverbindung während des vollständigen Kopiervorgangs getrennt wird, wird der Slave neu gestartet. Beim Herstellen einer Verbindung mit dem Master wird eine inkrementelle Replikation ausgelöst

(2) Der Master erhält einen Teil der verlorenen Daten direkt von Sein eigenes Backlog und sendet es an den Slave-Knoten. Der Standard-Backlog beträgt 1 MB. (3) msater basiert auf dem Offset im psync, der vom Slave gesendet wird Senden Sie sich gegenseitig Heartbeat-Informationen. Der Master sendet standardmäßig alle 10 Sekunden einen Heartbeat, und der Salve-Knoten sendet alle 1 Sekunde einen Heartbeat Dann wird es asynchron an den Slave-Knoten gesendet

Bei hoher Parallelität können mehrere Cluster mit einem Master und mehreren Backups das Problem der hohen Parallelität lösen, aber es gibt nur einen Master. Wenn der Master ausfällt, kann das gesamte System keine Schreibvorgänge ausführen und die Slaves können dies nicht Daten synchronisieren, und das gesamte System wird lahmgelegt, das Ganze ist nicht verfügbar. Der Hochverfügbarkeitsmechanismus von Redis ist der Sentinel-Mechanismus. Er ist eine wichtige Komponente im Redis-Cluster. Er ist für die Clusterüberwachung, Informationsbenachrichtigung, Failover und Konfigurationscenter verantwortlich.

(1) Clusterüberwachung, verantwortlich für die Überwachung, ob die Redis-Master- und Slave-Prozesse normal funktionieren

(2) Nachrichtenbenachrichtigung: Wenn eine Redis-Instanz ausfällt, ist der Sentinel dafür verantwortlich, Nachrichten als Alarmbenachrichtigungen an den Administrator zu senden

(3 ) Failover: Wenn der Master-Knoten auflegt, wird er automatisch an den Slave-Knoten weitergeleitet. (4) Konfigurationscenter: Wenn ein Failover auftritt, benachrichtigen Sie den Client über die neue Master-Adresse. Sentinel selbst ist verteilt und arbeitet als Cluster. müssen miteinander zusammenarbeiten.

Wenn sich herausstellt, dass der Masterknoten ausgefallen ist, ist die Zustimmung der Mehrheit der Wächter erforderlich. Dabei handelt es sich um verteilte Wahlen.

Der Sentinel-Mechanismus muss mindestens 3 Knoten sicherstellen, um seine Robustheit sicherzustellen. Wenn wir während des Tests nur zwei Knoten angeben, einen als Master-Knoten und einen als Slave-Knoten, dann ist in diesen beiden Knoten ein Wachposten verantwortlich Wenn einer von ihnen ausfällt Der Master-Host ist ausgefallen, daher ist ein Sentinel zur Durchführung der Wahl erforderlich. Dann kann der S1-Sentinel im Master-Knoten nicht mehr funktionieren und die Wahl kann nur vom S2-Sentinel im durchgeführt werden Nach der Wahl wird ein Sentinel für das Failover benötigt. Zur Ausführung der Arbeiten gibt der Mehrheitsparameter die Anzahl der für das Failover erforderlichen Sentinels an. Daher sind mindestens 3 Knoten erforderlich, um die Robustheit sicherzustellen.

3. Datenverlustprobleme aufgrund hoher Verfügbarkeit und hoher Parallelität

(1) Datenverlust durch asynchrone Replikation

Da die Replikation von Master -> Slave asynchron ist, werden einige Daten möglicherweise noch nicht repliziert. Der Slave und Master sind ausgefallen und diese Teile der Daten gehen verloren.

(2) Datenverlust durch Split Brain

Split Brain, das heißt, die Maschine, auf der sich ein Master befindet, verlässt plötzlich das normale Netzwerk und kann keine Verbindung zu anderen Slave-Maschinen herstellen, aber tatsächlich läuft der Master noch,

Zu diesem Zeitpunkt geht Sentinel möglicherweise davon aus, dass der Master ausgefallen ist, und startet dann die Auswahl und schaltet andere Slaves auf den Master um.

Zu diesem Zeitpunkt gibt es zwei Master im Cluster, den sogenannten Split Brain.

Zu diesem Zeitpunkt wird zwar ein bestimmter A-Slave auf den Master umgestellt, aber der Client hat möglicherweise keine Zeit, auf den neuen Master zu wechseln, und die Daten, die weiterhin auf den alten Master geschrieben werden, gehen möglicherweise verloren

Wenn also der alte Master wieder wiederhergestellt wird, bleibt er als Slave hängen. Wenn ein neuer Master auftaucht, werden seine eigenen Daten gelöscht und die Daten werden erneut vom neuen Master kopiert.

Beheben Sie Datenverluste, die durch asynchrone Replikation und Split-Brain verursacht werden.

min-slaves-to-write 1
 min-slaves-max-lag 10

Erfordert mindestens 1 Slave. Die Verzögerung der Datenreplikation und -synchronisierung darf 10 Sekunden nicht überschreiten.

Wenn alle Slaves verwendet werden, beträgt die Verzögerung der Datenreplikation und -synchronisierung mehr als 10 Sekunden, dann erhält der Master zu diesem Zeitpunkt keine Anfragen mehr

Die beiden oben genannten Konfigurationen können den durch asynchrone Replikation und Split-Brain verursachten Datenverlust reduzieren.

(1) Reduzieren Sie den durch asynchrone Replikation verursachten Datenverlust.

Mit der Min-Slaves-Max-Lag-Konfiguration können Sie sicherstellen, dass der Slave einmal repliziert Wenn die ACK-Verzögerung zu lang ist, geht man davon aus, dass nach dem Ausfall des Masters möglicherweise zu viele Daten verloren gegangen sind, sodass die Schreibanforderung abgelehnt wird. Dies kann den Datenverlust reduzieren, der dadurch verursacht wird, dass einige Daten nicht mit dem Slave synchronisiert werden Wenn der Master ausfällt, innerhalb eines kontrollierbaren Bereichs

(2) Reduzieren Sie den Split-Brain-Datenverlust

Wenn ein Master einen Split-Brain hat und die Verbindung zu anderen Slaves verliert, können die beiden oben genannten Konfigurationen sicherstellen, dass dies der Fall ist Es kann nicht fortgesetzt werden, Daten an die angegebene Anzahl von Slaves zu senden. Wenn der Slave sich länger als 10 Sekunden lang keine Bestätigungsnachricht gibt, lehnt er die Schreibanforderung des Clients direkt ab akzeptiert die neuen Daten des Clients nicht und vermeidet so Datenverlust

Die obige Konfiguration stellt sicher, dass Sie die neue Schreibanforderung ablehnen, wenn Sie die Verbindung zu einem Slave verlieren und feststellen, dass Ihnen nach 10 Sekunden kein Slave eine Bestätigung gibt.

In einem Split-Brain-Szenario verlieren Sie also bis zu 10 Sekunden an Daten. !

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung des Redis-Mechanismus für hohe Verfügbarkeit und hohe Parallelität. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!