Explication détaillée de la réplication maître-esclave Redis

Ce chapitre présente une fonctionnalité puissante de Redis : la réplication maître-esclave. Un hôte maître peut avoir plusieurs machines esclaves. Et un esclave esclave peut avoir plusieurs esclaves esclaves. Cela continue de former une puissante architecture de cluster de serveurs multi-niveaux (haute évolutivité). Il peut éviter le point de défaillance unique de Redis et obtenir un effet de reprise après sinistre (haute disponibilité). L'architecture de séparation de la lecture et de l'écriture satisfait des scénarios d'applications concurrentes avec plus de lecture et moins d'écriture. Recommandé : Tutoriel vidéo Redis

Le rôle de la réplication maître-esclave

Réplication maître-esclave, lecture-écriture séparation, récupération après sinistre. Un hôte est responsable de l'écriture des données et plusieurs machines esclaves sont responsables de la sauvegarde des données. Dans les scénarios à forte concurrence, même si la machine hôte raccroche, la machine esclave peut être utilisée pour continuer à travailler à la place de la machine hôte afin d'éviter les problèmes de performances du système causés par des points de défaillance uniques. La séparation de la lecture et de l'écriture permet de meilleures performances pour les applications qui lisent plus et écrivent moins.

Architecture de réplication maître-esclave

À la base de la réplication Redis, il existe une réplication maître-esclave très simple à utiliser et à configurer qui permet les serveurs Redis esclaves sont des copies exactes des serveurs maîtres.

C'est très simple : une commande : slaveof host ip host port peut déterminer la relation maître-esclave : ./redis-sentinel sentinel.conf Sentinel ; la surveillance peut être activée.

La construction est simple, mais l'entretien est pénible. Dans les scénarios à forte concurrence, de nombreux problèmes inattendus peuvent survenir. Nous avons seulement une compréhension claire du principe de réplication, une familiarité avec la machine hôte et les changements après la panne de la machine esclave. Ce n’est qu’à cette condition que nous pourrons surmonter ces écueils. Chaque étape ci-dessous est un petit point de connaissance et une petite scène. Chaque fois que vous franchissez une étape, vous acquerrez des connaissances.

Schéma d'architecture : un maître, deux serviteurs et un soldat (vous pouvez aussi avoir plusieurs maîtres, plusieurs serviteurs et plusieurs soldats)

Préparation avant de construire les travaux

Parce que j'étais pauvre, j'ai choisi d'utiliser un serveur pour simuler trois hôtes. La seule différence par rapport à l'environnement de production réside dans l'adresse IP et le port.

Étape 1 : Copiez trois copies de redis.conf, les noms sont redis6379.conf, redis6380.conf, redis6381.conf

Étape 2 : Modifier les ports des trois fichiers, fichier pid nom, nom du fichier journal, nom du fichier rdb

Étape 3 : Ouvrez trois fenêtres pour simuler trois serveurs et démarrez le service Redis.

[root@itdragon bin]# cp redis.conf redis6379.conf
[root@itdragon bin]# cp redis.conf redis6380.conf
[root@itdragon bin]# cp redis.conf redis6381.conf
[root@itdragon bin]# vim redis6379.conf
logfile "6379.log"
dbfilename dump_6379.rdb
[root@itdragon bin]# vim redis6380.conf
pidfile /var/run/redis_6380.pid
port 6380
logfile "6380.log"
dbfilename dump_6380.rdb
[root@itdragon bin]# vim redis6381.conf
port 6381
pidfile /var/run/redis_6381.pid
logfile "6381.log"
dbfilename dump_6381.rdb
[root@itdragon bin]# ./redis-server redis6379.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
(empty list or set)
[root@itdragon bin]# ./redis-server redis6380.conf 
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6380
127.0.0.1:6380> keys *
(empty list or set)
[root@itdragon bin]# ./redis-server redis6381.conf 
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6381
127.0.0.1:6381> keys *
(empty list or set)

Étapes de configuration de la réplication maître-esclave

Configuration de base

Étape 1 : interroger le master À partir des informations de réplication, sélectionnez respectivement trois ports et exécutez la commande : info replication.

# 6379 端口
[root@itdragon bin]# ./redis-server redis6379.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:0
......

# 6380 端口
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:0
......

# 6381 端口
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:0
......

Les trois ports affichent les mêmes informations : role:master Le rôle est master,connected_slaves:0 Le nombre d'esclaves connectés est zéro. Pour en savoir plus sur la signification des paramètres, veuillez visiter le lien : http://redisdoc.com/server/info.html

Étape 2 : Sélectionnez le port 6379 et exécutez la commande : set k1 v1

