Compréhension approfondie du mécanisme de synchronisation maître-esclave dans Redis

Cet article vous amènera à comprendre la synchronisation maître-esclave dans Redis, et à présenter les deux modèles structurels de Redis maître-esclave, l'établissement de la relation maître-esclave, la stratégie de réplication maître-esclave, etc. J'espère ça sera utile à tout le monde !

Les caractéristiques et les principes fondamentaux de redis ont été analysés en détail dans l'article précédent. À partir de cet article, nous analyserons et interpréterons la structure de déploiement et le mode de fonctionnement de redis. Dans un environnement de production réel, nous n'utiliserons fondamentalement pas Redis à nœud unique pour fournir des services, du moins le mode sentinelle ou cluster d'une structure maître-esclave pour garantir la fiabilité du service Redis. Cet article expliquera en détail le mécanisme de synchronisation maître-esclave de Redis. [Recommandations associées : Tutoriel vidéo Redis]

1. Redis a deux modèles structurels : maître-esclave :

1.1 Réplication maître-esclave

La structure de réplication d'un maître et de N esclaves n'a qu'un seul niveau de relation de réplication.C'est également la forme la plus couramment utilisée.Habituellement, les redis qui construisent des structures de sentinelle ou de cluster adoptent cette structure de réplication et peuvent garantir la disponibilité des services via la relation de réplication des nœuds esclaves de premier niveau et réaliser la commutation maître-esclave. dans des situations anormales.

1.2 Réplication en cascade

La relation de réplication de la structure de réplication en cascade peut avoir plusieurs niveaux, et le nœud esclave d'un nœud maître peut être le nœud maître d'un nœud esclave subordonné. L'application d'une structure de réplication en cascade est relativement rare. Cette structure peut alléger dans une certaine mesure la pression de réplication du nœud maître dans une structure avec plusieurs nœuds esclaves.

2. Établissement de la relation maître-esclave Redis

La synchronisation maître-esclave de Redis commence avec la commande SLAVEOF host port Grâce à cette commande, la commande SLAVEOF est utilisée pour modifier dynamiquement le comportement. de la fonction de réplication lorsque Redis est en cours d'exécution. En exécutant la commande SLAVEOF host port, vous pouvez transformer le serveur actuel en serveur esclave du serveur spécifié. Si le serveur actuel est déjà un serveur esclave d'un serveur maître, l'exécution du port hôte SLAVEOF entraînera l'arrêt de la synchronisation du serveur actuel avec l'ancien serveur maître, la suppression de l'ancien ensemble de données et la synchronisation avec le nouveau serveur maître. De plus, l'exécution de la commande SLAVEOF NO ONE sur un serveur esclave entraînera la désactivation de la fonction de réplication du serveur esclave et la transition du serveur esclave vers le serveur maître. L'ensemble de données synchronisées d'origine ne sera pas supprimé. Profitant de la fonctionnalité de SLAVEOF NO ONE selon laquelle l'ensemble de données synchronisées ne sera pas supprimé, sans configurer de sentinelle ou de cluster, le serveur esclave peut être utilisé comme nouveau serveur maître en cas de panne du serveur maître, permettant ainsi un fonctionnement ininterrompu.

La figure suivante montre le processus d'établissement d'une relation maître-esclave :

Remarque :

Selon le processus d'exécution ci-dessus, il y a un point qui nécessite une attention particulière lorsque nous exécutons la commande slaveof. sur un nœud qui a déjà une relation maître-esclave, mettra fin à la relation maître-esclave existante et effacera toutes les données sous le nœud. Il s'agit d'une opération relativement menaçante dans l'environnement de production. Existe-t-il un moyen plus sûr ? Lors de l'introduction de la commande slaveof ci-dessus, nous avons mentionné que vous pouvez transmettre le paramètre NO ONE, c'est-à-dire exécuter la commande SLAVEOF NO ONE. Cette commande mettra uniquement fin à la relation de réplication maître-esclave et n'effacera pas les données. Elle est relativement plus sûre. .

3. Synchronisation des données

Après avoir établi la relation maître-esclave, vous entrerez dans le processus de synchronisation des données maître-esclave. Il existe principalement trois situations ici. une fois la synchronisation initiale terminée, le choix de la méthode de synchronisation après que la relation maître-esclave soit anormalement interrompue et reconnectée. Il existe deux scénarios de synchronisation complète et incrémentielle.

3.1 Synchronisation complète

• Lorsque le nœud esclave est démarré ou déconnecté et reconnecté (la reconnexion ne remplit pas les conditions de synchronisation incrémentielle), la commande SYNC sera envoyée à la base de données maître.

