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

Le sens littéral de la synchronisation maître-esclave est qui est le maître et qui est l'esclave, et ils sont effectués simultanément pour former un effet de synchronisation. Alors, que savez-vous de la synchronisation maître-esclave de Redis ? Cet article présente principalement l'analyse de synchronisation maître-esclave de Redis. J'espère qu'il pourra aider tout le monde.

1. Principe de synchronisation maître-esclave Redis

1.1 Processus de synchronisation maître-esclave Redis

Après avoir configuré le maître connecté au serveur esclave, le l'esclave sera établi Connectez-vous au maître puis envoyez la commande de synchronisation. Qu'il s'agisse de la connexion établie pour la première synchronisation ou de la reconnexion après la déconnexion de la connexion, le maître démarrera un processus en arrière-plan pour enregistrer l'instantané de la base de données dans un fichier. En même temps, le processus principal principal commencera à collecter de nouvelles écritures. commandes et mettez-les en cache. Lorsque le processus en arrière-plan termine l'écriture du fichier, le maître envoie le fichier d'instantané à l'esclave. L'esclave enregistre le fichier sur le disque, puis le charge en mémoire pour restaurer l'instantané de la base de données sur l'esclave. Une fois que l'esclave a terminé la récupération du fichier d'instantané, le maître transmettra toutes les commandes mises en cache à l'esclave et celui-ci mettra à jour la base de données mémoire. Les commandes d'écriture ultérieures reçues par le maître seront envoyées à l'esclave via la connexion initialement établie. Les commandes pour synchroniser les données du maître vers l'esclave et les commandes envoyées du client vers le maître utilisent le même format de protocole. Lorsque la connexion entre le maître et l'esclave est déconnectée, l'esclave peut automatiquement rétablir la connexion. Si le maître reçoit des commandes de connexion synchrone de plusieurs esclaves en même temps, il lancera uniquement un processus pour écrire le miroir de la base de données, puis l'enverra à tous les esclaves.

1.2 Caractéristiques de la synchronisation maître-esclave Redis

La synchronisation maître-esclave présente des caractéristiques de cache distribué évidentes, comprenant principalement les aspects suivants :

1) Un maître peut avoir plusieurs esclaves, et un esclave peut également avoir plusieurs esclaves
2) Un esclave peut non seulement se connecter au maître, mais un esclave peut également se connecter à d'autres esclaves pour former une arborescence ; 🎜>3) Synchronisation maître-esclave Elle ne bloquera pas le maître, mais elle bloquera l'esclave. C'est-à-dire que lorsqu'un ou plusieurs esclaves synchronisent pour la première fois les données avec le maître, celui-ci peut continuer à traiter les requêtes du client. Au contraire, lorsque l'esclave synchronise les données pour la première fois, il bloquera et sera incapable de traiter la demande du client
4) La synchronisation maître-esclave peut être utilisée pour améliorer l'évolutivité du système ; esclaves pour gérer spécifiquement la demande de lecture du client, ou nous pouvons utiliser Pour faire une simple redondance des données ou persister uniquement sur l'esclave pour améliorer les performances globales du cluster.

1.3 Méthode de paramétrage de la synchronisation active Redis

Il existe deux façons de finaliser le paramétrage de la synchronisation du serveur Redis maître-esclave. Tout doit être fait sur le serveur esclave, en spécifiant le serveur Redis auquel l'esclave doit se connecter (il peut s'agir du maître ou de l'esclave).

1.3.1 Défini dans le fichier de configuration

Défini dans le fichier de configuration (redis.conf) du serveur Redis en tant qu'esclave.

Code Conf

slaveof 10.1.1.102 6379 #指定master的ip和端口

Evidemment, cette méthode de paramétrage est très simple, mais elle nécessite de modifier le fichier de configuration, et le fichier de configuration est en Chargé au démarrage du serveur. Le serveur ne peut donc pas être modifié sans démarrer et le fonctionnement est peu flexible.

Cette méthode de configuration convient comme configuration initiale lors du déploiement.

1.3.2 Mise en place dans le client Redis

Nous prenons ici comme exemple les Jedis officiellement recommandés par Redis. Les tests de l'article suivant sont également basés sur. Jedi. L'instance d'objet jedis appartient ici à l'esclave, et les paramètres sont l'adresse et le port du serveur.

Code Java

slaveJdedis.slaveOf("10.1.1.102", 6379); #指定master的ip和端口 
slaveJdedis.slaveofNoOne(); #取消指定master，自己成为一个master了

Vous pouvez facilement modifier le maître et l'esclave des serveurs maître et esclave via la méthode spécifiée par la relation client. Cette méthode est donc très adaptée pour ajuster les serveurs maître et esclave en ligne selon les besoins.

1.3.3 Problèmes avec la synchronisation maître-esclave actuelle

