Die Menge an Redis-Daten nimmt von Tag zu Tag zu und immer mehr Unternehmen verwenden sie nicht nur zum Zwischenspeichern, sondern neigen auch dazu, sie zu speichern Ich fördere die Entwicklung von Clustern und sammle auch für mich geeignete Cluster-Lösungen. Die meisten von ihnen verwenden Sharding-Technologie, um eine Reihe von Problemen zu lösen, die durch die Zunahme einzelner Instanzen verursacht werden Erinnerung.
In diesem Artikel werden fünf Lösungen kurz vorgestellt:
Offizielle Clusterlösung
Twemproxy-Proxy-Lösung
Sentinel-Modus
Codis
Client-Sharding
Offizielle Clusterlösung
Ab Redis-Version 3.0 wird der Redis-Cluster mit einer zentrierten Struktur unterstützt. Jeder Knoten speichert Daten und den gesamten Clusterstatus, und jeder Knoten ist mit anderen Knoten verbunden. Redis-Cluster ist eine serverseitige Sharding-Technologie.
Redis-Cluster-Architekturdiagramm
Redis-Cluster-Funktionen:
Jeder Knoten kommuniziert mit n-1 Knoten, so heißt es ein Clusterbus. Sie verwenden eine spezielle Portnummer, die der externen Service-Portnummer plus 10000 entspricht. Daher ist es notwendig, die Informationen jedes Knotens in diesem Cluster zu verwalten, da sonst der gesamte Cluster nicht verfügbar ist. Intern wird ein spezielles Binärprotokoll verwendet, um die Übertragungsgeschwindigkeit und Bandbreite zu optimieren.
redis-cluster ordnet alle physischen Knoten dem [0,16383] Steckplatz (Slot) zu, und der Cluster ist für die Aufrechterhaltung des Knoten--Slot--Werts verantwortlich.
Der Cluster ist vorab in 16384 Buckets unterteilt. Wenn Daten in den Redis-Cluster eingefügt werden müssen, wird anhand des Werts von CRC16(KEY) Mod 16384 entschieden, in welchem Bucket ein Schlüssel platziert werden soll.
Der Client ist direkt mit dem Redis-Knoten verbunden. Es ist nicht erforderlich, eine Verbindung zu allen Knoten im Cluster herzustellen, sondern einfach eine Verbindung zu einem beliebigen verfügbaren Knoten im Cluster.
Das Skript redis-trib.rb (Rub-Sprache) ist ein Cluster-Management-Tool, das beispielsweise das automatische Hinzufügen von Knoten, das Planen von Slots, das Migrieren von Daten und eine Reihe von Vorgängen ermöglicht.
Der Ausfall eines Knotens wird erst dann wirksam, wenn mehr als die Hälfte der Knoten im Cluster einen Ausfall erkennen.
Der gesamte Cluster wird als Ganzes betrachtet. Wenn der vom Client betätigte Schlüssel nicht auf dem Knoten zugewiesen ist, gibt Redis eine Lenkanweisung zurück, um auf den richtigen Knoten zu verweisen Knoten.
Um die Zugänglichkeit des Clusters zu erhöhen, besteht die offiziell empfohlene Lösung darin, den Knoten in einer Master-Slave-Struktur zu konfigurieren, d. h. einem Master-Knoten und n Slave-Knoten. Wenn der Master-Knoten ausfällt, wählt der Redis-Cluster basierend auf dem Wahlalgorithmus einen der Slave-Knoten aus, der zum Master-Knoten befördert werden soll, und der gesamte Cluster stellt weiterhin Dienste für die Außenwelt bereit.
Twemproxy-Proxy-Lösung
Twemproxy-Proxy-Architekturdiagramm:
Redis-Proxy-Middleware Twemproxy ist eine Art Sharding, das Middleware-Technologie nutzt. Twemproxy befindet sich zwischen dem Client und dem Server. Es verarbeitet die Anfrage des Clients (Sharding) und leitet sie dann an den echten Redis-Server am Backend weiter. Mit anderen Worten: Der Client greift nicht direkt auf den Redis-Server zu, sondern indirekt über die Twemproxy-Proxy-Middleware. Reduziert die Anzahl direkter Clientverbindungen zu Back-End-Servern und unterstützt die horizontale Erweiterung von Serverclustern.
Die interne Verarbeitung der Twemproxy-Middleware ist zustandslos und kann leicht selbst geclustert werden, wodurch einzelne Stress- oder Fehlerpunkte vermieden werden.
Twemproxy, auch bekannt als Nussknacker, entstand aus dem Lightweight-Proxy von Redis und Memcached-Clustern im Twitter-System.
Github-Quellcode-Adresse (https://github.com/twitter/twemproxy)
Wie Sie dem Architekturdiagramm oben entnehmen können, ist twemproxy ein einzelner Punkt, der leicht eingefügt werden kann Daher wird normalerweise Keepalived verwendet, um eine hohe Verfügbarkeit von Twemproy zu erreichen. Zu diesem Zeitpunkt arbeitet normalerweise nur ein Twemproxy und der andere befindet sich im Standby-Modus. Wenn einer auflegt, wechselt VIP automatisch und der Standby-Rechner übernimmt die Arbeit. Bezüglich der Verwendung von keepalived können Sie die Informationen online einsehen.
Sentinel-Modus
Sentinel Sentinel
Sentinel ist eine Hochverfügbarkeitslösung für Redis: Ein Sentinel-System bestehend aus einer oder mehreren Sentinel-Instanzen kann eine beliebige Anzahl von Master-Servern überwachen und alle Slave-Server unter diesen Master-Servern. Wenn der überwachte Master-Server offline geht, wird automatisch ein Slave-Server unter dem Offline-Master-Server auf einen neuen Master-Server aktualisiert.
Zum Beispiel:
Nachdem Server1 offline geht:
Aktualisieren Sie Server2 als neuen Master Server:
Funktionsweise von Sentinel
Jeder Sentinel sendet einmal pro Sekunde Nachrichten an den Master, Slave und andere Sentinel-Instanzen, die er kennt. Ein PING-Befehl.
Wenn die Zeit seit der letzten gültigen Antwort auf den PING-Befehl für eine Instanz den durch die Option down-after-milliseconds angegebenen Wert überschreitet, wird die Instanz von Sentinel als subjektiv offline markiert.
Wenn ein Master als subjektiv offline markiert ist, müssen alle Sentinels, die den Master überwachen, einmal pro Sekunde bestätigen, dass der Master tatsächlich in den subjektiven Offline-Status übergegangen ist.
Wenn eine ausreichende Anzahl von Sentinels (größer oder gleich dem in der Konfigurationsdatei angegebenen Wert) bestätigt, dass der Master innerhalb des angegebenen Zeitraums tatsächlich in einen subjektiven Offline-Zustand eingetreten ist, wird der Master als objektiv markiert offline.
Unter normalen Umständen sendet jeder Sentinel alle 10 Sekunden INFO-Befehle an alle ihm bekannten Master und Slaves.
Wenn der Master von Sentinel als objektiv offline markiert wird, wird die Häufigkeit, mit der Sentinel INFO-Befehle an alle Slaves des Offline-Masters sendet, von einmal alle 10 Sekunden auf einmal pro Sekunde geändert.
Wenn nicht genügend Sentinels zustimmen, dass der Meister offline war, wird der Offline-Status des Ziels des Meisters entfernt. Wenn der Master erneut einen gültigen Wert an den PING-Befehl von Sentinel zurückgibt, wird der subjektive Offline-Status des Masters entfernt.
codis
codis ist eine verteilte Redis-Lösung, Open Source von Wandoujia. Für Anwendungen der oberen Ebene gibt es keinen offensichtlichen Unterschied zwischen der Verbindung zum Codis-Proxy und der Verbindung zum nativen Redis-Server Oberschicht Die Anwendung kann wie ein eigenständiges Redis verwendet werden. Die unterste Schicht von Codis übernimmt die Weiterleitung von Anforderungen, die ununterbrochene Datenmigration usw. Alle nachfolgenden Dinge sind für den vorherigen Client transparent dass die Verbindung dahinter ein Redis-Dienst mit unbegrenztem Speicher ist.
Clientseitiges Sharding
Die Logik der Partitionierung wird auf der Clientseite implementiert und der Client wählt aus, welchen Knoten er anfordern möchte. Die Lösung kann sich auf konsistentes Hashing beziehen. Diese Lösung eignet sich normalerweise für Szenarien, in denen der Benutzer die vollständige Kontrolle über das Verhalten des Clients hat.
Zusammenfassung: Es gibt keine beste Lösung, nur die am besten geeignete Lösung.
Weitere technische Artikel zum Thema Redis finden Sie in der Spalte Redis-Tutorial, um mehr darüber zu erfahren!
Das obige ist der detaillierte Inhalt vonWas sind die Redis-Cluster-Lösungen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