• Après avoir reçu la commande SYNC, le nœud maître commencera à enregistrer l'instantané en arrière-plan (c'est-à-dire la persistance RDB, lors de la réplication maître-esclave, RDB sera déclenché sans condition) et mettra en cache les commandes reçues lors de l'enregistrement de l'instantané.

• Une fois que le nœud maître a terminé la persistance RDB, il envoie des fichiers RDB d'instantané à tous les nœuds esclaves et continue d'enregistrer les commandes d'écriture exécutées pendant l'envoi de l'instantané.

• Après avoir reçu le fichier d'instantané, le nœud esclave supprime toutes les anciennes données (toutes les données seront effacées) et charge l'instantané reçu.

• Une fois l'instantané du nœud maître envoyé et le nœud esclave charge l'instantané, le nœud maître commence à envoyer la commande d'écriture dans le tampon au nœud esclave.

• Le nœud esclave termine le chargement de l'instantané, commence à recevoir des demandes de commandes et exécute des commandes d'écriture à partir du tampon de base de données principal. (Initialisation terminée à partir de la base de données)

• Chaque fois que le nœud maître exécute une commande d'écriture, il enverra la même commande d'écriture au nœud esclave, et le nœud esclave reçoit et exécute la commande d'écriture reçue. (Opération de propagation de commande, opération une fois l'initialisation du nœud esclave terminée)

Le processus de synchronisation complète est le suivant :

Avant redis2.8, le nœud esclave utilisait la synchronisation complète, qu'il soit initialisé ou déconnecté et reconnecté. méthode, dans les versions postérieures à 2.8, la commande PSYNC est introduite, et il sera jugé s'il convient d'utiliser la synchronisation incrémentielle après la déconnexion et la reconnexion du nœud esclave.

3.2 Synchronisation incrémentielle

PSYNC dispose de modes de resynchronisation complète des données et de synchronisation incrémentielle.

• Resynchronisation complète : elle est fondamentalement la même que l'ancienne version de copie et peut être comprise comme une copie "complète".

• Resynchronisation partielle : Lorsque l'esclave est déconnecté et reconnecté, dans la phase de propagation des commandes, seules les commandes exécutées pendant la période de déconnexion du maître doivent être envoyées à l'esclave, ce qui peut être compris comme une réplication "incrémentale". .

Il existe trois concepts importants dans le processus d'exécution de PSYNC : runid, offset (copie offset) et copie du tampon de backlog.

1.runid

Chaque serveur Redis aura un identifiant qui indique son identité. L'ID envoyé dans PSYNC fait référence à l'ID du Maître précédemment connecté. Si cet ID n'est pas enregistré, la commande PSYNC utilisera le formulaire "PSYNC? -1" pour l'envoyer au Maître, indiquant qu'une copie complète est requise.

2.offset (décalage de réplication)

Le maître et l'esclave dans la réplication maître-esclave maintiendront chacun un décalage. Une fois que le maître a envoyé avec succès la commande de N octets, le décalage dans le maître sera augmenté de N. Une fois que l'esclave aura reçu la commande de N octets, l'esclave augmentera également le décalage dans l'esclave de N. Si les statuts du maître et de l'esclave sont cohérents, leurs décalages doivent également être cohérents.

3. Tampon de backlog de copie

Le tampon de backlog de copie est une file d'attente de backlog circulaire de longueur fixe (file d'attente FIFO) maintenue par le maître. Sa fonction est de mettre en cache les commandes qui ont été propagées. Lorsque le maître propage des commandes, il envoie non seulement les commandes à tous les esclaves, mais écrit également les commandes dans le tampon du backlog de réplication. La différence entre le processus d'exécution de PSYNC et de SYNC est que lorsque le salve est connecté, il est jugé si une synchronisation complète est requise. Le processus logique de synchronisation complète est le même que celui de SYNC. Les étapes d'exécution de PSYNC sont les suivantes :

• Le client envoie la commande SLAVEOF au serveur, c'est-à-dire que lorsque l'esclave initie une demande de connexion au maître, l'esclave détermine s'il s'agit de la première connexion en fonction du fait qu'il enregistre le runid maître.

• S'il s'agit de la première synchronisation, la commande PSYNC ? -1 sera envoyée au Maître pour une synchronisation complète ; s'il s'agit d'une reconnexion, la commande PSYNC runid offset sera envoyée au Maître (runid est l'ID d'identité) du maître, et le décalage est la synchronisation du nœud esclave (le montant de la migration globale de la commande).

• Après avoir reçu la commande PSYNC, le maître détermine d'abord si le runid est cohérent avec l'identifiant de la machine locale, s'il est cohérent, il déterminera à nouveau si le décalage et le décalage de la machine locale dépassent la copie. Si ce n'est pas le cas, envoyez CONTINUE à l'esclave. À ce moment, l'esclave n'a plus qu'à attendre que le maître renvoie la commande perdue lors de la perte de connexion. Si le runid est incohérent avec l'ID local ou si l'écart de décalage dépasse la taille du tampon du backlog de copie, alors le décalage du runid FULLRESYNC sera renvoyé et l'esclave enregistrera le runid et effectuera une synchronisation complète.

