Beispielanalyse der Redis-Backup-, Disaster-Recovery- und Hochverfügbarkeitspraxis

1. Eine kurze Einführung in Redis

Redis ist eine leistungsstarke, nicht relationale Schlüsselwertdatenbank. Aufgrund ihrer Hochleistungseigenschaften unterstützt sie hohe Verfügbarkeit, Persistenz, mehrere Datenstrukturen, Cluster usw. Dadurch zeichnet es sich aus und wird zu einer häufig verwendeten nicht relationalen Datenbank.

Darüber hinaus verfügt Redis über viele Nutzungsszenarien.

Session Cache

Redis-Cache-Sitzungen haben sehr gute Vorteile, da Redis Persistenz bietet, die in Anwendungsszenarien, die Sitzungen über einen langen Zeitraum aufrechterhalten müssen, wie z. B. Warenkorb-Sitzungsunterstützung, eine gute Langzeitleistung bieten kann Benutzer mit einem guten Einkaufserlebnis.

Vollständiger Seiten-Cache

In WordPress bietet Pantheon ein gutes Plug-in wp-redis, das die von Ihnen durchsuchten Seiten mit der schnellsten Geschwindigkeit laden kann.

Queue

Redis unterstützt Listen- und Set-Operationen und eignet sich daher sehr gut für die Verwendung als Nachrichtenwarteschlangenplattform. Wir nutzen oft die Warteschlangenfunktion von Reids, um Käufe einzuschränken. Beispielsweise können an Feiertagen oder in Aktionsperioden bestimmte Aktivitäten durchgeführt werden, um das Kaufverhalten der Benutzer einzuschränken, sodass sie heute nur noch wenige Käufe oder nur einmal innerhalb eines bestimmten Zeitraums tätigen können. Es ist auch besser für die Anwendung geeignet.

Ranking

Redis implementiert den Vorgang des Erhöhens oder Verringerns von Zahlen im Speicher sehr gut. Daher verwenden wir Redis in vielen Ranking-Szenarien. Beispielsweise bewerten Roman-Websites Romane und empfehlen Benutzern basierend auf dem Ranking die am besten bewerteten Romane.

Veröffentlichen/Abonnieren

Redis bietet Veröffentlichungs- und Abonnementfunktionen. Es gibt viele Szenarien für Veröffentlichung und Abonnement. Beispielsweise können wir ein Chat-System implementieren, das auf den Veröffentlichungs- und Abonnementfunktionen von Redis basiert.

Darüber hinaus gibt es viele andere Szenarien, in denen Redis eine gute Leistung erbringt.

2. Single-Point-of-Failure-Problem bei der Verwendung von Redis

Redis wird in verschiedenen Unternehmen verwendet und seine zahlreichen hervorragenden Funktionen und umfangreichen Anwendungsszenarien sind der Grund für seine Existenz. Dann kommen die Probleme und Risiken. Obwohl Redis über umfangreiche Anwendungsszenarien verfügt, verwenden einige Unternehmen die Bereitstellung einzelner Knoten beim Üben von Redis-Anwendungen immer noch relativ konservativ, was Sicherheitsrisiken für die zukünftige Wartung mit sich bringt.

Ich hatte im Jahr 2015 einmal mit einem Betriebsunterbrechungsproblem zu kämpfen, das durch einen Single Point of Failure verursacht wurde. Als Redis zum ersten Mal bereitgestellt wurde, verwendete es eine Einzelknotenbereitstellung anstelle einer verteilten Bereitstellung und berücksichtigte Probleme bei der Notfallwiederherstellung nicht.

Zu diesem Zeitpunkt nutzten wir den Redis-Server, um den Kauf von reduzierten Produkten durch den Benutzer zu kontrollieren. Aus unbekannten Gründen fiel jedoch der Server des Redis-Knotens aus, was dazu führte, dass wir das Kaufverhalten des Benutzers nicht kontrollieren konnten Der Benutzer kann innerhalb eines bestimmten Zeitraums mehrmals einkaufen. Das Verhalten von reduzierten Waren.

