Une brève analyse du principe de la réplication maître-esclave du cluster dans Redis

Cet article vous donnera une compréhension approfondie du principe de réplication maître-esclave du cluster Redis. J'espère qu'il vous sera utile !

1. Réfléchissez d'abord à une question : pourquoi Redis a-t-il besoin d'une solution distribuée alors que ses performances sont si élevées ?

1. Obtenez des performances plus élevées : pour les applications à haute concurrence, les performances d'une seule machine seront affectées et davantage de serveurs Redis sont nécessaires pour partager la pression et réaliser l'équilibrage de charge

2. éviter les temps d'arrêt/pannes matérielles

3. Atteindre l'évolutivité : la mémoire et le matériel d'une seule machine sont limités, et une expansion horizontale peut être réalisée

Un stockage redondant ou fragmenté peut atteindre les fonctionnalités ci-dessus.

2. Configuration de réplication-réplication maître-esclave

Comme Kafka, Mysql et Rocketmq, redis prend en charge le déploiement de cluster. Les nœuds du cluster sont divisés en maître et esclave. esclave (la dernière est appelée réplique).slave synchronisera les dernières données du maître via le mécanisme de réplication. Redis fournit une commande très pratique pour activer la réplication maître-esclave. [Recommandations associées : Tutoriel vidéo Redis]

Comment configurer et activer la réplication maître-esclave ?

Prenons l'exemple de la création d'un pseudo cluster localement. Le port 6379 est le nœud esclave et le port 6378 est le nœud maître.

1. Configurez la réplique du masterip masterport dans redis.conf du nœud esclave, il se connectera automatiquement au nœud maître et commencera à synchroniser les données

Si un nouveau nœud maître est remplacé, cette configuration sera réécrite.

2. Ou spécifiez

./redis-server --replicaof masterip masterport

lors du démarrage du programme redis-server. 3. Ou connectez-vous au client et exécutez la commande suivante

slaveof masterip masterport

Notez que cette méthode est modifiée pendant le fonctionnement et peut réaliser un basculement

Remarque : A. nœud esclave Il peut également être le nœud maître d'autres nœuds pour former une relation de réplication en cascade. Mais d'autres nœuds synchronisent également les données du nœud maître de niveau supérieur.

Après avoir configuré le cluster, vérifiez l'état du cluster via la réplication des informations

Utilisez la commande role pour afficher les informations sur le rôle du nœud dans le cluster

Notez que le nœud esclave est en lecture seule . Une erreur sera signalée lors de l'écriture de la commande.

Comment l'esclave quitte-t-il le cluster ? Vous pouvez exécuter la commande suivante :

slaveof no one

3. Processus de réplication maître-esclave

1. Tout d'abord, la réplique-réplique rejoint le cluster

.

2. Établissez avec la connexion principale, vérifiez régulièrement via la minuterie s'il faut synchroniser les données du nœud maître

Description du code source :

//每1s执行这个方法
void replicationCron(void) {
    ...
    //检查是否需要连接到master 如果是REPL_STATE_CONNECT状态，必须连接到master
    //#define REPL_STATE_CONNECT 1  Must connect to master 
    if (server.repl_state == REPL_STATE_CONNECT) {
        serverLog(LL_NOTICE,"Connecting to MASTER %s:%d",
            server.masterhost, server.masterport);
        //和master创建连接    
        if (connectWithMaster() == C_OK) {
            serverLog(LL_NOTICE,"MASTER <-> REPLICA sync started");
        }
    }
    
    //发送ping命令给slave 
    if ((replication_cron_loops % server.repl_ping_slave_period) == 0 &&
        listLength(server.slaves))
    {
        /* Note that we don&#39;t send the PING if the clients are paused during
         * a Redis Cluster manual failover: the PING we send will otherwise
         * alter the replication offsets of master and slave, and will no longer
         * match the one stored into &#39;mf_master_offset&#39; state. */
        int manual_failover_in_progress =
            server.cluster_enabled &&
            server.cluster->mf_end &&
            clientsArePaused();

        if (!manual_failover_in_progress) {
            ping_argv[0] = createStringObject("PING",4);
            replicationFeedSlaves(server.slaves, server.slaveseldb,
                ping_argv, 1);
            decrRefCount(ping_argv[0]);
        }
    }
    
    //发送换行符到所有slave,告诉slave等待接收rdb文件
    listRewind(server.slaves,&li);
    while((ln = listNext(&li))) {
        client *slave = ln->value;

        int is_presync =
            (slave->replstate == SLAVE_STATE_WAIT_BGSAVE_START ||
            (slave->replstate == SLAVE_STATE_WAIT_BGSAVE_END &&
             server.rdb_child_type != RDB_CHILD_TYPE_SOCKET));

        if (is_presync) {
            if (write(slave->fd, "\n", 1) == -1) {
                /* Don&#39;t worry about socket errors, it&#39;s just a ping. */
            }
        }
    }
    ...
}

3.

Lorsque l'esclave est connecté Après être arrivé au maître, utilisez la commande psync (anciennement la commande sync, qui ne permet pas la resynchronisation partielle, utilisez donc maintenant PSYNC à la place) pour initialiser la réplication et envoyer l'identifiant de réplication du nœud maître et le décalage maximum traité au maître.