Lorsque le nœud maître propage les commandes, la base de données maître transmettra chaque commande d'écriture à la base de données esclave, et en même temps, elle stockera la commande d'écriture dans la file d'attente du backlog et enregistrera le décalage global de la commande stockée dans la file d'attente actuelle du retard. Lorsque le salve se reconnecte, le maître trouvera les commandes exécutées pendant la période de déconnexion dans la file d'attente de l'anneau en fonction du décalage transmis par le nœud esclave, et les synchronisera avec le nœud salve pour obtenir des résultats de synchronisation incrémentiels.

Le processus d'exécution PSYNC est comme indiqué ci-dessous :

D'après le processus d'exécution PSYNC ci-dessus, nous pouvons voir que lorsque le nœud esclave est déconnecté et reconnecté, le noyau pour déterminer s'il faut utiliser la synchronisation incrémentielle est le décalage du nœud esclave. l'esclave et le décalage du maître. Si la différence dépasse la taille du tampon du backlog de copie, cette taille est configurée par les paramètres suivants. Le tampon du backlog de réplication est essentiellement une file d'attente circulaire de longueur fixe. Par défaut, la taille de la file d'attente du backlog est de 1 Mo. La taille de la file d'attente peut être définie via le fichier de configuration : Plus la taille du tampon du backlog de réplication est grande. plus la base de données maître-esclave peut être déconnectée. Plus cela prend de temps

repl-backlog-size 1mb

Redis fournit également le temps nécessaire pour libérer la file d'attente en anneau lorsqu'il n'y a pas d'esclave à synchroniser. La valeur par défaut est d'une heure. connexion, à quelle fréquence le tampon du backlog de réplication est libéré

repl-backlog-ttl 3600

四、主从复制策略

Redis采用了乐观复制的策略，也就是在一定程度内容忍主从数据库的内容不一致，但是保持主从数据库数据的最终一致性。具体来说，Redis在主从复制的过程中，本身就是异步的，在主从数据库执行完客户端请求后会立即将结果返回给客户端，并异步的将命令同步给从数据库，但是这里并不会等待从数据库完全同步之后，再返回客户端。这一特性虽然保证了主从复制期间性能不受影响，但是也会产生一个数据不一致的时间窗口，如果在这个时间窗口期间网络突然断开连接，就会导致两者数据不一致。如果不在配置文件中添加其他策略，那就默认会采用这种方式。为了防止主从不一致不可控，redis提供了以下两个参数来做约束：

min-slaves-to-write 3
min-slaves-max-lag 10

当slave数量小于min-slaves-to-write，且延迟小于等于min-slaves-max-lag时，master停止写入操作。

还有一个参数也会影响主从之间的延时：

repl-disable-tcp-nodelay：

设置成yes，则redis会合并小的TCP包从而节省带宽，但会增加同步延迟，造成master与slave数据不一致。设置成no，则redis master会立即发送同步数据，几乎没有延迟。

Redis的主从同步无论那种场景可以抽象为以下七个步骤：

1.建立socket连接

从服务器根据设置的套接字创建连向主服务器的套接字连接，主服务器接收从服务器的套接字连接之后，为该套接字创建响应的客户端状态，并将此时的从服务器看做是主服务器的客户端，也就是该从服务器同时具备服务器与客户端两个身份。

2.发送PING命令

PING命令主要有两种作用：虽然建立了套接字连接，但是还未使用过，通过发送PING命令检查套接字的读写状态是否正常；通过发送PING命令检查主服务器能否正常处理命令请求，能处理主服务器回复PONG。

3.身份验证

从服务器接收到主服务器返回的“PONG”回复，接下来就需要考虑身份验证的事。如果从服务器设置了masterauth选项，那么进行身份验证，如果从服务器没有设置masterauth选项，那么不进行身份验证。

4.发送端口信息

在身份验证步骤之后，从服务器将执行命令REPLCONF listening-port ，向主服务器发送从服务器的监听端口号。

5.数据同步

从服务器向主服务器发送SYNC命令、PSYNC命令，执行同步操作。

6.命令传播

主从服务器就会进入命令传播阶段，主服务器只要将自己执行的写命令发送给从服务器，而从服务器只要一直执行并接收主服务器发来的写命令。

五、告一段落

本篇详细介绍了redis主从同步机制，不同场景下同步策略的选择，这也是redis高可用的基石。在此基础上，下一篇将对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!