Redis-Datenbanken können kleine, kurzlebige und komplexe Objekte speichern, die monatelang bestehen bleiben. Unabhängig von der Komplexität und Größe der Objekte ist die kontinuierliche Verfügbarkeit dieser Daten ein Muss, um dem Kunden einen nahtlosen Back-End-Service zu bieten.Normalerweise ist die Standalone Redis -Installation einfach zu konfigurieren und zu verwenden. Es ist jedoch nicht die beste Option, in einer Umgebung zu verwenden, in der Knotenfehler auftreten können. Die Datendauer der Daten kann mit der AFIS-Funktion (REDIS-Append-Datei) in Redis aufbewahrt werden, ist jedoch nicht die ideale Lösung für die hohe Verfügbarkeit. In ähnlicher Weise können die Redis RDB-Dateien als Sicherungsoption verwendet werden. Beide Optionen befassen sich nicht mit dem Problem plötzlicher Redisknotenfehler.Daher führte Redis mehrere integrierte Funktionen ein, um die hohe Verfügbarkeit von Redis-Datenbanken zu unterstützen, die im folgenden Abschnitt diskutiert wurden.

Datenbankreplikation

Die Datenbankreplikation ist die grundlegende Technik für die Erstellung einer Datenbanksystemfehlertoleranz und kontinuierlich verfügbar. Replikation kopiert Daten aus der Master -Datenbank (primäre Datenbank) in eine oder mehrere Slave -Datenbanken (Replikas), die sicherstellen. Dieser Vorgang ist mit einem automatischen Failover -Prozess verbunden, der einen neuen Master aus den verfügbaren Replikatknoten fördert, wenn der Masterknoten ausfällt.

Eingebaute Redis -Replikation

Redis unterstützte die Replikation von den frühesten Versionen und verbesserte sich immens. Die eigenständige Version unterstützt die grundlegende Replikation mit dem Befehl slaveof, indem ein vorhandener Knoten in einen Slave des primären Datenbankknotens konvertiert wird. Außerdem ermöglicht die Funktion Redis Sentinel die Replikation mit einer erweiterten Failover -Funktion. Darüber hinaus unterstützt der Redis-Cluster eine Reihe von Funktionen mit Hochverfügbarkeitsfunktionen für verteiltere und große Datenbanksysteme.

Grundlegende Redis -Replikation mit Slaveof Command

Eine der grundlegenden Möglichkeiten, um die Redis -Replikation zu erreichen.

Es ist nur einen Schritt davon entfernt, eine Redis -Instanz zum Sklavenknoten zu machen. Die folgende Zeile sollte der Konfigurationsdatei der jeweiligen Instanz hinzugefügt werden:

Slaveof

Anwendungsfall

Das folgende Beispiel zeigt ein Szenario, in dem eine bestimmte Redis -Instanz als Sklavenknoten eines Masterknotens konfiguriert ist, der in der 127 ausgeführt wird.0.0.1 Adresse am 7000 -Port.

Mit dieser Konfiguration kopiert die Master -Datenbank alle Daten in den Slaveknoten, wodurch der Slave eine genaue Kopie des primären Datenbankknotens ist.

Sobald der Meisterknoten mit 127 läuft.0.0.1 und Port 7000, starten wir die andere Instanz, deren Konfigurationsdatei die SlaveOF -Konfiguration enthält. Die neue Instanz wird in Port 7001 ausgeführt.

Die neue Instanz wird erfolgreich gestartet und mit Master -Läufen bei 127 synchronisiert.0.0.1 (Port 7000).

Wenn Sie einige Daten an den Masterknoten schreiben, können diese wie folgt aus dem Sklaven gelesen werden. Es bedeutet, dass Master und Replik ordnungsgemäß synchronisiert wurden.

Das Schreiben von Daten in den Master -Knoten wird wie folgt am Port 7000 ausgeführt.

Das Lesen von Daten aus dem Sklavenknoten wird am Port 7001 ausgeführt, wie im Folgenden dargestellt:

Wenn der Redis -Master fehlschlägt, haben wir bereits eine genaue Kopie der primären Datenbank, die auf Port 7001 ausgeführt wird. In ähnlicher Weise können Sie mehrere Sklaven für einen bestimmten Masterknoten konfigurieren. Der einzige Nachteil in diesem Setup ist, dass Sie sich manuell um den Failover -Prozess kümmern müssen.

Profis

• Einfach und weniger zeitaufwändig zu richten.
• Dieses Setup funktioniert so lange, wie ein einzelner Masterknoten verfügbar ist und auch ohne einen einzelnen Sklavenknoten.
• Möglich, um mit Konfigurationsmanagement -Tools zu automatisieren.

Nachteile