Man kann sagen, dass ein solcher Ausfallunfall dem Unternehmen irreparable Verluste verursacht hat. Als die Person, die das System zu diesem Zeitpunkt bediente und wartete, war es notwendig, dieses Problem zu beheben die Architektur verbessern. Deshalb begann ich, nach Möglichkeiten zu suchen und zu lernen, wie man den Redis-Single-Point-of-Failure in nicht verteilten Anwendungen beheben kann.

3. Sicherung und Notfallwiederherstellung von Redis-Anwendungen in nicht verteilten Szenarien

Redis-Master-Slave-Replikation sollte jetzt weit verbreitet sein. Zu den häufig verwendeten Master-Slave-Replikationsarchitekturen gehören die folgenden zwei Architekturlösungen.

Häufig verwendete Redis-Master-Slave-Replikation

Option 1

Im Allgemeinen ist diese Struktur die gebräuchlichste, dh ein Masterknoten und zwei Slave-Knoten. Wenn der Client Daten schreibt, schreibt er auf den Master-Knoten, und wenn er liest, liest er von zwei Slaves. Dadurch wird eine Leseerweiterung erreicht und die Leselast auf dem Master-Knoten reduziert.

Option 2

Diese Architektur hat auch einen Master und zwei Slaves. Master und Slave1 verwenden Keepalived, um die VIP-Migration auf unterschiedliche Weise zu implementieren. Wenn der Client eine Verbindung zum Master herstellt, erfolgt die Verbindung über VIP. Dadurch wird die Situation einer IP-Änderung in Lösung 1 vermieden.

Vor- und Nachteile der Redis-Master-Slave-Replikation

Vorteile

Sobald der Master ausfällt, kann der Slave-Knoten zu einem neuen Master befördert werden und den alten Master ersetzen, um fortzufahren Bereitstellung von Diensten

Implementierung Lesen Sie die Erweiterung. Die Master-Slave-Replikationsarchitektur wird im Allgemeinen verwendet, um eine Leseerweiterung zu erreichen. Der Master implementiert hauptsächlich die Schreibfunktion und der Slave implementiert die Lesefunktion keine Masterkopien möglich.

Zu diesem Zeitpunkt müssen Sie die folgenden Vorgänge ausführen (vorausgesetzt, Slave1 wird zum Master befördert):

Führen Sie den Befehl „slaveof no one“ auf Slave1 aus, um Slave1 zum neuen Master-Knoten zu befördern.

ist auf Slave1 als beschreibbar konfiguriert. Dies liegt daran, dass der Slave in den meisten Fällen als schreibgeschützt konfiguriert ist.

Teilen Sie dem Client (d. h. dem Programm, das eine Verbindung zu Redis herstellt) die Verbindungsadresse des neuen Master-Knotens mit.

Konfigurieren Sie Slave2 so, dass Daten vom neuen Master kopiert werden.

Architekturplan 2

Wenn der Master ausfällt, kann der Client für Datenoperationen eine Verbindung zu Slave1 herstellen, aber Slave1 wird zu einem einzelnen Punkt, was zu einem einzelnen Fehlerpunkt (Single Point of Failure) führt, der häufig benötigt wird zu vermeiden.

Danach müssen Sie die folgenden Vorgänge ausführen:

1. Führen Sie den Befehl „Slave of No One“ auf Slave1 aus, um Slave1 zum neuen Master-Knoten zu befördern In den meisten Fällen konfigurieren Sie Slave als schreibgeschützt

2. Konfigurieren Sie Slave2 so, dass er Daten vom neuen Master kopiert

3. Es ist zu beachten, dass alle Architekturlösungen einen manuellen Eingriff für das Failover erfordern. Der Bedarf an manuellen Eingriffen erhöht den Arbeitsaufwand für Betrieb und Wartung und hat auch enorme Auswirkungen auf das Geschäft. Zu diesem Zeitpunkt können Sie die Hochverfügbarkeitslösung von Redis verwenden – Sentinel

IV Einführung in Redis Sentinel

