Im Allgemeinen gibt es 5 Arten von Redis-Clustern:
1, Master-Slave-Replikation
2, Sentinel-Modus
3, Cluster offiziell bereitgestellt durch den Redis-Cluster-Modus (Server)
4, Jedis-Sharding-Cluster (Client-Sharding)
5, unter Verwendung von Middleware-Agenten wie Wandoujias Codis usw.
Nachdem wir ihre Modelle vorgestellt haben, analysieren wir ihre Prinzipien:
Master-Slave-Replikation:
Wie die Master-Slave-Replikation funktioniert: Nachdem der Slave-Slave-Knotendienst gestartet und eine Verbindung zum Master hergestellt wurde, sendet er aktiv einen SYNC-Befehl. Nach Erhalt des Synchronisierungsbefehls startet der Master-Dienst-Masterknoten den Hintergrundspeichervorgang und sammelt alle empfangenen Befehle zum Ändern des Datensatzes. Nach Abschluss des Hintergrundvorgangs überträgt der Master die gesamte Datenbankdatei an den Slave, um einen vollständigen Vorgang abzuschließen Synchronisation. Der Slave-Slave-Knotendienst speichert und lädt die Datenbankdateidaten nach dem Empfang in den Speicher. Danach überträgt der Master-Knoten weiterhin alle gesammelten Änderungsbefehle und neuen Änderungsbefehle nacheinander an die Slaves. Die Slaves führen diese Datenänderungsbefehle dieses Mal aus, um eine endgültige Datensynchronisierung zu erreichen.
Wenn die Verbindung zwischen Master und Slave getrennt wird, kann sich der Slave automatisch wieder mit dem Master verbinden. Nach erfolgreicher Verbindung wird jedoch automatisch eine vollständige Synchronisierung durchgeführt.
Master-Slave-Replikationskonfiguration
Ändern Sie die Konfigurationsdatei des Slave-Knotens: Slaveof Masterip Masterport
Wenn ein Passwort festgelegt ist, legen Sie es fest: Masterauth-Master-Passwort
Sentinel-Modus:
Dieser Modus wird ab Redis-Version 2.6 bereitgestellt, aber der Modus dieser Version war zu diesem Zeitpunkt bis Redis-Version 2.8 instabil Später wurde der Sentinel-Modus stabil, unabhängig davon, ob es sich um den Master-Slave-Modus oder den Sentinel-Modus handelt. Sie können nicht horizontal erweitert werden, und die Hochverfügbarkeitsfunktionen dieser beiden Modi werden durch den Speicher begrenzt Masterknoten.
Der Sentinel-Prozess wird verwendet, um den Arbeitsstatus des Master-Servers im Redis-Cluster zu überwachen. Wenn der Master-Server ausfällt, können der Master- und der Slave-Server gewechselt werden, um eine hohe Verfügbarkeit des Systems sicherzustellen.
Die Rolle des Sentinel-Prozesses
Überwachung: Sentinel überprüft ständig, ob Ihr Master und Slave normal funktionieren.
Benachrichtigung: Wenn ein Problem mit einem überwachten Redis-Knoten auftritt, kann der Sentinel über die API Benachrichtigungen an den Administrator oder andere Anwendungen senden.
Automatisches Failover: Wenn ein Master nicht ordnungsgemäß funktioniert, startet Sentinel einen automatischen Failover-Vorgang. Dabei wird einer der Slaves des ausgefallenen Masters auf einen neuen Master aktualisiert und die anderen Slaves des ausgefallenen Masters können kopiert werden der neue Master; wenn der Client versucht, eine Verbindung zum ausgefallenen Master herzustellen, gibt der Cluster auch die Adresse des neuen Masters an den Client zurück, sodass der Cluster den aktuellen Master verwenden kann, um den ausgefallenen Master zu ersetzen. Nachdem der Master- und der Slave-Server gewechselt wurden, ändern sich die Inhalte der Konfigurationsdateien redis.conf, redis.conf und sentinel.conf des Masters entsprechend, d. h. es gibt eine zusätzliche Zeile „slaveof“ in der redis.conf-Konfiguration des Masters Konfiguration wird das Überwachungsziel von sentinel.conf entsprechend geändert.
So funktioniert der Sentinel-Prozess
Jeder Sentinel-Prozess sendet einmal pro Sekunde Nachrichten an den Master-Server und den Slave-Server im gesamten Cluster und andere Sentinel-Prozesse.
Wenn die Zeit seit der letzten gültigen Antwort auf den PING-Befehl den durch die Option down-after-milliseconds angegebenen Wert überschreitet, wird die Instanz vom Sentinel-Prozess als subjektiv offline (SDOWN) markiert)
Wenn ein Master-Server als subjektiv offline (SDOWN) markiert ist, müssen alle Sentinel-Prozesse, die den Master-Server überwachen, einmal pro Sekunde bestätigen, dass der Master-Server tatsächlich in den subjektiven Offline-Status eingetreten ist.
Wenn a Eine ausreichende Anzahl von Sentinel-Prozessen (größer oder gleich dem in der Konfigurationsdatei angegebenen Wert) bestätigen, dass der Master-Server innerhalb des angegebenen Zeitraums in den subjektiven Offline-Status (SDOWN) eingetreten ist. Anschließend wird der Master-Server als objektiv offline markiert ( ODOWN)
Unter normalen Umständen benachrichtigt jeder Sentinel-Prozess alle Master-Server und Slave-Slaves im Cluster einmal alle 10 Sekunden. Der Server sendet einen INFO-Befehl.
Wenn der Master-Server vom Sentinel-Prozess als objektiv offline (ODOWN) markiert wird, ändert sich die Häufigkeit, mit der der Sentinel-Prozess INFO-Befehle an alle Slave-Slave-Server des Offline-Master-Servers sendet, von einmal alle 10 Sekunden bis einmal pro Sekunde.
Wenn nicht genügend Sentinel-Prozesse vorhanden sind, um zuzustimmen, dass der Master-Server offline geht, wird der objektive Offline-Status des Master-Servers entfernt. Wenn der Master-Server den PING-Befehl erneut an den Sentinel-Prozess sendet und eine gültige Antwort zurückgibt, wird der subjektive Offline-Status des Master-Servers entfernt.
Offizieller Redis-Cluster-Modus
Redis Cluster ist eine Server-Sharding-Technologie, die seit Version 3.0 offiziell verfügbar ist.
In diesem Bild stellt jeder blaue Kreis einen Redis-Serverknoten dar. Jeweils zwei ihrer Knoten sind miteinander verbunden. Der Client kann sich mit jedem Knoten verbinden und dann auf jeden Knoten im Cluster zugreifen. Führen Sie darauf Zugriffe und andere Vorgänge durch.
Redis-Cluster-Daten-Sharding
Auf jedem Knoten von Redis gibt es zwei Dinge, eines ist der Slot, der als A-Variable verstanden werden kann, die zwei speichern kann Werte. Der Wertebereich dieser Variablen ist: 0-16383. Ein anderes ist Cluster. Ich persönlich verstehe diesen Cluster als Cluster-Management-Plug-in. Wenn unser Zugriffsschlüssel eintrifft, erhält Redis ein Ergebnis basierend auf dem crc16-Algorithmus und berechnet dann den Rest des Ergebnisses auf 16384, sodass jeder Schlüssel einem Hash-Slot mit einer Nummer zwischen 0 und 16383 entspricht Dieser Wert wird verwendet Suchen Sie den Knoten, der dem entsprechenden Steckplatz entspricht, und springen Sie dann automatisch direkt zum entsprechenden Knoten, um Zugriffsvorgänge durchzuführen.
Jedis-Sharding-Cluster
Man kann sagen, dass Redis-Sharding eine in der Branche übliche Methode war, bevor der Redis-Cluster auf den Markt kam. Seine Hauptidee ist die Verwendung von Hash Algorithmus zum Speichern des Schlüssels der Daten, sodass ein bestimmter Schlüssel einem bestimmten Knoten zugewiesen wird.
Glücklicherweise unterstützt der Java Redis-Client-Treiber Jedis bereits die Redis Sharding-Funktion, nämlich ShardedJedis und ShardedJedisPool in Kombination mit dem Cache-Pool
Die Redis Sharding-Implementierung von Jedis weist die folgenden Merkmale auf:
Verwenden Sie einen konsistenten Hash-Algorithmus, um den Schlüssel und den Knotennamen gleichzeitig zu hashen, und führen Sie dann einen Zuordnungsabgleich durch. Der verwendete Algorithmus ist MURMUR_HASH. Der Hauptgrund für die Verwendung von konsistentem Hashing anstelle einer einfachen Hash-ähnlichen Modulo-Zuordnung besteht darin, dass beim Hinzufügen oder Entfernen von Knoten kein erneutes Hashing aufgrund eines erneuten Abgleichs auftritt. Konsistentes Hashing wirkt sich nur auf die Schlüsselzuweisung benachbarter Knoten aus und die Auswirkung ist gering.
Um zu vermeiden, dass konsistentes Hashing nur benachbarte Knoten betrifft und einen Knotenzuweisungsdruck verursacht, virtualisiert ShardedJedis 160 virtuelle Knoten entsprechend dem Namen jedes Redis-Knotens (andernfalls weist Jedis einen Standardnamen zu). Je nach Gewicht können auch 160-fache virtuelle Knoten virtualisiert werden. Durch die Verwendung virtueller Knoten für den Mapping-Abgleich können Schlüssel beim Hinzufügen oder Reduzieren von Redis-Knoten verschoben und gleichmäßiger auf Redis-Knoten verteilt werden, anstatt dass nur benachbarte Knoten betroffen sind.
ShardedJedis unterstützt den KeyTagPattern-Modus, bei dem ein Teil des KeyTags für das Sharding extrahiert wird. Auf diese Weise kann durch entsprechende Benennung des Schlüssels eine Gruppe verwandter Schlüssel im selben Redis-Knoten abgelegt werden, wodurch ein Zugriff vermieden wird Zugehörige Daten über Knoten hinweg. Sehr wichtig.
Middleware-Agent verwenden
Die Rolle der Middleware besteht darin, den Schlüssel der Daten, die wir in Redis speichern müssen, mithilfe einer Reihe von Algorithmen zu berechnen, um einen Wert zu berechnen. Suchen Sie dann anhand dieses Werts den entsprechenden Redis-Knoten und speichern Sie die Daten in diesem Redis-Knoten.
Zu den häufig verwendeten Middlewares gehören die folgenden:
Twemproxy
Codis
nginx
Das obige ist der detaillierte Inhalt vonWas sind die Clustermodi von Redis?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
