Technologieaustausch

7.11-tägiger Lern-Check-in – Anfänger-Lernen Redis (6)

2024-07-12

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

7.11 Check-in für das Tagesstudium

Fügen Sie hier eine Bildbeschreibung ein

1. Redis-Transaktion

Das Konzept von Transaktionen und ACID-Eigenschaften

Fügen Sie hier eine Bildbeschreibung ein
Transaktionen auf Datenbankebene

Auf Datenbankebene ist eine Transaktion eine Reihe von Vorgängen, die entweder alle erfolgreich ausgeführt werden oder keiner von ihnen ausgeführt wird.

Vier Hauptmerkmale von Datenbanktransaktionen

  • A: Atomic, Atomicity, führt alle SQL-Anweisungen als atomare Arbeitseinheiten aus. Entweder werden alle ausgeführt oder keine davon.
  • C: Konsistent, nach Abschluss der Transaktion ist der Status aller Daten konsistent, dh solange 100 von Konto A abgezogen werden, werden 100 zu Konto B hinzugefügt;
  • I: Isolation: Wenn mehrere Transaktionen gleichzeitig ausgeführt werden, müssen die von jeder Transaktion vorgenommenen Änderungen von anderen Transaktionen isoliert werden.
  • D: Dauer, Persistenz, dh nach Abschluss der Transaktion werden die Änderungen an den Datenbankdaten dauerhaft gespeichert.

Redis-Transaktion

Eine Redis-Transaktion ist eine Reihe von Befehlen, die serialisiert werden und eine Reihe von Befehlen einmalig, sequentiell und exklusiv ausgeführt werden.

Fügen Sie hier eine Bildbeschreibung ein

Drei Hauptmerkmale von Redis-Transaktionen

  • separate Quarantäneoperationen : Alle Befehle in der Transaktion werden serialisiert und der Reihe nach ausgeführt. Während der Ausführung der Transaktion wird diese nicht durch Befehlsanfragen anderer Clients unterbrochen;
  • Kein Konzept der Isolationsstufe: Die Befehle in der Warteschlange werden erst dann tatsächlich ausgeführt, wenn sie übermittelt werden, da vor der Übermittlung der Transaktion keine Anweisungen tatsächlich ausgeführt werden. Daher gibt es keine „Abfrage innerhalb der Transaktion, um die Aktualisierungen in der Transaktion anzuzeigen, und keine Abfrage außerhalb der Transaktion.“ Transaktion „Kann nicht angezeigt“ werden.
  • Keine Garantie für Atomizität: Wenn die Ausführung eines Befehls in derselben Redis-Transaktion fehlschlägt, werden nachfolgende Befehle weiterhin ohne Rollback ausgeführt.

Drei Phasen der Redis-Transaktionsausführung

Fügen Sie hier eine Bildbeschreibung ein

  • anmachen:vonMULTIStarten Sie eine Transaktion.
  • Tritt dem Team bei: Mehrere Befehle in eine Transaktion einreihen. Diese Befehle werden nicht sofort nach dem Empfang ausgeführt, sondern in die Transaktionswarteschlange gestellt und auf ihre Ausführung gewartet.
  • implementieren:Darauf ankommenEXECDer Befehl löst die Transaktion aus;

Grundlegende Operationen von Redis-Transaktionen

Fügen Sie hier eine Bildbeschreibung ein
Multi, Ausführen, Verwerfen

Transaktionseingabe vonMultiWenn der Befehl startet, werden die eingegebenen Befehle einzeln in die Befehlspufferwarteschlange verschoben und erst dann ausgeführtExec Anschließend führt Redis die Befehle in der vorherigen Befehlspufferwarteschlange nacheinander aus.Während des Teambildungsprozesses können Sie passendiscardKomm, gib das Team auf.

Beispiel

127.0.0.1:6379> set t1 1
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set id 12
QUEUED
127.0.0.1:6379(TX)> get id
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> get t1
QUEUED
127.0.0.1:6379(TX)> EXEC
1) OK
2) "12"
3) (integer) 2
4) (integer) 3
5) "3"
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20

