2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
Transactions au niveau de la base de données
Au niveau de la base de données, une transaction est un ensemble d'opérations qui soit toutes s'exécutent avec succès, soit aucune d'entre elles ne s'exécute.
Quatre caractéristiques majeures des transactions de bases de données
Transaction Redis
Une transaction Redis est un ensemble de commandes. Toutes les commandes d'une transaction seront sérialisées et une série de commandes seront exécutées de manière unique, séquentielle et exclusive.
MULTI
Démarrer une transaction ;EXEC
La commande déclenche la transaction ;
Multi, Exec, rejeter
entrée de transaction deMulti
Lorsque la commande démarre, les commandes saisies seront placées une par une dans la file d'attente du tampon de commandes et ne seront exécutées que lorsque leExec
Ensuite, Redis exécutera les commandes dans la file d'attente du tampon de commandes précédente dans l'ordre.Pendant le processus de formation de l'équipe, vous pouvez réussirdiscard
Venez abandonner l'équipe.
exemple
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"
abandonner la transaction
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
Tous assis ensemble
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.
Avis:
Le jeu de commandes contient des instructions incorrectes (notez qu'il s'agit d'erreurs de syntaxe). Elles sont toutes connectées et échouent toutes.
Chaque injustice a son propriétaire, chaque dette a son propriétaire
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"
Avis:
Pour les erreurs d'exécution, c'est-à-dire les erreurs non grammaticales, les commandes correctes seront exécutées et les commandes incorrectes renverront une erreur.
Aperçu
Parmi les entreprises existantes, 80 % des entreprises utilisent principalement les services Redis autonomes. Dans les scénarios réels, Redis sur un seul nœud est sujet à des risques.
faire face à des problèmes:
- dysfonctionnement de la machine. Nous déployons sur un serveur Redis Lorsqu'une panne de machine se produit, nous devons migrer vers un autre serveur et nous assurer que les données sont synchronisées.
- Goulot d’étranglement de capacité. Lorsque nous aurons besoin d'étendre la mémoire Redis, de 16 Go de mémoire à 64 Go, une seule machine ne pourra certainement pas la satisfaire. Bien sûr, vous pouvez acheter une nouvelle machine 128G.
Solution
Pour obtenir une plus grande capacité de stockage de la base de données distribuée et résister à un accès simultané élevé, nous stockerons les données de la base de données centralisée d'origine sur plusieurs autres nœuds du réseau.
Avis:
Afin de résoudre ce problème de nœud unique, Redis déploiera également plusieurs copies de données sur d'autres nœuds pour la réplication afin d'obtenir une haute disponibilité de Redis et une sauvegarde redondante des données pour garantir une haute disponibilité des données et des services.
Qu'est-ce que la réplication maître-esclave
La réplication maître-esclave fait référence à la copie de données d'un serveur Redis vers d'autres serveurs Redis. Le premier est appelé nœud maître et le second nœud esclave. La réplication des données est unidirectionnelle et ne peut s'effectuer que du nœud maître vers le nœud esclave.
Le rôle de la réplication maître-esclave
Écrire le fichier de configuration
Créer un nouveau redis6379.conf
include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb
Créer un nouveau redis6380.conf
include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb
Créer un nouveau redis6381.conf
include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6381.pid
port 6381
dbfilename dump6381.rdb
Démarrez trois serveurs Redis
./redis-server ../redis6379.conf
./redis-server ../redis6380.conf
./redis-server ../redis6381.conf
Afficher les processus système
[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
Vérifiez l'état de fonctionnement de trois hôtes
#打印主从复制的相关信息
./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
Equipé d'une base de données esclave mais pas de base de données maître
Format de syntaxe :
slaveof <ip> <port>
Exemple:
Exécuté les 6380 et 6381.
127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
OK
Écrire sur l'hôte et lire les données sur l'esclave
set k1 v1
La réplication maître-esclave peut être divisée en 3 étapes
Le processus de copie est grossièrement divisé en 6 processus
info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
4. Envoyez la commande ping
Une fois la connexion établie avec succès, le nœud esclave envoie une requête ping pour la première communication.
effet:
- Détectez si la prise réseau entre le maître et l'esclave est disponible.
- Détecter si le nœud maître peut actuellement accepter des commandes
TSA.
Si le paramètre requirepass est défini sur le nœud maître, la vérification du mot de passe est requise. Le nœud esclave doit configurer le paramètre masterauth pour garantir que le mot de passe est le même que celui du nœud maître pour réussir la vérification. Si la vérification échoue, la réplication sera effectuée ; terminé et le nœud esclave relancera le processus de réplication.
Synchronisez les ensembles de données.
Une fois la connexion de réplication maître-esclave communiquée normalement, lorsque la réplication est établie pour la première fois, le nœud maître envoie toutes les données qu'il détient au nœud esclave. Cette partie de l'opération est l'étape la plus longue.
Stratégie de synchronisation maître-esclave
Lorsque le maître et l'esclave sont juste connectés, une synchronisation complète est effectuée ; une fois la synchronisation complète terminée, une synchronisation incrémentielle est effectuée. Bien entendu, si nécessaire, l'esclave peut à tout moment lancer une synchronisation complète. La stratégie Redis est que, quoi qu'il arrive, une synchronisation incrémentielle sera tentée en premier, et en cas d'échec, la machine esclave devra effectuer une synchronisation complète.
Par exemple
enregistrer un cache
set name jjy
La commande d'enregistrement est
$3 r n
set r n
$4 r n
name r n
$5 r n
jjy r n
Compenser | 1000 | 1001 | 1002 | 1003 | 1004 | 1005 | 1006 | 1007 | 1008 |
---|---|---|---|---|---|---|---|---|---|
Valeur d'octet | $ | 3 | l | n | $ | 4 | n | un | m |
7. La commande est copiée en continu.
Lorsque le nœud maître synchronise les données actuelles avec le nœud esclave, le processus d'établissement de la réplication est terminé. Ensuite, le nœud maître enverra en permanence des commandes d'écriture aux nœuds esclaves pour garantir la cohérence des données maître-esclave.
Inconvénients de la réplication maître-esclave Redis
Lorsque le maître hôte tombe en panne, nous devons résoudre manuellement le commutateur.
Problèmes d'exposition :
Une fois que le nœud maître tombe en panne et que le service d'écriture ne peut plus être utilisé, vous devez basculer manuellement, resélectionner le nœud maître et définir manuellement la relation maître-esclave.
Technologie de commutation maître-esclave
Lorsque le serveur maître tombe en panne, un serveur esclave doit être basculé manuellement vers le serveur maître, ce qui nécessite une intervention manuelle, prend du temps et demande beaucoup de main d'œuvre, et entraînera également l'indisponibilité du service pendant un certain temps.Ce n'est pas une approche recommandée, le plus souvent nous donnons la priorité àMode sentinelle。
Présentation de Sentinelle
Le mode Sentinel est un mode spécial. Premièrement, Redis fournit des commandes sentinelle. Sentinel est un processus indépendant. En tant que processus, il s'exécutera indépendamment. Le principe est que la sentinelle surveille plusieurs instances Redis en cours d'exécution en envoyant des commandes et en attendant la réponse du serveur Redis.
Rôle de sentinelle
Créez un nouveau fichier sentinel-26379.conf
#端口
port 26379
#守护进程运行
daemonize yes
#日志文件
logfile "26379.log"
sentinel monitor mymaster localhost 6379 2
paramètre:
moniteur sentinelle mymaster 192.168.92.128 6379 2 La signification de la configuration est : le nœud sentinelle surveille le nœud maître 192.168.92.128:6379 Le nom du nœud maître est mymaster La signification des 2 derniers est liée à la détermination des défauts de. le nœud maître : au moins 2 sont requis Ce n'est que lorsque deux nœuds sentinelles sont d'accord que la défaillance du nœud maître peut être déterminée et le basculement effectué.
Créez un nouveau fichier sentinel-26380.conf
#端口
port 26380
#守护进程运行
daemonize yes
#日志文件
logfile "26380.log"
sentinel monitor mymaster localhost 6379 2
Créez un nouveau fichier sentinel-26381.conf
#端口
port 26381
#守护进程运行
daemonize yes
#日志文件
logfile "26381.log"
sentinel monitor mymaster localhost 6379 2
Démarrage du nœud sentinelle
redis-sentinel sentinel-26379.conf
Afficher l'état du nœud sentinelle
[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
phase de surveillance
Avis:
- sentinelle (sentinelle 1)----->Initier des informations au maître (maître) et à l'esclave (esclave) et obtenir les informations complètes.
- sentinelle (sentinelle 2)----->Initiez l'information au maître (maître), vous connaîtrez les informations de la sentinelle existante (sentinelle 1), et vous connecterez à l'esclave (esclave).
- sentinel (sentinel 2)----->Initier un abonnement à sentinel (sentinel 1).
Étape de notification
Sentinel envoie en permanence des notifications au maître et à l'esclave pour collecter des informations.
phase de basculement
Dans la phase de notification, si la notification envoyée par la sentinelle ne reçoit pas de réponse du maître, elle marquera le maître comme SRI_S_DOWN et enverra le statut du maître à chaque sentinelle. Lorsque d'autres sentinelles apprendront que le maître est mort, elles diront. Je n'y crois pas, je vais aussi le vérifier et l'envoyer. Les résultats sont partagés avec chaque sentinelle. Lorsque la moitié des sentinelles pensent que le maître est en panne, elles marqueront le maître comme SRI_0_DOWN.
Voici la question :
A ce moment, le maître doit être remplacé. Qui sera le maître ?
Comment voter
Chemin:
Quelle que soit la sentinelle à qui je recevrai en premier l'avis d'élection, elle votera pour elle.
Éliminer certains cas :
Aperçu
Démontre les capacités de surveillance et de basculement automatique de Sentinel en cas de panne du nœud maître.
Démontrer le basculement
Utilisez la commande kill pour tuer le nœud maître
ps aux |grep redis
kill -9 pid
Afficher les informations du nœud sentinelle
Si vous utilisez immédiatement la commande info Sentinel sur le nœud sentinelle pour l'afficher.
[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
Avis:
Vous constaterez que le nœud maître n'a pas été basculé, car il faudra un certain temps à la sentinelle pour détecter la panne du nœud maître et la transférer.
Redémarrer le nœud 6379
[root@localhost src]# ./redis-cli info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:down
Les fichiers de configuration seront réécrits
Lors de la phase de basculement, les fichiers de configuration des nœuds sentinelle et maître-esclave seront réécrits.
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
en conclusion
Redis dispose de trois modes de cluster
Inconvénients du mode Sentinelle
défaut:
Présentation du mode cluster
Le cluster Redis est un cluster de services distribués composé de plusieurs groupes de nœuds maître-esclave. Il dispose de fonctionnalités de réplication, de haute disponibilité et de partitionnement.
Avantages du cluster Redis
La construction d'un cluster Redis nécessite au moins 3 nœuds maîtres. Nous construisons ici 3 maîtres, chacun avec un nœud esclave, pour un total de 6 nœuds Redis ;
Construction de clusters
Créez 6 nœuds Redis différents avec les numéros de port 6379, 6380, 6381, 6382, 6383 et 6384 respectivement.
Avis: Les fichiers dump.rdb et appendonly.aof doivent être supprimés avant la copie.
1. Créez un nouveau fichier de configuration
Créez les fichiers redis6379.config, redis6380.config, redis6381.config, redis6382.config, redis6383.config, redis6384.config. Modifiez le numéro de port dans le fichier de configuration afin qu'il corresponde au numéro de port du fichier.
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
paramètre:
- cluster-config-file : le fichier de configuration de persistance du cluster, qui contient l'état des autres nœuds, les variables de persistance, etc., sera automatiquement généré dans le répertoire dir configuré ci-dessus. Chaque nœud conservera un fichier de configuration du cluster pendant le fonctionnement ; chaque fois que les informations du cluster changent (comme l'ajout ou la suppression de nœuds), tous les nœuds du cluster mettront à jour les dernières informations dans le fichier de configuration lorsque le nœud redémarrera ; le fichier de configuration pour obtenir des informations sur le cluster et vous pouvez facilement rejoindre le cluster. Le fichier de configuration du cluster est géré par Redis et ne nécessite aucune modification manuelle.
- clouster-enabled : activer le cluster
Créer le dossier
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/
Démarrer six nœuds
[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
Vérifiez si chaque nœud démarre avec succès
[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
Configurer le cluster
Format de commande : --cluster-replicas 1 signifie créer un nœud esclave pour chaque maître
Avis: L'IP ici est la véritable IP de la machine où se trouve chaque nœud.
[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
Vérifier le cluster
Connectez-vous à n'importe quel client
./redis-cli -h 192.168.47.100 -p 6379 -c
paramètre:
‐h : adresse de l'hôte
-p : numéro de port
‐c : indique le mode cluster
Test d'écriture de données
[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>
Cluster Redis Toutes les données sont divisées en 16 384 emplacements (slots) et chaque nœud est responsable d'une partie des emplacements. Les informations sur les emplacements sont stockées dans chaque nœud. Seul le nœud maître se verra attribuer des emplacements, et le nœud esclave ne se verra pas attribuer d'emplacements.
Algorithme de positionnement des fentes: k1 = 127001
Par défaut, Cluster utilisera l'algorithme crc16 pour hacher la valeur de la clé afin d'obtenir une valeur entière, puis utilisera cette valeur entière au modulo 16384 pour obtenir l'emplacement spécifique.
HASH_SLOT = CRC16(clé) % 16384
Récupération
Afficher les nœuds
192.168.66.103:8001> cluster nodes
Tuez le nœud maître
lsof -i:8001
kill -9 pid
Observer les informations sur le nœud
Modifier le fichier de configuration
spring.data.redis.cluster.nodes=192.168.47.100:6381,192.168.47.100:6383,192.168.47.100:6380
Avis
1. Le cluster Redis nécessite au moins 3 nœuds pour garantir une haute disponibilité.
2. Vous devez essayer d'éviter d'ajouter ou de supprimer des nœuds pendant l'exécution du cluster Redis, car cela pourrait entraîner une migration de données et ainsi affecter les performances globales du cluster Redis.
Code écrit en Java
@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"));
}
}
Si mon contenu vous est utile, s'il vous plaîtJ'aime, commente, mets en favori .Créer n’est pas facile, le soutien de tous est ce qui me fait avancer