Quels sont les modes de cluster de Redis ?

Il existe généralement 5 types de clusters Redis :

1, réplication maître-esclave

2, mode sentinelle

3, Cluster officiellement fourni par le mode Redis Cluster (serveur)

4, cluster de sharding Jedis (sharding client)

5, utilisant des agents middleware, tels que les codis de Wandoujia, etc.

Après avoir présenté leurs modèles, analysons leurs principes :

Réplication maître-esclave :

Comment fonctionne la réplication maître-esclave : Une fois que le service du nœud esclave esclave démarre et se connecte au maître, il enverra activement une commande SYNC. Après avoir reçu la commande de synchronisation, le nœud maître du service maître démarrera le processus de sauvegarde en arrière-plan et collectera toutes les commandes reçues pour modifier l'ensemble de données. Une fois le processus en arrière-plan terminé, le maître transférera l'intégralité du fichier de base de données vers l'esclave pour terminer une opération complète. synchronisation. Le service de nœud esclave esclave enregistre et charge les données du fichier de base de données en mémoire après les avoir reçues. Après cela, le nœud maître continue de transmettre toutes les commandes de modification collectées et les nouvelles commandes de modification aux esclaves en séquence. Les esclaves exécuteront cette fois ces commandes de modification de données pour réaliser la synchronisation finale des données.

Si le lien entre le maître et l'esclave est déconnecté, l'esclave peut se reconnecter automatiquement au maître, mais une fois la connexion réussie, une synchronisation complète sera automatiquement effectuée.

Configuration de la réplication maître-esclave

Modifier le fichier de configuration du nœud esclave : slaveof masterip masterport

Si un mot de passe est défini, définissez-le : masterauth master- password

Mode Sentinelle :

Ce mode est fourni à partir de la version 2.6 de Redis, mais le mode de cette version à cette époque était instable jusqu'à la version 2.8 de Redis Plus tard, le mode sentinelle est devenu stable. Qu'il s'agisse du mode maître-esclave ou du mode sentinelle, ces deux modes ont un problème : ils ne peuvent pas s'étendre horizontalement, et les fonctionnalités de haute disponibilité de ces deux modes seront limitées par la mémoire du. Nœud maître.

Le processus Sentinel est utilisé pour surveiller l'état de fonctionnement du serveur maître dans le cluster Redis. Lorsque le serveur maître tombe en panne, les serveurs maître et esclave peuvent être commutés pour garantir la haute disponibilité du système.

Le rôle du processus Sentinel

Surveillance : Sentinel vérifiera en permanence si votre maître et votre esclave fonctionnent normalement.

Notification : lorsqu'il y a un problème avec un nœud Redis surveillé, la sentinelle peut envoyer des notifications à l'administrateur ou à d'autres applications via l'API.

Basculement automatique : lorsqu'un maître ne fonctionne pas correctement, Sentinel lancera une opération de basculement automatique. Il mettra à niveau l'un des esclaves du maître défaillant vers un nouveau maître et laissera les autres esclaves du maître défaillant copier. le nouveau maître ; lorsque le client tente de se connecter au maître défaillant, le cluster renverra également l'adresse du nouveau maître au client, afin que le cluster puisse utiliser le maître actuel pour remplacer le maître défaillant. Une fois les serveurs maître et esclave commutés, le contenu des fichiers de configuration redis.conf du maître, redis.conf et sentinel.conf de l'esclave changera en conséquence, c'est-à-dire qu'il y aura une ligne supplémentaire de slaveof dans la configuration redis.conf du maître. Configuration, la cible de surveillance de sentinel.conf sera modifiée en conséquence.

Fonctionnement du processus Sentinel

Chaque processus Sentinel envoie des messages au serveur maître et au serveur esclave de l'ensemble du cluster une fois par seconde. Envoyez une commande PING depuis le serveur. et d'autres processus Sentinel.

Si le temps écoulé depuis la dernière réponse valide à la commande PING dépasse la valeur spécifiée par l'option down-after-milliseconds, l'instance sera marquée comme subjectivement hors ligne (SDOWN) par le processus Sentinel )

Si un serveur maître est marqué comme subjectivement hors ligne (SDOWN), tous les processus Sentinel qui surveillent le serveur maître doivent confirmer que le serveur maître est effectivement entré une fois par seconde dans l'état subjectif hors ligne

Lorsqu'un. un nombre suffisant de processus Sentinel (supérieur ou égal à la valeur spécifiée dans le fichier de configuration) confirment que le serveur maître est entré dans l'état subjectif hors ligne (SDOWN) dans la plage de temps spécifiée, puis le serveur maître sera marqué comme objectivement hors ligne ( ODOWN)

