Heim  >  Artikel  >  Datenbank  >  Einführung in den Redis-Cluster-Cluster

Einführung in den Redis-Cluster-Cluster

尚
nach vorne
2020-05-18 09:06:301885Durchsuche

Im Gegensatz zum Master-Salve- oder Sentinel-Modus besteht der größte Unterschied zwischen Cluster und ihnen darin, dass es sich bei den ersten beiden um Vollspeicher handelt, der viel Speicher verbraucht und einen Fasseffekt hat, während der Cluster-Cluster verteilter Speicher ist , jeder Redis speichert unterschiedliche Inhalte.

Einführung in den Redis-Cluster-Cluster

redis-cluster ist so konzipiert, dass insgesamt 16384 Hash-Slots verfügbar sind, und jedem Master wird ein Teil des Slots zugewiesen. Der Verteilungsalgorithmus ist: [hash_slot = crc16 (key) mod 16384] Wenn {} vorhanden ist, nehmen Sie den verfügbaren Schlüssel von {}, andernfalls kann der gesamte Schlüssel verfügbar sein. Der Cluster muss mindestens 3 Master und 3 Slaves haben und jede Instanz verwendet eine andere Konfigurationsdatei.

Einführung in den Redis-Cluster-Cluster

  1. Alle Redis-Knoten sind miteinander verbunden (PING-PONG-Mechanismus) und verwenden intern Binärprotokolle, um Übertragungsgeschwindigkeit und Bandbreite zu optimieren.

  2. Der Ausfall eines Knotens wird erst dann wirksam, wenn mehr als die Hälfte der Knoten im Cluster einen Ausfall erkennen.

  3. Der Client ist direkt mit dem Redis-Knoten verbunden, ohne dass eine Zwischen-Proxy-Schicht erforderlich ist. Der Client muss sich nicht mit allen Knoten im Cluster verbinden, sondern nur mit allen verfügbaren Knoten im Cluster.

  4. redis-cluster ordnet alle physischen Knoten dem Slot [0-16383] zu, und der Cluster ist für die Aufrechterhaltung des NodeslotWerts verantwortlich

Redis-Cluster-Voting: Fehlertoleranz

1. Der Abstimmungsprozess bezieht alle Master im Cluster ein. Wenn mehr als die Hälfte der Master-Knoten mit dem Master-Knoten kommunizieren (Cluster-Knoten). Timeout), der aktuelle Master wird berücksichtigt. Der Knoten hängt.

2. Wann wird der gesamte Cluster nicht mehr verfügbar (cluster_state:fail)?

Wenn ein Master im Cluster aufhängt und der Der aktuelle Master hat keinen Slave und der Cluster wechselt in den Fehlerzustand. Es versteht sich, dass er in den Fehlerzustand wechselt, wenn die Steckplatzzuordnung [0-16383] des Clusters unvollständig ist. 3.0.0.rc1 fügt den Parameter „Cluster-require-full-coverage“ hinzu, der standardmäßig geschlossen ist, und öffnet den Cluster-Kompatibilitätsteil nicht

Wenn mehr als die Hälfte der Master im Cluster aussterben Unabhängig davon, ob Slaves vorhanden sind oder nicht, wechselt der Cluster in den Fehlerzustand.

In der Redis-Cluster-Architektur wird der Redis-Master-Knoten im Allgemeinen zum Empfangen von Lese- und Schreibvorgängen verwendet, während der Redis-Slave-Knoten im Allgemeinen nur für die Sicherung verwendet wird. Er verfügt über denselben Steckplatzsatz wie der entsprechende Master Wenn ein Redis-Master unerwartet ausfällt, wird der entsprechende Slave zu einem temporären Redis-Master aktualisiert.

In der offiziellen Redis-Dokumentation gibt es diese Beschreibung der Redis-Cluster-Architektur: In der Cluster-Architektur wird Redis-Master standardmäßig im Allgemeinen zum Empfangen von Lese- und Schreibvorgängen verwendet, während Redis-Slave dies verwendet Backup: Wenn eine Anfrage an den Slave gestellt wird, wird diese direkt an den Master weitergeleitet, wo sich der entsprechende Schlüssel zur Verarbeitung befindet.

Aber wenn es Ihnen nichts ausmacht, möglicherweise abgelaufene Daten im Redis-Cluster zu lesen, und Sie nicht an Schreibanforderungen interessiert sind, können Sie den Slave auch über den Befehl readonly auf lesbar setzen und dann die relevanten Informationen über den Befehl abrufen Slave-Schlüssel, um eine Lese-/Schreibtrennung zu erreichen.

Weitere Redis-Kenntnisse finden Sie in der Spalte

Redis-Einführungs-Tutorial

.

Das obige ist der detaillierte Inhalt vonEinführung in den Redis-Cluster-Cluster. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Dieser Artikel ist reproduziert unter:oschina.net. Bei Verstößen wenden Sie sich bitte an admin@php.cn löschen