Transaktion abbrechen

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set name z3
QUEUED
127.0.0.1:6379(TX)> set age 29
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> DISCARD
OK
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

Alle sitzen zusammen

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set name z3
QUEUED
127.0.0.1:6379(TX)> get name
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> get t1
QUEUED
127.0.0.1:6379(TX)> set email
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379(TX)> exec
(error) EXECABORT Transaction discarded because of previous errors.
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14

Beachten
Der Befehlssatz enthält falsche Anweisungen (beachten Sie, dass es sich um Syntaxfehler handelt). Sie sind alle miteinander verbunden und schlagen alle fehl.

Jede Ungerechtigkeit hat ihren Besitzer, jede Schuld hat ihren Besitzer

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set age 11
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> set email [email protected]
QUEUED
127.0.0.1:6379(TX)> incr email
QUEUED
127.0.0.1:6379(TX)> get age
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) (integer) 5
3) OK
4) (error) ERR value is not an integer or out of range
5) "11"
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18

Beachten
Bei Laufzeitfehlern, also nicht grammatikalischen Fehlern, werden korrekte Befehle ausgeführt und falsche Befehle geben einen Fehler zurück.

2. Redis-Cluster

Master-Slave-Replikation

Fügen Sie hier eine Bildbeschreibung ein
Überblick
Unter den bestehenden Unternehmen nutzen 80 % der Unternehmen hauptsächlich eigenständige Redis-Dienste. In tatsächlichen Szenarien ist Redis auf einem einzelnen Knoten anfällig für Risiken.

vor Problemen stehen:

  • Fehlfunktion der Maschine. Wir stellen es auf einem Redis-Server bereit. Wenn ein Maschinenausfall auftritt, müssen wir auf einen anderen Server migrieren und sicherstellen, dass die Daten synchronisiert sind.
  • Kapazitätsengpass. Wenn wir den Redis-Speicher von 16G auf 64G erweitern müssen, wird eine einzelne Maschine dies definitiv nicht erfüllen können. Natürlich können Sie eine neue 128G-Maschine kaufen.

Lösung

Um eine größere Speicherkapazität der verteilten Datenbank zu erreichen und einem hohen gleichzeitigen Zugriff standzuhalten, werden wir die Daten der ursprünglichen zentralisierten Datenbank auf mehreren anderen Netzwerkknoten speichern.

Beachten
Um dieses Einzelknotenproblem zu lösen, wird Redis auch mehrere Kopien von Daten zur Replikation auf anderen Knoten bereitstellen, um eine hohe Verfügbarkeit von Redis und eine redundante Datensicherung zu erreichen, um eine hohe Verfügbarkeit von Daten und Diensten sicherzustellen.

Was ist Master-Slave-Replikation?

Unter Master-Slave-Replikation versteht man das Kopieren von Daten von einem Redis-Server auf andere Redis-Server. Ersterer wird als Master-Knoten bezeichnet, letzterer als Slave-Knoten. Die Datenreplikation erfolgt in eine Richtung und kann nur vom Master-Knoten zum Slave-Knoten erfolgen.

Fügen Sie hier eine Bildbeschreibung ein
Die Rolle der Master-Slave-Replikation

  • Daten Redundanz: Die Master-Slave-Replikation implementiert eine Hot-Sicherung von Daten, die zusätzlich zur Persistenz eine Datenredundanzmethode darstellt.
  • Erholung: Wenn auf dem Master-Knoten ein Problem auftritt, kann der Slave-Knoten Dienste bereitstellen, um eine schnelle Fehlerbehebung zu erreichen. Dies ist eigentlich eine Art Dienstredundanz.
  • Lastverteilung: Auf der Grundlage der Master-Slave-Replikation mit der Trennung von Lesen und Schreiben kann der Master-Knoten Schreibdienste und die Slave-Knoten Lesedienste bereitstellen (d. h. beim Schreiben von Redis-Daten sollte die Anwendung eine Verbindung zum Master-Knoten herstellen). , und beim Lesen von Redis-Daten sollte die Anwendung eine Verbindung zum Slave-Knoten herstellen), insbesondere in Szenarien, in denen weniger geschrieben und mehr gelesen wird, kann die Aufteilung der Leselast über mehrere Slave-Knoten die Parallelität des Redis-Servers erheblich erhöhen .
  • Grundstein für hohe Verfügbarkeit: Zusätzlich zu den oben genannten Funktionen ist die Master-Slave-Replikation auch die Grundlage für die Implementierung von Sentinels und Clustern. Daher ist die Master-Slave-Replikation die Grundlage für die hohe Verfügbarkeit von Redis.

