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.
slaveof 10.1.1.102 6379 #指定master的ip和端口
slaveJdedis.slaveOf("10.1.1.102", 6379); #指定master的ip和端口 slaveJdedis.slaveofNoOne(); #取消指定master,自己成为一个master了
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 :
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!