2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
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
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.
MULTIStarten Sie eine Transaktion.EXECDer Befehl löst die Transaktion aus;
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"
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
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.
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"
Beachten：
Bei Laufzeitfehlern, also nicht grammatikalischen Fehlern, werden korrekte Befehle ausgeführt und falsche Befehle geben einen Fehler zurück.
Ü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.
Die Rolle der Master-Slave-Replikation
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
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
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
Starten Sie drei Redis-Server
./redis-server ../redis6379.conf
./redis-server ../redis6380.conf
./redis-server ../redis6381.conf
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
Ü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
Ausgestattet mit Slave-Datenbank, aber nicht mit Master-Datenbank
Syntaxformat:
slaveof <ip> <port>
Beispiel:
Ausgeführt am 6380 und 6381.
127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
OK
Schreiben Sie auf dem Host und lesen Sie Daten auf dem Slave
set k1 v1
Die Master-Slave-Replikation kann in drei Phasen unterteilt werden
Der Kopiervorgang ist grob in 6 Vorgänge unterteilt
info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
4. Senden Sie den Ping-Befehl
Nachdem die Verbindung erfolgreich hergestellt wurde, sendet der Slave-Knoten eine Ping-Anfrage für die erste Kommunikation.
Wirkung:
- Ermitteln Sie, ob der Netzwerk-Socket zwischen Master und Slave verfügbar ist.
- Ermitteln Sie, ob der Masterknoten derzeit Befehle annehmen kann
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.
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.
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
Der Aufnahmebefehl lautet
$3 r n
set r n
$4 r n
name r n
$5 r n
jjy r n
| Versatz | 1000 | 1001 | 1002 | 1003 | 1004 | 1005 | 1006 | 1007 | 1008 |
|---|---|---|---|---|---|---|---|---|---|
| Bytewert | $ | 3 | R | N | $ | 4 | N | A | M |
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.
Nachteile der Redis-Master-Slave-Replikation
Wenn der Host-Master ausfällt, müssen wir den Schalter manuell lösen.
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.
Sentinel-Rolle
Erstellen Sie eine neue Datei sentinel-26379.conf
#端口
port 26379
#守护进程运行
daemonize yes
#日志文件
logfile "26379.log"
sentinel monitor mymaster localhost 6379 2
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
Erstellen Sie eine neue Datei sentinel-26381.conf
#端口
port 26381
#守护进程运行
daemonize yes
#日志文件
logfile "26381.log"
sentinel monitor mymaster localhost 6379 2
Starten des Sentinel-Knotens
redis-sentinel sentinel-26379.conf
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
Überwachungsphase
Beachten:
- Sentinel (Sentinel 1)----->Initiieren Sie Informationen an den Master (Master) und den Slave (Slave) und erhalten Sie die vollständigen Informationen.
- Sentinel (Sentinel 2) ----->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)----->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.
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:
Ü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
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
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
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
abschließend
Redis verfügt über drei Clustermodi
Nachteile des Sentry-Modus
Mangel：
Übersicht über den Clustermodus
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
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.
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
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/
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
Ü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
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
Cluster überprüfen
Stellen Sie eine Verbindung zu jedem Client her
./redis-cli -h 192.168.47.100 -p 6379 -c
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>
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.
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
Töte den Master-Knoten
lsof -i:8001
kill -9 pid
Knoteninformationen beachten
Konfigurationsdatei ändern
spring.data.redis.cluster.nodes=192.168.47.100:6381,192.168.47.100:6383,192.168.47.100:6380
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"));
}
}
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
Er widmet sich seit mehr als 30 Jahren der Technologieforschung und beherrscht verschiedene Sprachen wie Java, Linux, Javascript, PHP, CSS usw. Er hat viele Beiträge im Open-Source-Bereich geleistet Entwicklerdokumentationsstation, um einige Themen in der Technologieentwicklung als zukünftige Referenz zu teilen