127.0.0.1:6379> set k1 v1
OK

Étape 3 : Définissez la relation maître-esclave, sélectionnez respectivement le port 6380 et le port 6381, exécutez la commande : SLAVEOF 127.0.0.1 6379

# 6380 端口
127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
OK
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......

# 6381 端口
127.0.0.1:6381> SLAVEOF 127.0.0.1 6379
OK
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......

# 6379 端口
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=98,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=98,lag=1
......

La relation maître-esclave a changé :

Impression du port 6380 et du port 6381 Informations : role:slave ; master_host :127.0.0.1 adresse IP de l'hôte ; master_port :6379 port de l'hôte.

Informations imprimées sur le port 6379 : rôle : hôte maître ; esclaves_connectés : 2 connectés à deux esclaves ; esclaveX : ID, adresse IP, numéro de port, état de connexion, informations sur la base de données esclave

Étape n° : 4 : Copiez intégralement, sélectionnez respectivement le port 6380 et le port 6381, exécutez la commande : get k1

# 6380 端口
127.0.0.1:6380> get k1
"v1"

# 6381 端口
127.0.0.1:6381> get k1
"v1"

Les deux ports peuvent imprimer la valeur de k1, indiquant que lors de l'établissement d'une relation maître-esclave, l'esclave a le données de base.

Étape 5 : Copie incrémentielle, sélectionnez le port 6379 et exécutez la commande : set k2 v2. Sélectionnez ensuite respectivement le port 6380 et le port 6381 et exécutez la commande : get k2

# 6379 端口
127.0.0.1:6379> set k2 v2
OK

# 6380 端口
127.0.0.1:6380> get k2
"v2"

# 6381 端口
127.0.0.1:6381> get k2
"v2"

Les deux ports peuvent imprimer la valeur de k2, ce qui signifie qu'une fois la relation maître-esclave établie, les nouvelles données ajoutées par le L'hôte sera copié sur l'esclave.

Étape 6 : Séparation lecture-écriture maître-esclave, sélectionnez le port 6380, exécutez la commande : set k3 v3

# 6380 端口
127.0.0.1:6380> set k3 v3
(error) READONLY You can't write against a read only slave.

# 6379 端口
127.0.0.1:6379> set k3 v3
OK

L'esclave 6380 n'a pas réussi à écrire en raison du mécanisme de séparation en lecture-écriture.

Étape 7 : Si l'hôte est en panne, sélectionnez le port 6379 et exécutez la commande : shutdown

# 6379 端口
127.0.0.1:6379> SHUTDOWN
not connected> QUIT

# 6380 端口
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......

# 6381 端口
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......

D'après les résultats imprimés, nous savons que l'esclave est en veille

Non. Huit étapes : récupérez l'hôte après une panne. Sélectionnez le port 6379, redémarrez le service Redis et exécutez la commande : set k4 v4. Sélectionnez respectivement le port 6380 et le port 6381 et exécutez la commande : get k4

# 6379 端口
[root@itdragon bin]# ./redis-server redis6379.conf 
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> set k4 v4
OK

# 6380 端口
127.0.0.1:6380> get k4
"v4"

# 6381 端口
127.0.0.1:6381> get k4
"v4"

Après le redémarrage de l'hôte, tout est normal.

Étape 9 : Récupérez depuis la machine en panne, sélectionnez le port 6380 et exécutez la commande : shutdown. Sélectionnez le port 6379 et exécutez la commande : set k5 v5. Sélectionnez le port 6380, redémarrez le service Redis et exécutez la commande : get k5

# 6380 端口
127.0.0.1:6380> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# ./redis-server redis6380.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6380
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......
127.0.0.1:6380> get k5
"v5"

# 6379 端口
127.0.0.1:6379> set k5 v5
OK

从机宕机后，一切正常。笔者用的是redis.4.0.2版本的。看过其他教程，从机宕机恢复后，只能同步主机新增数据，也就是k5是没有值的，可是笔者反复试过，均有值。留着备忘！

第十步：去中性化思想，选择6380端口，执行命令：SLAVEOF 127.0.0.1 6381。选择6381端口，执行命令：info replication

# 6380 端口
127.0.0.1:6380> SLAVEOF 127.0.0.1 6381
OK

# 6381 端口
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=1677,lag=1
......

虽然6381 是6380的主机，是6379的从机。在Redis眼中，6381依旧是从机。一台主机配多台从机，一台从机在配多台从机，从而实现了庞大的集群架构。同时也减轻了一台主机的压力，缺点是增加了服务器间的延迟。

从机上位

模拟主机宕机，人为手动怂恿从机上位的场景。先将三个端口恢复成6379是主机，6380和6381是从机的架构。