Étant donné que les serveurs maître et esclave ne sont pas automatiquement élus par Redis et nécessitent une participation manuelle, la commutation maître-esclave ne peut pas être une finition automatique. Cela soulève la question de savoir quand et qui doit déclencher le changement. J'ai vérifié que le client ne dispose pas de cette fonctionnalité. Si nécessaire, vous devez l'ajouter vous-même.

Jedis sélectionne actuellement de manière aléatoire le serveur Redis à partir duquel lire, donc pour implémenter la lecture distribuée automatique, nous devons réencapsuler Jedis.

1) Un mécanisme doit être développé pour détecter l'état de fonctionnement du maître et de l'esclave dès que possible

2) Une stratégie de commutation automatique pour le maître et l'esclave doit être définie ; 🎜>3) Obligatoire Définir un mécanisme capable de lire aléatoirement n'importe quel serveur Redis


Ces fonctions peuvent être implémentées côté client, mais l'effet ne sera pas très bon. Ce serait parfait si le serveur lui-même pouvait le prendre en charge. Cependant, à en juger par l'introduction sur le site officiel de Redis, il semble que personne n'ait encore fait une telle demande et qu'un tel plan n'existe pas.

2. Introduction aux clients grand public Redis

Sur le site officiel de Redis, 5 logiciels clients Java pour Redis sont répertoriés. Parmi eux, Jedis est le client java officiellement recommandé par Redis, qui a été maintenu et mis à jour. Actuellement, la dernière version stable du serveur est Redis2.4.17 et la dernière version de test est Redis 2.6.0 RC7.

2.1 Jedis

Jedis est la version client Java officiellement recommandée de Redis. La dernière version est actuellement Jedis 2.1.0-5, qui est entièrement compatible avec la version 2.0.0 de Redis. Ce client est toujours maintenu et mis à jour.

2.2 JRedis

JRedis n'a pas été mis à jour depuis longtemps et est entièrement compatible avec la version Redis 2.0.0. Après avoir été mis à jour avant mai aujourd'hui, il peut être compatible avec la dernière version de test Redis2.6.0.

2.3 JDBC-Redis

JDBC-Redis est le pilote JDBC pour la base de données NoSQL Redis. Vous ne pouvez télécharger que la version jdbc-redis_0.1_beta publiée en mars 2009, qui n'est actuellement plus maintenue.

2.4 RJC

RJC fournit un pool de connexions de style Apache DBCP. Les mises à jour ont été arrêtées il y a 1 an et sont entièrement compatibles avec la version Redis 2.0.0.

2.5 redis-protocol

Cette mise à jour est la plus rapide et la plus fréquente et est compatible avec la dernière version de Redis 2.6.0. Cependant, il est positionné pour prendre entièrement en charge le protocole Redis et interagir plus efficacement avec le serveur Redis. Par conséquent, les fonctions du serveur Redis ne sont pas pleinement utilisées.

2.6 Évaluation globale de chaque client Java

Dans l'ensemble, chaque client implémente essentiellement les fonctions de base définies par le protocole Redis. La récente mise à jour du protocole Redis offre la prise en charge la plus complète du protocole Redis ; Jedis fournit davantage d'opérations de configuration pour le serveur Redis et est la plus pratique à utiliser. Les autres clients sont rarement entretenus et leurs fonctions sont moyennes.

Si vous souhaitez étendre un peu les fonctionnalités du client, le développement basé sur Jedis est le moyen le plus rapide.

Si vous souhaitez maximiser la compatibilité et étendre les fonctions client, le protocole Redis est le meilleur choix.

3. Suggestions pour l'utilisation de la synchronisation maître-esclave Redis

La synchronisation maître-esclave Redis n'est pas bien prise en charge par tous les clients Java actuels. La raison principale devrait être due aux limitations du mécanisme de mise en œuvre du serveur Redis lui-même. C’est possible si vous devez le faire, mais l’effet peut être compromis.

3.1 Implémenté en encapsulant Jdedis

1) Ajouter une classe de gestion, responsable du maintien de la relation topologique du serveur du cluster de serveurs Redis
2) Ajouter un ; nouveau La classe de surveillance est chargée de surveiller et de maintenir l'état d'exécution du serveur dans le cluster de serveurs Redis
3) Ajouter une nouvelle classe de stratégie de sélection de maître, qui est responsable de déterminer le moment de commutation entre le maître et l'esclave et de sélectionner le plus serveur Redis approprié pour agir en tant que maître.
4) Ajoutez une classe proxy pour prendre en charge les opérations de lecture et d'écriture du client Jedis actuel sur le serveur Redis. La couche application utilise le client Jedis via la classe proxy. La classe proxy doit garantir que le cluster de serveurs Redis est transparent pour la couche application.

Recommandations associées :

Explication détaillée de l'exemple de code de configuration de la synchronisation maître-esclave Mysql

Introduction détaillée à la mise en œuvre de Mysql master- principe de synchronisation esclave (image et texte)

Script shell de surveillance de la synchronisation maître-esclave MySQL sous Linux

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!