Einrichtung der Master-Slave-Replikationsumgebung

Fügen Sie hier eine Bildbeschreibung ein
Konfigurationsdatei schreiben
Erstellen Sie eine neue redis6379.conf

include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb
  • 1
  • 2
  • 3
  • 4

Erstellen Sie eine neue redis6380.conf

include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb
  • 1
  • 2
  • 3
  • 4

Erstellen Sie eine neue redis6381.conf

include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6381.pid
port 6381
dbfilename dump6381.rdb
  • 1
  • 2
  • 3
  • 4

Starten Sie drei Redis-Server

./redis-server ../redis6379.conf
./redis-server ../redis6380.conf
./redis-server ../redis6381.conf
  • 1
  • 2
  • 3

Systemprozesse anzeigen

[root@localhost src]# ps -ef |grep redis
root    40737    1  0 22:05 ?     00:00:00 ./redis-server *:6379
root    40743    1  0 22:05 ?     00:00:00 ./redis-server *:6380
root    40750    1  0 22:05 ?     00:00:00 ./redis-server *:6381
root    40758  40631  0 22:05 pts/0   00:00:00 grep --color=auto redis
  • 1
  • 2
  • 3
  • 4
  • 5

Überprüfen Sie den Betriebsstatus von drei Hosts

#打印主从复制的相关信息
./redis-cli -p 6379
./redis-cli -p 6380
./redis-cli -p 6381
127.0.0.1:6379> info replication
127.0.0.1:6380> info replication
127.0.0.1:6381> info replication
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

Ausgestattet mit Slave-Datenbank, aber nicht mit Master-Datenbank

Syntaxformat:

slaveof  <ip> <port>
  • 1

Beispiel:

Ausgeführt am 6380 und 6381.

127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
OK
  • 1
  • 2

Schreiben Sie auf dem Host und lesen Sie Daten auf dem Slave

set k1 v1
  • 1

Analyse des Prinzips der Master-Slave-Replikation

Fügen Sie hier eine Bildbeschreibung ein
Die Master-Slave-Replikation kann in drei Phasen unterteilt werden

  • Verbindungsaufbauphase (d. h. Vorbereitungsphase)
  • Phase der Datensynchronisierung
  • Befehlsweitergabephase

Der Kopiervorgang ist grob in 6 Vorgänge unterteilt

Fügen Sie hier eine Bildbeschreibung ein

  1. Speichern Sie die Informationen zum Masterknoten (Master).
    Statusinformationen nach der Ausführung von „slaveof“ anzeigen
info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  1. Der Slave-Knoten (Slave) verwaltet die replikationsbezogene Logik durch geplante Aufgaben, die jede Sekunde ausgeführt werden. Wenn die geplante Aufgabe erkennt, dass es einen neuen Master-Knoten gibt, versucht sie, eine Netzwerkverbindung mit dem Knoten herzustellen.
    Fügen Sie hier eine Bildbeschreibung ein
  2. Stellen Sie eine Netzwerkverbindung zwischen dem Slave-Knoten und dem Master-Knoten her
    Der Slave-Knoten richtet einen Socket mit Port 51234 ein, der speziell zum Empfangen der vom Master-Knoten gesendeten Replikationsbefehle verwendet wird.

Fügen Sie hier eine Bildbeschreibung ein
4. Senden Sie den Ping-Befehl

