Redis-Master-Slave-Synchronisationsprinzip

1. Vorwort

Um die hohe Verfügbarkeit von Redis sicherzustellen, wird im Allgemeinen ein Cluster-Modus erstellt, bei dem es sich um den Master-Slave-Modus handelt.

Der Master-Slave-Modus kann die hohe Verfügbarkeit von Redis sicherstellen. Wie stellt Redis also die Datenkonsistenz des Master-Slave-Servers sicher? (Slave-)Synchronisation.

2. Erste vollständige Synchronisierung

Wenn ein Redis-Server zum ersten Mal den Salveof-Befehl an den Master-Server sendet, wird der Redis-Slave-Server verwendet führt eine vollständige Synchronisierung durch. Die Synchronisierungsschritte sind in der folgenden Abbildung dargestellt:

• Der Slave-Server sendet den psync-Befehl an den Master (Der zu diesem Zeitpunkt gesendete psync-Befehl lautet psync? -1), teilen Sie dem Master mit, dass ich Daten synchronisieren muss.
• Nach Erhalt des psync-Befehls führt der Master den BGSAVE-Befehl aus, um einen Snapshot der RDB-Datei zu erstellen.
• Nachdem die Generierung abgeschlossen ist, wird die RDB-Datei an den Slave gesendet.
• Wenn der Slave die Datei empfängt, lädt er den RDB-Snapshot und ändert den Datenbankstatus so, dass er mit dem Status des Masters übereinstimmt, wenn BGSAVE ausgeführt wird.
• Der Master sendet alle im Puffer gespeicherten Schreibbefehle, um dem Slave mitzuteilen, dass die Synchronisierung durchgeführt werden kann.
• Der Slave führt diese Schreibbefehle aus .

3. Befehlsweitergabe

Der Slave hat sich bereits mit dem Master synchronisiert, wenn der nachfolgende Master Bei einem Schreibvorgang, z. B. einem einfachen Set-Namen-Redis, sendet der Master, nachdem er den aktuellen Befehl ausgeführt hat, den aktuellen Befehl zur Ausführung an den Slave, um Datenkonsistenz zu erreichen.

4. Erneut kopieren

Wenn der Slave getrennt und wieder verbunden wird, wird er in eine vollständige Synchronisierung und eine teilweise Neusynchronisierung unterteilt Synchronisation

Werfen wir zunächst einen Blick auf die allgemeine Richtung der Teilsynchronisation

• Wenn der Slave die Verbindung trennt und wieder herstellt , wird der psync-Befehl an den Master gesendet.
• Nach dem Empfang von psync gibt der Master eine +continue-Antwort zurück, was darauf hinweist, dass der Slave eine teilweise Synchronisierung durchführen kann.
• Master sendet den Schreibbefehl nach Trennung an Slave
• Slave führt den Schreibbefehl aus.

Tatsächlich muss der Master, nachdem der Slave den psync-Befehl an den Master gesendet hat, anhand der folgenden drei Punkte noch beurteilen, ob eine teilweise Synchronisierung durchgeführt werden soll.

Lassen Sie uns zunächst die drei Aspekte vorstellen:

• Server, auf dem die ID ausgeführt wird

Jedes Nach einem Redis Wird der Server gestartet, wird eine Lauf-ID generiert.

Bei der ersten Synchronisierung teilt der Master dem Slave seine ID mit und der Slave zeichnet sie auf. Wenn der Slave die Verbindung trennt und wieder herstellt, versucht er, die Synchronisierung durchzuführen, wenn dies der Fall ist stellt fest, dass die ID zu diesem Master gehört. Teilweise Neusynchronisierung. Wenn sich die ID vom aktuell verbundenen Master unterscheidet, wird eine vollständige Neusynchronisierung durchgeführt.

• Replikationsoffset

Replikationsoffset umfasst Master-Replikationsoffset Wenn der Replikationsoffset des Nach der anfänglichen Synchronisierung sind die beiden Datenbanken gleich, dann führt der Master einen Schreibbefehl aus, dann ist der Offset des Masters +1, der Master schreibt den Befehl an den Slave, der Slave führt ihn einmal aus und der Slave-Offset wird um +1 verschoben Die Versionen sind konsistent.

• Replikations-Backlog-Puffer

Der Replikations-Backlog-Puffer wird vom Master festgelegt und verwaltet Eine lange First-In-First-Out-Warteschlange.

Wenn der Slave PYNC sendet, sendet er auch seinen eigenen Offset an den Master. Wenn die Daten nach dem Offset des Slaves noch im Puffer vorhanden sind, wird eine +continue-Benachrichtigung zurückgegeben. Der Slave führt eine teilweise Neusynchronisierung durch.

Wenn die Daten nach dem Slave-Offset nicht mehr im Puffer sind, wird eine vollständige Neusynchronisierung durchgeführt.

Wenn wir die oben genannten drei Punkte kombinieren, können wir Folgendes zusammenfassen:

• Wenn der Slave getrennt und wieder verbunden wird, sendet er den psync-Befehl an den Master.
• Der Master beurteilt zunächst die Server-Lauf-ID. Wenn diese mit seiner eigenen übereinstimmt, beurteilt er den Offset
• Der Master beurteilt selbst, ob der Verschiebungsbetrag mit dem Offset des Slaves übereinstimmt.
• Wenn es inkonsistent ist, geht der Master zum Puffer, um zu bestimmen, ob die Daten nach dem Offset des Slaves vorhanden sind.
• Wenn vorhanden, wird eine +continue-Antwort zurückgegeben, die angibt, dass der Slave eine teilweise Synchronisierung durchführen kann.
• Master sendet den Schreibbefehl nach Trennung an Slave
• Slave führt den Schreibbefehl aus.

5. Der letzte Prozess der Master-Slave-Synchronisation

6. Fazit

Kürzlich habe ich entsprechend den Anforderungen des Unternehmens einen Redis-Master-Slave-Cluster aufgebaut und Sentinels verwendet, um Master- Slave-Umschaltung. Daher habe ich das Master-Slave-Prinzip von Redis anhand von „Redis Design and Implementation“ geklärt, um meinen Eindruck zu vertiefen.

Empfohlenes Tutorial: „Redis-Tutorial“

Das obige ist der detaillierte Inhalt vonRedis-Master-Slave-Synchronisationsprinzip. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!