Le nœud maître a les deux attributs suivants, un identifiant de réplication (instance de marque), un offset (marque écrite dans le flux du nœud esclave)

Replication ID, offset

S'il n'y a pas suffisamment de travail en retard dans le tampon du nœud maître, ou si la réplique référencée est un enregistrement historique (ID de réplication) qui n'est plus connu, une resynchronisation complète aura lieu

Description du code source :

    //没有在rdb进程，没有aof重写进程
    if (server.rdb_child_pid == -1 && server.aof_child_pid == -1) {
        time_t idle, max_idle = 0;
        int slaves_waiting = 0;
        int mincapa = -1;
        listNode *ln;
        listIter li;

        listRewind(server.slaves,&li);
        while((ln = listNext(&li))) {
            client *slave = ln->value;
            //判断slave是否是等待bgsave状态
            if (slave->replstate == SLAVE_STATE_WAIT_BGSAVE_START) {
            //多久没有发送心跳或查询数据了 空闲时间间隔
                idle = server.unixtime - slave->lastinteraction;
                if (idle > max_idle) max_idle = idle;
                slaves_waiting++;
                mincapa = (mincapa == -1) ? slave->slave_capa :
                                            (mincapa & slave->slave_capa);
            }
        }

        if (slaves_waiting &&
            (!server.repl_diskless_sync ||
             max_idle > server.repl_diskless_sync_delay))
        {
            /* Start the BGSAVE. The called function may start a
             * BGSAVE with socket target or disk target depending on the
             * configuration and slaves capabilities. */
             //bgsave rdb生成
            startBgsaveForReplication(mincapa);
        }
    }

Pendant le processus de réplication, le processus de transition de l'état esclave.

4. Lors de l'étape de propagation des commandes, une fois la synchronisation complète effectuée, le maître et l'esclave propageront les commandes pour assurer la cohérence des données.

4. Comprendre l'ID de réplication

Chaque fois qu'une instance est redémarrée à partir de zéro en tant qu'instance principale, ou qu'une réplique est promue en instance principale, un nouvel ID de réplication sera généré pour cette instance. Si deux réplicas ont le même ID de réplication, ils peuvent avoir les mêmes données à des moments différents. Pour un historique donné (ID de réplication) contenant le dernier ensemble de données, le décalage est compris comme une heure logique. Il doit être jugé par les deux données de l'ID de réplication et du décalage. Utilisé pour déterminer où le nœud esclave a synchronisé les données.

5. Questions courantes sur la réplication maître-esclave

1. Que se passera-t-il si l'esclave lui-même possède des données ?

slave supprime d'abord ses propres données, puis les charge avec un fichier rdb.

2. Pendant le processus de génération des fichiers RDB, comment gérer les commandes écrites par le client ?

Enregistrez dans le cache mémoire et envoyez-le à l'esclave après l'envoi du rdb.

3. Comment la réplication Redis gère-t-elle l'expiration des clés ?

1. La copie n'expirera pas la clé, mais attendra que l'hôte expire la clé. Lorsque le maître expire une clé (ou l'expulse en raison de LRU), il synthétise une commande DEL qui est transmise à toutes les répliques.

2. Cependant, en raison de l'expiration du pilote hôte, il arrive parfois que la réplique ait encore des clés de mémoire logiquement expirées car le serveur maître ne peut pas fournir la commande DEL à temps. Pour résoudre ce problème, la réplique utilise son horloge logique pour signaler qu'une clé n'existe pas et n'est utilisée que pour les opérations de lecture qui ne violent pas la cohérence de l'ensemble de données (car de nouvelles commandes du maître arriveront)

3 . Exécuter dans le script Lua Pendant cette période, l'expiration de la clé ne sera pas effectuée. Lorsqu'un script Lua est exécuté, le temps est conceptuellement figé dans le nœud maître, de sorte qu'une clé donnée existera ou non pendant toute la durée d'exécution du script. Cela empêche la clé d'expirer au milieu d'un script et d'exiger que la clé envoie le même script au réplica d'une manière qui garantit le même effet dans l'ensemble de données.

Une fois qu'une réplique est promue au rang principal, elle commencera à expirer les clés de manière indépendante et ne nécessite aucune aide de la part de l'ancien réplica principal.

6. Résumé de la réplication maître-esclave

1. Le problème de la sauvegarde des données est résolu, mais le fichier RDB est volumineux, les fichiers volumineux sont transférés et le temps de récupération est également long

2. anormal, la réplique doit être élue manuellement comme maître

3 Dans le cas de 1 maître et de plusieurs esclaves, il y a toujours un problème unique

4 Redis version 2.8.18 et ultérieure prend en charge la réplication sans disque, avec des versions supérieures. performance.

7. Instructions de réplication

1. La réplication asynchrone est utilisée par défaut et le nombre de commandes synchronisées est confirmé par l'asynchronisme

2. Un maître peut avoir plusieurs copies

3. copie, à partir de redis4 À partir de .0, les répliques recevront exactement le même flux de réplication du nœud maître

4 La réplication peut être utilisée à la fois pour l'évolutivité et pour plusieurs répliques de requêtes en lecture seule

Pour plus de connaissances liées à la programmation, veuillez. visite : Introduction à la programmation ! !

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!