Nachdem die Verbindung erfolgreich hergestellt wurde, sendet der Slave-Knoten eine Ping-Anfrage für die erste Kommunikation.

Fügen Sie hier eine Bildbeschreibung ein

Wirkung:

  • Ermitteln Sie, ob der Netzwerk-Socket zwischen Master und Slave verfügbar ist.
  • Ermitteln Sie, ob der Masterknoten derzeit Befehle annehmen kann
  1. ASD.
    Wenn der Parameter „requirepass“ auf dem Master-Knoten festgelegt ist, ist eine Kennwortüberprüfung erforderlich. Der Slave-Knoten muss den Parameter „masterauth“ konfigurieren, um sicherzustellen, dass das Kennwort mit dem des Master-Knotens übereinstimmt, damit die Überprüfung fehlschlägt beendet und der Slave-Knoten startet den Replikationsprozess erneut.

  2. Datensätze synchronisieren.
    Nachdem die Master-Slave-Replikationsverbindung normal kommuniziert hat, sendet der Master-Knoten beim ersten Aufbau der Replikation alle Daten, die er enthält, an den Slave-Knoten. Dieser Teil des Vorgangs ist der längste Schritt.
    Fügen Sie hier eine Bildbeschreibung ein

Master-Slave-Synchronisationsstrategie

Wenn Master und Slave gerade verbunden sind, wird eine vollständige Synchronisierung durchgeführt. Nach Abschluss der vollständigen Synchronisierung wird eine inkrementelle Synchronisierung durchgeführt. Selbstverständlich kann der Slave bei Bedarf jederzeit eine vollständige Synchronisierung einleiten. Die Redis-Strategie besteht darin, dass, egal was passiert, zuerst eine inkrementelle Synchronisierung versucht wird, und wenn dies nicht gelingt, muss die Slave-Maschine eine vollständige Synchronisierung durchführen.

Zum Beispiel

Speichern Sie einen Cache

set name jjy
  • 1

Der Aufnahmebefehl lautet

$3 r n
set r n
$4 r n
name r n
$5  r n
jjy r n
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
Versatz100010011002100310041005100610071008
Bytewert$3RN$4NAM

7. Der Befehl wird fortlaufend kopiert.
Wenn der Master-Knoten die aktuellen Daten mit dem Slave-Knoten synchronisiert, ist der Replikationseinrichtungsprozess abgeschlossen. Als nächstes sendet der Master-Knoten kontinuierlich Schreibbefehle an die Slave-Knoten, um die Konsistenz der Master-Slave-Daten sicherzustellen.

Sentinel-Überwachung

Fügen Sie hier eine Bildbeschreibung ein
Nachteile der Redis-Master-Slave-Replikation

Wenn der Host-Master ausfällt, müssen wir den Schalter manuell lösen.

Fügen Sie hier eine Bildbeschreibung ein

Belichtungsprobleme:
Sobald der Masterknoten ausfällt und der Schreibdienst nicht verwendet werden kann, müssen Sie manuell wechseln, den Masterknoten erneut auswählen und die Master-Slave-Beziehung manuell festlegen.

Master-Slave-Schalttechnik

Wenn der Master-Server ausfällt, muss ein Slave-Server manuell auf den Master-Server umgeschaltet werden, was einen manuellen Eingriff erfordert, zeit- und arbeitsintensiv ist und außerdem dazu führt, dass der Dienst für einen bestimmten Zeitraum nicht verfügbar ist.Dies ist kein empfohlener Ansatz, häufiger geben wir ihm VorrangSentry-Modus

Sentinel-Übersicht

Der Sentinel-Modus ist ein spezieller Modus. Redis stellt Sentinel-Befehle als unabhängigen Prozess bereit. Das Prinzip besteht darin, dass der Sentinel mehrere laufende Redis-Instanzen überwacht, indem er Befehle sendet und auf die Antwort des Redis-Servers wartet.