• Der Master -Failover -Prozess ist nicht automatisiert.
• Da die Lesevorgänge asynchron sind, können abgestandene Lesevorgänge auftreten.
• Master- und Sklavenauslastung ist nicht gleich, da die Sharding nicht unterstützt wird.

Hohe Verfügbarkeit mit Redis Sentinel

Redis Sentinel wurde vorgestellt, um sich mit den Nachteilen der vorherigen Lösung zu befassen. Redis Sentinel ist ein verteilt.

Der Sentinel kann einen Sklaven automatisch ohne menschliche Intervention zu einem Masterknoten fördern. Der Master -Failover -Prozess beginnt, wenn die angegebene maximale Anzahl von Sentinel -Knoten (Quorum) zustimmt, dass der Masterknoten nicht erreichbar ist. Die Verfügbarkeit der Sentinelknoten ist also wichtig. Es wird jedoch empfohlen, einen separaten Sentinel -Cluster zu verwenden, um Sentinel -Knoten getrennt von Masterknoten auszuführen. Mit diesem Setup sprechen REDIS -Clients zuerst mit dem Sentinel -Knoten und fragen Sie nach Informationen über den aktuell ausgeführten Masterknoten. Dann arbeiten nur die Kunden mit dem aktuellen Master zusammen.

Es ist möglich, einen Redis -Server im Sentinel -Modus zu starten, wie im folgenden Befehl gezeigt:

Redis-Server --Wächter

Wie in der folgenden Ausgabe gezeigt, wurde der Server im Sentinel -Modus gestartet.

Darüber hinaus können Redis -Sentinels auch mit den Redis -Servern zusammengestellt werden.

Profis

• Automatische Failover -Funktion
• Einfach und weniger zeitaufwändig zu konfigurieren

Nachteile

• Sentinel benötigt einen separaten Cluster, wenn er nicht mit den Redis -Serverknoten zusammenarbeitet
• Die Auslastung der Master- und Slave -Knoten ist aus dem Ausgleich, da keine Sharding -Option verfügbar ist
• Redis Sentinel ist ein verteiltes System und beinhaltet eine beträchtliche Menge an Wartung

Hohe Verfügbarkeit mit Redis -Clustering

Mit den neuesten Redis -Veröffentlichungen wurde dem Redis -Stack eine Clusterkomponente hinzugefügt. Es unterstützt:

• Sharding
• Reproduzieren
• Hohe Verfügbarkeit

Der Redis -Cluster befasst sich also mit verschiedenen Aspekten, die in früheren Lösungen fehlen. Es wurde für große Unternehmen, die eine große Datenmenge generieren und speichern. Da Sharding Ihre Daten unter mehreren Mastern verteilt und jeweils eine Teilmenge des gesamten Schlüsselraums hat. Es gibt Ihnen einen massiven Leistungsschub.

Gleichzeitig ist die Replikation in Redis -Clustern verfügbar, in denen Sie mehrere Slave -Knoten für einen bestimmten Master konfigurieren können. Normalerweise sollte ein Clusterknoten genau eine Redis -Server -Instanz enthalten. Es ist jedoch möglich, die Kreuzreplikation durch Bereitstellen mehrerer Instanzen in einem einzelnen Knoten zu konfigurieren.

Darüber hinaus wird die automatische Failover -Option von den Redis -Clustern bereitgestellt, in denen der Sklavenknoten für einen Master fördert. In einem Cluster -Setup ist das Quorum nicht erforderlich. Das Quorum des Masterknotens ist nur erforderlich, damit der gesamte Cluster ausgeführt werden kann.

Die Redis-Cluster-Lösung kann also als All-in-One-Lösung für diejenigen angesehen werden, die in ihren Anwendungen nach Sharding, Replikation und hoher Verfügbarkeit suchen.

Profis

• Unterstützt Sharding, der beim Abfragen von Redis -Datenspeichern einen Leistungsschub verleiht.
• Bietet eine automatische Failover -Lösung
• Master-Replica-Unterstützung

Nachteile

• Die Aufrechterhaltung eines Cluster kann eine beträchtliche Menge an Arbeit sein
• Mangel an Bibliotheksunterstützung

Abschluss

Redis unterstützt eine hohe Verfügbarkeit mit eigenständigem Redis, Redis-Sentinel-Modell und eingebauter Clusterkomponente. Alle drei Lösungen haben ihre Vor- und Nachteile wie oben erläutert. Insgesamt ist Redis Sentinel die Option, wenn Sie nur nach hoher Verfügbarkeit suchen und sich nicht um die Leistung kümmern. Wenn Sie jedoch nach einem Gleichgewicht zwischen Leistung und hoher Verfügbarkeit mit Kreuzreplikation suchen, ist der Redis-Cluster unter allen drei die besten.