从机上位步骤：

第一步：模拟主机宕机，选择6379端口，执行命令：shutdown

第二步：断开主从关系，选择6380端口，执行命令：SLAVEOF no one

第三步：重新搭建主从，选择6381端口，执行命令：info replication，SLAVEOF 127.0.0.1 6380

第四步：之前主机恢复，选择6379端口，重启Redis服务，执行命令：info replication

在6379主机宕机后，6380从机断开主从关系，6381开始还在原地待命，后来投靠6380主机后，6379主机回来了当它已是孤寡老人，空头司令。

# 6379端口

127.0.0.1:6379> SHUTDOWN
not connected> QUIT

# 6380端口
127.0.0.1:6380> SLAVEOF no one
OK
127.0.0.1:6380> set k6 v6
OK

# 6381端口
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......
127.0.0.1:6381> SLAVEOF 127.0.0.1 6380
OK
127.0.0.1:6381> get k6
"v6"

哨兵监控

从机上位是需要人为控制，在生产环境中是不可取的，不可能有人实时盯着它，也不可能大半夜起床重新搭建主从关系。在这样的需求促使下，哨兵模式来了！！！

哨兵有三大任务：

1 监控：哨兵会不断地检查你的Master和Slave是否运作正常

2 提醒：当被监控的某个Redis出现问题时, 哨兵可以通过API向管理员或者其他应用程序发送通知

3 故障迁移：若一台主机出现问题时，哨兵会自动将该主机下的某一个从机设置为新的主机，并让其他从机和新主机建立主从关系。

哨兵搭建步骤：

第一步：新开一个窗口，取名sentinel，方便观察哨兵日志信息

第二步：创建sentinel.conf文件，也可以从redis的解压文件夹中拷贝一份。

第三步：设置监控的主机和上位的规则，编辑sentinel.conf，输入 sentinel monitor itdragon-redis 127.0.0.1 6379 1 保存退出。解说：指定监控主机的ip地址，port端口，得票数。

第四步：前端启动哨兵，执行命令：./redis-sentinel sentinel.conf。

第五步：模拟主机宕机，选择6379窗口，执行命令：shutdown。

第六步：等待从机投票，在sentinel窗口中查看打印信息。

第七步：启动6379服务器，

语法结构：sentinel monitor 自定义数据库名 主机ip 主机port 得票数

若从机得票数大于设置值，则成为新的主机。若之前的主机恢复后，

如果哨兵也宕机了？？？那就多配几个哨兵并且相互监控。

# sentinel窗口
[root@itdragon bin]# vim sentinel.conf
sentinel monitor itdragon-redis 127.0.0.1 6379 1
[root@itdragon bin]# ./redis-sentinel sentinel.conf
......
21401:X 29 Nov 15:39:15.052 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ itdragon-redis 127.0.0.1 6380
21401:X 29 Nov 15:39:15.052 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ itdragon-redis 127.0.0.1 6380
21401:X 29 Nov 15:39:45.081 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ itdragon-redis 127.0.0.1 6380

21401:X 29 Nov 16:40:52.055 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ itdragon-redis 127.0.0.1 6380
21401:X 29 Nov 16:41:02.028 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ itdragon-redis 127.0.0.1 6380
......

# 6379端口
127.0.0.1:6379> SHUTDOWN
not connected> QUIT

# 6380端口
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=72590,lag=0
......

# 6381端口
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
......

+slave ：一个新的从服务器已经被 Sentinel 识别并关联。

+sdown ：给定的实例现在处于主观下线状态。

-sdown ：给定的实例已经不再处于主观下线状态。

主从复制的原理

全量复制

实现原理：建立主从关系时，从机会给主机发送sync命令，主机接收命令，后台启动的存盘进程，同时收集所有用于修改命令，传送给从机。

增量复制

实现原理：主机会继续将新收集到的修改命令依次传给从机，实现数据的同步效果。

主从复制的缺点

Redis的主从复制最大的缺点就是延迟，主机负责写，从机负责备份，这个过程有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，从机器数量的增加也会使这个问题更加严重。

Résumé

1 Afficher la commande de relation de réplication maître-esclave : réplication d'informations

2 Définir la commande de relation maître-esclave : slaveof host ip host port

3 Activez la commande du mode sentinelle : ./redis-sentinel sentinel.conf

4 Principe de réplication maître-esclave : affectation complète au début, suivie d'une affectation incrémentielle

5 Trois tâches principales du mode sentinelle : surveillance, rappel, migration automatique des pannes

Pour plus de connaissances sur Redis, veuillez faire attention à la colonne Tutoriel de base de données Redis.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!