Fügen Sie hier eine Bildbeschreibung ein
Sentinel-Rolle

  • Clusterüberwachung: Verantwortlich für die Überwachung, ob die Redis-Master- und Slave-Prozesse ordnungsgemäß funktionieren
  • Benachrichtigung: Wenn eine Redis-Instanz ausfällt, ist der Sentinel dafür verantwortlich, Nachrichten als Alarmbenachrichtigungen an den Administrator zu senden.
  • Failover: Wenn der Master-Knoten auflegt, wird er automatisch an den Slave-Knoten weitergeleitet.
  • Konfigurationszentrum: Wenn ein Failover auftritt, benachrichtigen Sie den Client über die neue Master-Adresse

Aufbau einer Sentinel-Überwachungsumgebung

Fügen Sie hier eine Bildbeschreibung ein

Erstellen Sie eine neue Datei sentinel-26379.conf

#端口
port 26379
#守护进程运行
daemonize yes
#日志文件
logfile "26379.log"
sentinel monitor mymaster localhost 6379 2
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

Parameter:
Sentinel-Monitor mymaster 192.168.92.128 6379 2 Die Bedeutung der Konfiguration ist: Der Sentinel-Knoten überwacht den Master-Knoten 192.168.92.128:6379. Die Bedeutung der letzten 2 hängt mit der Fehlerbestimmung zusammen der Master-Knoten: mindestens 2 sind erforderlich. Nur wenn zwei Sentinel-Knoten übereinstimmen, kann der Ausfall des Master-Knotens festgestellt und ein Failover durchgeführt werden.

Erstellen Sie eine neue Datei sentinel-26380.conf

#端口
port 26380
#守护进程运行
daemonize yes
#日志文件
logfile "26380.log"
sentinel monitor mymaster localhost 6379 2
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

Erstellen Sie eine neue Datei sentinel-26381.conf

#端口
port 26381
#守护进程运行
daemonize yes
#日志文件
logfile "26381.log"
sentinel monitor mymaster localhost 6379 2
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

Starten des Sentinel-Knotens

redis-sentinel sentinel-26379.conf
  • 1

Status des Sentinel-Knotens anzeigen

[root@localhost src]# ./redis-cli -p 26379
127.0.0.1:26379> 
127.0.0.1:26379> 
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.66.100:6379,slaves=2,sentinels=3
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11

Analyse des Funktionsprinzips von Sentinel

Fügen Sie hier eine Bildbeschreibung ein
Überwachungsphase
Fügen Sie hier eine Bildbeschreibung ein

Beachten:

  • Sentinel (Sentinel 1)-----&gt;Initiieren Sie Informationen an den Master (Master) und den Slave (Slave) und erhalten Sie die vollständigen Informationen.
  • Sentinel (Sentinel 2) -----&gt;Initiieren Sie Informationen an den Master (Master), kennen Sie die Informationen des vorhandenen Sentinel (Sentinel 1) und stellen Sie eine Verbindung zum Slave (Slave) her.
  • sentinel (sentinel 2)-----&gt;Initiieren Sie ein Abonnement für sentinel (sentinel 1).

Benachrichtigungsphase

Sentinel sendet kontinuierlich Benachrichtigungen an Master und Slave, um Informationen zu sammeln.

Failover-Phase

Wenn in der Benachrichtigungsphase die vom Sentinel gesendete Benachrichtigung keine Antwort vom Master erhält, wird der Master als SRI_S_DOWN markiert und der Status des Masters an jeden Sentinel gesendet. Wenn andere Sentinels hören, dass der Master gestorben ist, sagen sie Ich glaube es nicht. Ich werde es auch überprüfen und senden. Die Ergebnisse werden mit jedem Sentinel geteilt. Wenn die Hälfte der Sentinels denkt, dass der Master ausgefallen ist, markieren sie den Master als SRI_0_DOWN.
Fügen Sie hier eine Bildbeschreibung ein
Hier kommt die Frage:

Zu diesem Zeitpunkt muss der Meister ersetzt werden. Wer wird der Meister sein?

Wie man abstimmt