Dans des circonstances normales, chaque processus Sentinel informera tous les serveurs maîtres et esclaves du cluster une fois toutes les 10 secondes. Le serveur envoie une commande INFO.

Lorsque le serveur maître est marqué comme objectivement hors ligne (ODOWN) par le processus Sentinel, la fréquence du processus Sentinel envoyant des commandes INFO à tous les serveurs esclaves du serveur maître hors ligne passera de Modifié d'une fois tous les 10. secondes à une fois par seconde.

S'il n'y a pas suffisamment de processus Sentinel pour accepter que le serveur maître soit hors ligne, le statut objectif hors ligne du serveur maître sera supprimé. Si le serveur maître envoie à nouveau la commande PING au processus Sentinel et renvoie une réponse valide, l'état subjectif hors ligne du serveur maître sera supprimé.

Mode Cluster officiel de Redis

Redis Cluster est une technologie de Sharding de serveur, officiellement disponible depuis la version 3.0.

Dans cette image, chaque cercle bleu représente un nœud de serveur Redis. Deux de leurs nœuds sont connectés l’un à l’autre. Le client peut se connecter à n'importe quel nœud, puis accéder à n'importe quel nœud du cluster. Effectuez l’accès et d’autres opérations dessus.

Partagement des données du cluster Redis

Sur chaque nœud de Redis, il y a deux choses, l'une est l'emplacement, qui peut être compris comme une variable A qui peut stocker deux valeurs. La plage de valeurs de cette variable est : 0-16383. Un autre est le cluster. Personnellement, je comprends ce cluster comme un plug-in de gestion de cluster. Lorsque notre clé d'accès arrive, redis obtiendra un résultat basé sur l'algorithme crc16, puis calculera le reste du résultat à 16384, de sorte que chaque clé correspondra à un emplacement de hachage numéroté entre 0 et 16383, à travers Cette valeur est utilisée pour trouver le nœud correspondant à l'emplacement correspondant, puis sauter automatiquement directement au nœud correspondant pour les opérations d'accès.

Cluster de partitionnement Jedis

Redis Sharding peut être considéré comme une méthode courante utilisée dans l'industrie avant la sortie du cluster Redis. Son idée principale est d'utiliser le hachage. algorithme pour stocker la clé du hachage des données, de sorte qu'une clé spécifique soit attribuée à un nœud spécifique.

Heureusement, le pilote client Java Redis Jedis prend déjà en charge la fonction Redis Sharding, à savoir ShardedJedis et ShardedJedisPool combinés avec le pool de cache

L'implémentation Redis Sharding de Jedis a les caractéristiques suivantes :

Utilisez un algorithme de hachage cohérent pour hacher la clé et le nom du nœud en même temps, puis effectuez une correspondance de mappage. L'algorithme utilisé est MURMUR_HASH. La principale raison de l'utilisation d'un hachage cohérent au lieu d'un simple mappage modulo de type hachage est que lorsque des nœuds sont ajoutés ou supprimés, le rehachage dû à la rematching ne se produira pas. Un hachage cohérent n'affecte que l'allocation de clé des nœuds adjacents et l'impact est faible.

Afin d'éviter un hachage cohérent affectant uniquement les nœuds adjacents et provoquant une pression d'allocation de nœuds, ShardedJedis virtualisera 160 nœuds virtuels en fonction du nom de chaque nœud Redis (sinon, Jedis attribuera un nom par défaut). Selon le poids, 160 fois les nœuds virtuels peuvent également être virtualisés. L'utilisation de nœuds virtuels pour la correspondance de mappage permet de déplacer et de répartir les clés plus uniformément entre les nœuds Redis lors de l'ajout ou de la réduction de nœuds Redis, au lieu que seuls les nœuds adjacents soient affectés.

ShardedJedis prend en charge le mode keyTagPattern, qui consiste à extraire une partie du keyTag pour le partitionnement. De cette façon, en nommant la clé de manière appropriée, un groupe de clés associées peut être placé dans le même nœud Redis, ce qui évite d'y accéder. données associées entre les nœuds. Très important.

Utiliser un agent middleware

Le rôle du middleware est de calculer la clé des données que nous devons stocker dans Redis via un ensemble d'algorithmes pour calculer une valeur. Recherchez ensuite le nœud redis correspondant en fonction de cette valeur et stockez les données dans ce nœud redis.

Les middlewares couramment utilisés incluent les éléments suivants

Twemproxy

Codis

nginx

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!