Redis Sentinel bietet eine Hochverfügbarkeitslösung für Redis. Aus praktischer Sicht kann der Einsatz von Redis Sentinel eine Redis-Umgebung schaffen, die bestimmte Fehler ohne menschliches Eingreifen verhindert. Redis Sentinel verwendet eine verteilte Architektur und führt mehrere Prozesse für die kollaborative Zusammenarbeit aus. Führen Sie mehrere Sentinel-Prozesse aus, um zusammenzuarbeiten. Wenn mehrere Sentinels einem bestimmten Master keine Dienste mehr bereitstellen können, wird eine Fehlererkennung durchgeführt, wodurch die Möglichkeit falsch positiver Ergebnisse verringert wird.

5. Redis Sentinel-Funktion

Die Hauptfunktionen von Redis Sentinel in der Redis-Hochverfügbarkeitslösung sind wie folgt:

Überwachung

Sentinel prüft ständig, ob Master und Slave normal wie erwartet laufen

Benachrichtigung

Über die API kann Sentinel Systemadministratoren und programmüberwachte Redis-Ausfälle benachrichtigen.

Automatisches Failover

Wenn der Master nicht wie erwartet läuft, kann Sentinel den Failover-Prozess starten, einer davon wird vom Slave ausgeführt Werden Sie zum Master und andere Slaves werden für die Verwendung des neuen Masters neu konfiguriert. Anwendungen, die den Redis-Dienst nutzen, werden ebenfalls benachrichtigt, dass sie beim Herstellen einer Verbindung die neue Adresse verwenden sollen.

Konfigurationsanbieter

Sentinel kann als Authentifizierungsquelle für die Erkennung von Client-Diensten verwendet werden: Der Client stellt eine Verbindung zu Sentinel her, um die Redis-Master-Adresse zu erhalten, die derzeit für einen bestimmten Dienst verantwortlich ist. Wenn ein Failover auftritt, meldet Sentinel die neue Adresse.

6. Redis Sentinel-Architektur

7. Redis Sentinel-Implementierungsprinzip

Sentinel-Cluster überwacht sich selbst und die Redis-Master-Slave-Replikation. Wenn festgestellt wird, dass der Master-Knoten ausfällt, werden die folgenden Schritte ausgeführt:

1) Es findet eine Wahl zwischen Sentinels statt, um einen Anführer zu wählen, und der gewählte Anführer führt ein Failover durch

• Der Sentinel-Anführer wählt einen aus vom Slave-Knoten als neuen Master-Knoten. Hier ist eine Umformulierung dieses Satzes: Um die Slave-Wahl zu implementieren, müssen die folgenden Wahlmethoden implementiert werden: a) Die Zeit zum Trennen der Verbindung zum Master Zeit vom Sentinel Basierend auf der Zeit zwischen der Feststellung, dass der Master nicht verfügbar ist, und dem Beginn des Failovers durch den Sentinel wird der Slave als nicht für die Heraufstufung zum Master geeignet angesehen.

b) Slave-Priorität

• Jeder Slave hat eine Priorität, die in der Konfigurationsdatei redis.conf gespeichert ist. Wenn die Prioritäten gleich sind, fahren Sie fort.

c) Die Replikations-Offset-Position

Der Replikations-Offset zeichnet auf, wo die Daten vom Master kopiert werden. Je größer der Replikations-Offset, desto mehr Daten werden vom Master empfangen. Wenn der Replikations-Offset gleich ist, fahren Sie mit der Auswahl fort

d) Run-ID

Wählen Sie den Slave mit der kleinsten Run-ID als neuen Master

Das Flussdiagramm sieht wie folgt aus:

3) Der Sentinel-Anführer wird den Slave von niemandem hinrichten Befördern Sie den neuen Master, der im vorherigen Schritt Operation ausgewählt wurde, zum Master-Knoten Degradieren Sie den ursprünglichen Master zum Slave. Wenn die normale Arbeit wieder aufgenommen wird, sendet der Sentinel-Anführer einen Befehl zum Kopieren vom neuen Master. Die oben genannten Failover-Vorgänge werden alle von Sentinel selbst ausgeführt, ohne dass ein manueller Eingriff erforderlich ist.

Das obige ist der detaillierte Inhalt vonBeispielanalyse der Redis-Backup-, Disaster-Recovery- und Hochverfügbarkeitspraxis. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!