Weg:

Ich werde für denjenigen Sentinel stimmen, bei dem ich zuerst die Wahlbenachrichtigung erhalte.

Beseitigen Sie einige Fälle:

  • Nicht online
  • Langsame Antwort
  • Lange Zeit vom ursprünglichen Master getrennt
  • Prioritätsprinzip

Failover

Fügen Sie hier eine Bildbeschreibung ein
Überblick
Demonstriert die Überwachungs- und automatischen Failover-Funktionen von Sentinel, wenn der Masterknoten ausfällt.

Failover demonstrieren
Verwenden Sie den Befehl kill, um den Masterknoten zu töten

ps aux |grep redis
kill -9 pid
  • 1
  • 2

Informationen zum Sentinel-Knoten anzeigen

Wenn Sie sofort den Befehl info Sentinel auf dem Sentinel-Knoten verwenden, um ihn anzuzeigen.

[root@localhost src]# ./redis-cli -p 26379
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6381,slaves=5,sentinels=3
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9

Beachten
Sie werden feststellen, dass der Masterknoten nicht umgeschaltet wurde, da es einige Zeit dauern wird, bis der Sentinel den Ausfall des Masterknotens erkennt und ihn überträgt.

Starten Sie Knoten 6379 neu

[root@localhost src]# ./redis-cli info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:down
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

Konfigurationsdateien werden neu geschrieben
Während der Failover-Phase werden die Konfigurationsdateien der Sentinel- und Master-Slave-Knoten neu geschrieben.

include /usr/local/redis/redis.conf
pidfile "/var/run/redis_6379.pid"
port 6379
dbfilename "dump6379.rdb"
# Generated by CONFIG REWRITE
daemonize yes
protected-mode no
appendonly yes
slowlog-max-len 1200
slowlog-log-slower-than 1000
save 5 1
user default on nopass ~* &* +@all
dir "/usr/local/redis"
replicaof 127.0.0.1 6381
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14

abschließend

  • Die Master-Slave-Knoten im Sentinel-System unterscheiden sich nicht von gewöhnlichen Master-Slave-Knoten. Die Fehlererkennung und -übertragung wird von Sentinel gesteuert und abgeschlossen.
  • Sentinel-Knoten sind im Wesentlichen Redis-Knoten.
  • Jeder Sentinel-Knoten muss nur den Überwachungs-Masterknoten konfigurieren, um andere Sentinel-Knoten und Slave-Knoten automatisch zu erkennen.
  • Während der Start- und Failover-Phase des Sentinel-Knotens werden die Konfigurationsdateien jedes Knotens neu geschrieben (Config Rewrite).

Cluster-Modus

Redis verfügt über drei Clustermodi

  • Master-Slave-Modus
  • Sentinel-Modus
  • Cluster-Modus

Nachteile des Sentry-Modus
Fügen Sie hier eine Bildbeschreibung ein
Mangel

  • Wenn der Master auflegt, wählt Sentinel einen Master. Während der Wahl gibt es keine Möglichkeit, auf Redis zuzugreifen, und der Zugriff wird vorübergehend unterbrochen.
  • Im Sentry-Modus kann nur der Master-Knoten extern beschrieben werden und der Slave-Knoten kann nur zum Lesen verwendet werden. Obwohl ein einzelner Redis-Knoten bis zu 10 W QPS unterstützt, liegt bei E-Commerce-Werbeaktionen der gesamte Druck beim Schreiben von Daten beim Master.
  • Der Einzelknotenspeicher von Redis kann nicht zu groß eingestellt werden, da die Master-Slave-Synchronisation beim Starten des Knotens sehr lange dauert.

Übersicht über den Clustermodus
Fügen Sie hier eine Bildbeschreibung ein
Der Redis-Cluster ist ein verteilter Service-Cluster, der aus mehreren Master-Slave-Knotengruppen besteht. Er verfügt über Replikations-, Hochverfügbarkeits- und Sharding-Funktionen.

Vorteile des Redis-Clusters

  • Der Redis-Cluster verfügt über mehrere Master, wodurch die Auswirkungen vorübergehender Zugriffsprobleme verringert werden können.
  • Der Redis-Cluster verfügt über mehrere Master, was eine höhere Parallelität ermöglichen kann
  • Redis-Cluster können in Shards gespeichert werden, sodass mehr Daten gespeichert werden können

Aufbau im Cluster-Modus

Für den Redis-Clusteraufbau sind mindestens 3 Master-Knoten erforderlich. Wir bauen hier 3 Master mit jeweils einem Slave-Knoten, also insgesamt 6 Redis-Knoten.
Fügen Sie hier eine Bildbeschreibung ein
Clusterbau

Erstellen Sie 6 verschiedene Redis-Knoten mit den Portnummern 6379, 6380, 6381, 6382, 6383 und 6384.

Beachten: Die Dateien dump.rdb und appendonly.aof müssen vor dem Kopieren gelöscht werden.

1. Erstellen Sie eine neue Konfigurationsdatei
Erstellen Sie die Dateien redis6379.config, redis6380.config, redis6381.config, redis6382.config, redis6383.config, redis6384.config. Ändern Sie die Portnummer in der Konfigurationsdatei so, dass sie der Datei-Portnummer entspricht.

daemonize yes
dir /usr/local/redis-7.2.4/redis-cluster/6382/
bind 192.168.47.100
port 6382
dbfilename dump6382.rdb
cluster-enabled yes
cluster-config-file nodes-6382.conf
cluster-node-timeout 5000
appendonly yes
protected-mode no
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

Parameter

  • Cluster-Konfigurationsdatei: Die Konfigurationsdatei für die Cluster-Persistenz, die den Status anderer Knoten, Persistenzvariablen usw. enthält, wird automatisch im oben konfigurierten Dir-Verzeichnis generiert. Jeder Knoten verwaltet während des Betriebs eine Cluster-Konfigurationsdatei. Wenn sich die Cluster-Informationen ändern (z. B. beim Hinzufügen oder Entfernen von Knoten), aktualisieren alle Knoten im Cluster die neuesten Informationen in der Konfigurationsdatei Öffnen Sie die Konfigurationsdatei, um Clusterinformationen zu erhalten, und Sie können dem Cluster problemlos wieder beitreten. Die Cluster-Konfigurationsdatei wird von Redis verwaltet und erfordert keine manuelle Änderung.
  • clouster-enabled: Aktiviert den Cluster

Ordner erstellen

mkdir -p /usr/local/redis-7.2.4/redis-cluster/6379/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6380/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6381/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6382/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6383/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6384/
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

Starten Sie sechs Knoten

[root@bogon src]# ./redis-server ../redis6379.config
[root@bogon src]# ./redis-server ../redis6380.config
[root@bogon src]# ./redis-server ../redis6381.config
[root@bogon src]# ./redis-server ../redis6382.config
[root@bogon src]# ./redis-server ../redis6383.config
[root@bogon src]# ./redis-server ../redis6384.config
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

Überprüfen Sie, ob jeder Knoten erfolgreich gestartet ist

[root@bogon src]# ps -ef | grep redis
root    3889    1 0 09:56 ?    00:00:03 ./redis-server 0.0.0.0:6379 [cluster]
root    3895    1 0 09:56 ?    00:00:03 ./redis-server 0.0.0.0:6380 [cluster]
root    3901    1 0 09:57 ?    00:00:03 ./redis-server 0.0.0.0:6381 [cluster]
root    3907    1 0 09:57 ?    00:00:02 ./redis-server *:6382 [cluster]
root    3913    1 0 09:57 ?    00:00:02 ./redis-server 0.0.0.0:6383 [cluster]
root    3919    1 0 09:57 ?    00:00:02 ./redis-server 0.0.0.0:6384 [cluster]
root    4247  2418 0 10:22 pts/0  00:00:00 grep --color=auto redis
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

Konfigurieren Sie den Cluster

Befehlsformat: --cluster-replicas 1 bedeutet, für jeden Master einen Slave-Knoten zu erstellen

Beachten: Die IP hier ist die tatsächliche IP der Maschine, auf der sich jeder Knoten befindet.

[root@localhost src]# ./redis-cli --cluster create 192.168.47.100:6379 192.168.47.100:6380 192.168.47.100:6381 192.168.47.100:6382 192.168.47.100:6383 192.168.47.100:6384 --cluster-replicas 1
  • 1

Fügen Sie hier eine Bildbeschreibung ein

Cluster überprüfen

Stellen Sie eine Verbindung zu jedem Client her

./redis-cli -h 192.168.47.100  -p 6379 -c
  • 1

Parameter:

‐h: Hostadresse
-p: Portnummer
‐c: zeigt den Clustermodus an

Datenschreibtest

[root@bogon src]# ./redis-cli -p 6379 -c
127.0.0.1:6379> set name zhangsan
-> Redirected to slot [5798] located at 192.168.47.100:6380
OK
192.168.47.100:6380> get name
"zhangsan"
192.168.47.100:6380>
[root@bogon src]# ./redis-cli -p 6383 -c
127.0.0.1:6383> get name
-> Redirected to slot [5798] located at 192.168.47.100:6380
"zhangsan"
192.168.47.100:6380>
[root@bogon src]# ./redis-cli -p 6383 -c
127.0.0.1:6383> readonly
OK
127.0.0.1:6383> get name
"zhangsan"
127.0.0.1:6383>
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18

Analyse der Clustermusterprinzipien

Redis-Cluster Alle Daten sind in 16384 Slots (Slots) unterteilt, und jeder Knoten ist für einen Teil der Slots verantwortlich. Slot-Informationen werden in jedem Knoten gespeichert. Nur dem Master-Knoten werden Slots zugewiesen, dem Slave-Knoten werden keine Slots zugewiesen.

Fügen Sie hier eine Bildbeschreibung ein

Slot-Positionierungsalgorithmus: k1 = 127001

Standardmäßig verwendet Cluster den crc16-Algorithmus, um den Schlüsselwert zu hashen, um einen ganzzahligen Wert zu erhalten, und verwendet diesen ganzzahligen Wert dann, um 16384 zu modulieren, um den spezifischen Steckplatz zu erhalten.

HASH_SLOT = CRC16(Schlüssel) % 16384

Erholung
Knoten anzeigen

192.168.66.103:8001> cluster nodes
  • 1

Töte den Master-Knoten

lsof -i:8001
kill -9 pid
  • 1
  • 2

Knoteninformationen beachten

Fügen Sie hier eine Bildbeschreibung ein

Java-betriebener Redis-Cluster

Fügen Sie hier eine Bildbeschreibung ein
Konfigurationsdatei ändern

spring.data.redis.cluster.nodes=192.168.47.100:6381,192.168.47.100:6383,192.168.47.100:6380
  • 1

Beachten
1. Der Redis-Cluster erfordert mindestens 3 Knoten, um eine hohe Verfügbarkeit sicherzustellen.
2. Sie sollten versuchen, das Hinzufügen oder Löschen von Knoten zu vermeiden, während der Redis-Cluster ausgeführt wird, da dies zu einer Datenmigration führen und somit die Gesamtleistung des Redis-Clusters beeinträchtigen kann.

In Java geschriebener Code

@SpringBootTest
public class CluseterTest {

  @Autowired
  private RedisTemplate<String,Object> redisTemplate;

  @Test
  void string() {
    //  保存字符串
    redisTemplate.opsForValue().set("itbaizhan","itbaizhan123");

    System.out.println(redisTemplate.opsForValue().get("itbaizhan"));

   }
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15

Wenn meine Inhalte für Sie hilfreich sind, freuen wir uns über Ihre HilfeLike, Kommentar, Favorit .Schaffen ist nicht einfach, die Unterstützung aller ist das, was mich am Laufen hält
Fügen Sie hier eine Bildbeschreibung ein