Le cluster Redis est une solution de base de données distribuée fournie par Redis. Le cluster utilise le partitionnement pour partager des données et fournit des fonctions de réplication et de basculement.

1. Nœud

3. Exécutez les commandes dans le cluster

4. Repartage

5. Erreur ASK

6. Réplication et basculement

7. Pourquoi le nombre d'emplacements Redis est-il de 16384

1. Nœud

1.1 Démarrez le nœud

Un nœud est un serveur Redis s'exécutant dans un cluster. Lorsque le serveur Redis est démarré, il décide d'activer ou non le mode cluster du serveur selon que l'option de configuration activée pour le cluster est oui. Les nœuds exécutés en mode cluster continueront à utiliser tous les composants serveur utilisés en mode autonome. Les données qui ne sont utilisées qu'en mode cluster, le nœud les enregistre dans les structures clusterNode , clusterLink et clusterState .

1.2 Plusieurs nœuds forment un cluster

Au début, chaque nœud est indépendant les uns des autres et ils sont tous dans un cluster qui ne contient que le leur. Pour constituer un cluster réellement fonctionnel, nous devons connecter les nœuds indépendants pour former un cluster à plusieurs contenus. Un cluster de nœuds . Le travail de connexion de chaque nœud peut être complété en utilisant la commande CLUSER MEET , le format de la commande est le suivant:

CLUSER MEET <ip> <port>

Lors de l'envoi de cette commande à un nœud, le nœud de nœud peut serrer la main du nœud spécifié par ip et port. Lorsque la négociation est réussie, le nœud de nœud ajoutera le nœud spécifié par ip et port au cluster où se trouve actuellement le nœud de nœud. situé. Le nombre maximal de clusters Redis est le nombre d'emplacements, qui est de 16 384 nœuds.

1.3 Structure des données du cluster

clusterNode : enregistre l'état actuel d'un nœud, tel que l'heure de création du nœud, le nom du nœud, l'époque de configuration actuelle du nœud, l'adresse IP et le numéro de port du nœud, etc. Chaque nœud utilisera cette structure de données pour enregistrer son propre état et créer une structure de données correspondante pour les autres nœuds du cluster afin d'enregistrer l'état des autres nœuds.
clusterLink : enregistre les informations pertinentes nécessaires pour se connecter au nœud, telles que les descripteurs de socket, les tampons d'entrée et les tampons de sortie.
clusterState : cette structure enregistre l'état actuel du cluster du point de vue du nœud actuel, par exemple si le cluster est en ligne ou hors ligne, combien de nœuds le cluster contient et l'époque de configuration actuelle du cluster.

2. Affectation des emplacements

Le cluster Redis enregistre les paires clé-valeur dans la base de données par partitionnement: la base de données entière du cluster est divisée en 16384 emplacements (emplacement), chaque clé de la base de données appartient à l'un de ces 16384 emplacements, et chaque nœud du cluster Il peut gérer 0 ou jusqu'à 16384 emplacements. Lorsque tous les 16 384 emplacements de la base de données sont traités par des nœuds, le cluster est à l'état en ligne. Au contraire, si un emplacement de la base de données n'est pas traité, le cluster est à l'état hors ligne.

Après avoir utilisé la commande CLUSER MEET pour connecter plusieurs nœuds au même cluster, le cluster est toujours hors ligne, car aucun des trois nœuds du cluster ne traite les emplacements. En envoyant la commande CLUSER ADDSLOTS au nœud, nous pouvons attribuer un ou plusieurs slots au nœud pour être responsable de:

CLUSER ADDSLOTS <slot> [slot ...]

Par exemple, exécutez la commande suivante pour affecter 0-5000 au noeud 7000 comme responsable:

127.0.0.1:7000> CLUSER ADDSLOTS 0 1 2 ... 5000

2.1 Enregistrer les informations d'affectation des emplacements du nœud

struct clusterNode 
{
    /* ... ... */
    unsigned char slots[16384/8];
    int numslots;
    /* ... ...  */
}

L'attribut slots est un tableau de bits binaires, qui est utilisé pour enregistrer les slots que le nœud gère
numslots enregistre le nombre d'emplacements que le nœud est responsable du traitement, c'est-à-dire le nombre de bits binaires avec une valeur de 1 dans le tableau d'emplacements.

2.2 Diffuser les informations d'affectation des emplacements du nœud

En plus d'enregistrer les slots qu'il est responsable du traitement dans l'attribut slots et l'attribut numslots de la structure clusterNode, un nœud enverra également son tableau slots à d'autres nœuds du cluster via des messages pour informer les autres nœuds qu'il est actuellement responsable du traitement Quelles machines à sous. Une fois que les autres nœuds l'ont reçu, ils enregistrent le tableau de slots dans la structure clusterNode du nœud correspondant. Par conséquent, chaque nœud du cluster saura quels nœuds du cluster sont affectés aux 16384 slots de la base de données.

2.3 Enregistrer les informations d'affectation de tous les slots du cluster

typedef struct clusterState
{
    /* ... ...  */
    clusterNode *slots[16384];
    /* ... ... */
} clusterState;

Le tableau de slots dans clusterState enregistre les informations d'affectation de tous les 16384 slots du cluster. Si le pointeur slots [i] est NULL, cela signifie que le slot i n'a été assigné à aucun nœud; si le pointeur slots [i] pointe vers une structure clusterNode, cela signifie que slot i a été affecté au nœud représenté par le structure clusterNode. Si seules les informations d'affectation des emplacements sont stockées dans le tableau clusterNode.slots de chaque nœud, certains problèmes ne peuvent pas être traités efficacement. Par exemple, pour savoir si l'emplacement i a été attribué ou quel emplacement de nœud i est affecté à, le programme doit traverser clusterState. Toutes les structures clusterNode dans le dictionnaire de nœuds, vérifiez le tableau d'emplacements de ces structures, ce processus est responsable de O (N), et en stockant toutes les informations d'attribution d'emplacements dans le tableau clusterState.slots, le le programme vérifie si le slot i est attribué ou obtenu Le nœud responsable du traitement du slot i n'a besoin que d'accéder à la valeur de clusterState.slots [i]. La complexité de cette opération est O (1).

clusterState.slots enregistre les informations d'affectation de tous les emplacements du cluster et le tableau clusterNode.slots enregistre uniquement les informations d'attribution d'emplacements du nœud représenté par la structure clusterNode. À ce stade, la clé du tableau de deux emplacements est.

3. Exécutez les commandes dans le cluster

Une fois tous les 16384 emplacements de la base de données attribués, le cluster passe à l'état en ligne. Lorsque le client envoie une commande liée à la base de données au noeud, le noeud recevant la commande déterminera à quel emplacement appartient la clé de base de données à traiter par la commande, et vérifiera si cet emplacement est attribué à lui-même.

Si l'emplacement où se trouve la clé est affecté au nœud actuel, le nœud exécute directement cette commande
Si tous les emplacements de la clé ne sont pas affectés au noeud actuel, le noeud renverra une erreur MOVED au client, demandera au client de se tourner vers le noeud correct et enverra à nouveau la commande qu'il voulait exécuter.

3.1 Calculer à quel emplacement appartient la clé

CRC16(key) & 16383

CRC (16) est utilisé pour calculer la somme de contrôle CRC-16 de la clé, et & 16383 est utilisé pour calculer un entier entre 0 et 16383 comme numéro d'emplacement de clé.

3.2 Déterminer si le slot est traité par le nœud actuel

Après avoir obtenu le numéro d'emplacement i, si clusterState.slots [i] pointe vers son propre nœud, le nœud exécute la commande. Sinon, renvoyez une erreur MOVED au client en fonction de l'adresse IP du nœud et du numéro de port enregistrés par le clusterNode pointé par clusterState.slots [i], et demandez au client de se tourner vers le nœud qui traite l'emplacement i.

3.3 Erreur MOVED

Le format de l'erreur MOVED est:

MOVED <slot> <ip> <port>

slot est l'emplacement où se trouve la clé
ip et port sont responsables du traitement de l'ip et du numéro de port du slot

En mode cluster, l'erreur MOVED ne sera pas imprimée et le client se retournera en fonction de l'erreur MOVED.

4. Repartage

L'opération de redistribution du cluster Redis peut modifier n'importe quel nombre d'emplacements qui ont été attribués à un nœud vers un autre nœud, et les paires clé-valeur appartenant à l'emplacement concerné seront également déplacées du nœud source vers le nœud cible. Le resharding est effectué par le logiciel de gestion de cluster redis-trib. Redis fournit toutes les commandes nécessaires au resharding et redis-trib effectue l'opération de resharding en envoyant des commandes au nœud source et au nœud cible. Les étapes spécifiques sont les suivantes:

1) redis-trib envoie une commande au nœud cible pour préparer le nœud cible à importer les paires clé-valeur appartenant à l'emplacement à partir du nœud source
2) redis-trib envoie une commande au nœud source pour préparer le nœud source à migrer les paires clé-valeur appartenant à l'emplacement vers le nœud cible
3) Redis-trib envoie une commande au nœud source pour obtenir jusqu'à compter les paires clé-valeur appartenant à l'emplacement.
4) Pour le nom de clé obtenu en 3), redis-trib envoie une commande au nœud source pour migrer la clé sélectionnée du nœud source vers le nœud cible
5) Répétez les étapes 3 et 4 jusqu'à ce que toutes les paires clé-valeur appartenant à l'emplacement enregistré par le nœud source soient migrées vers le nœud cible.
6) Redis-trib envoie une commande à n'importe quel nœud du cluster pour attribuer l'emplacement au nœud cible, et ces informations d'affectation seront envoyées à l'ensemble du cluster via un message.

5. Erreur ASK

Pendant le processus de re-fragmentation, pendant le processus de migration du nœud source vers le nœud cible, un scénario peut se produire, dans lequel une partie des clés appartenant à l'emplacement migré se trouve dans le nœud source, et l'autre partie des clés est dans le nœud cible. Lorsque le client envoie une commande liée à la clé de base de données à la base de données et que la clé à traiter par la commande appartient à l'emplacement en cours de migration:

Le nœud source recherchera maintenant la clé spécifiée dans sa propre base de données et, si elle est trouvée, exécutera la commande envoyée par le client
Si elle n'est pas trouvée, la clé a peut-être été migrée vers le noeud cible. Le noeud source renvoie une erreur ASK au client , le dirigeant vers le noeud cible qui importe l'emplacement et envoie la commande qu'il souhaite. processus à nouveau.

La différence entre l'erreur ASK et la commande MOVED:

Les erreurs MOVED affecteront le nœud auquel le client enverra les futures commandes
L'erreur ASK n'affectera pas le nœud pointé par les futures commandes du client

6. Réplication et basculement

6.1 Configurer le nœud esclave

Envoyez une commande à un nœud:

CLUSTER REPLICATE <node-id>

Vous pouvez faire du nœud qui reçoit la commande le nœud esclave du nœud spécifié par node-id et commencer à copier le nœud maître.

6.2 Détection des défauts

Chaque nœud du cluster envoie périodiquement des messages PING aux autres nœuds du cluster pour vérifier si l'autre partie est en ligne. Si le nœud recevant le message PING ne renvoie pas de message PONG au nœud qui envoie le message PING dans le délai spécifié , puis Le nœud envoyant le message PING marquera le nœud recevant le message PING comme un nœud hors ligne suspecté.

Dans un cluster, chaque nœud du cluster échange les informations d'état de chaque nœud du cluster en s'envoyant des messages, par exemple si un nœud est en ligne, suspecté d'être hors ligne ou hors ligne, si plus de la moitié des emplacements de traitement Tous les nœuds maîtres signalent qu'un nœud maître x est suspecté hors ligne, puis le nœud maître x sera marqué comme hors ligne et le nœud qui marque le nœud maître x comme étant hors ligne diffusera un message au cluster à propos du nœud maître x. Pour hors ligne messages, tous les nœuds qui reçoivent le message hors ligne marqueront le nœud maître x comme étant hors ligne.

6.3 Basculement

Lorsqu'un nœud esclave constate que le nœud maître qu'il réplique est entré dans l'état hors ligne, le nœud esclave démarre le basculement vers le nœud maître hors ligne. Les étapes spécifiques sont les suivantes:

Copiez le nœud esclave du nœud maître hors ligne, il y aura un nœud esclave sélectionné
Le nœud esclave sélectionné exécutera la commande SLAVEOF no one et deviendra le nouveau nœud maître
Le nouveau nœud maître révoquera toutes les attributions d'emplacements au nœud maître hors ligne et s'attribuera tous ces emplacements à lui-même
Le nouveau nœud maître diffuse un message PONG au cluster. Ce message PONG permet aux autres nœuds du cluster de savoir immédiatement que ce nœud est passé d'un nœud esclave à un nœud maître et que le nœud maître a pris le relais et est géré par le nœud hors ligne.
Le nouveau nœud maître commence à traiter et reçoit les demandes de commande liées à l'emplacement qu'il est responsable du traitement, et le basculement est terminé

7. Pourquoi le nombre d'emplacements Redis est-il de 16384

(1) Si l'emplacement est 65536, l'en-tête de message pour l'envoi des informations de pulsation atteint 8k et le paquet de pulsations envoyé est trop volumineux.

Comme dans l'en-tête du message, celui qui occupe le plus d'espace est myslots[CLUSTER_SLOTS/8]. Lorsque le slot est 65536, la taille de ce bloc est: 65536÷8÷1024=8kb。parce que chaque seconde, le nœud redis doit envoyer un certain nombre de messages ping sous forme de paquets heartbeat. Si le slot est 65536, l'en-tête de ce message ping est trop grand, ce qui gaspille de la bande passante.

(2) Le nombre de nœuds maîtres du cluster redis est pratiquement impossible à dépasser 1000

Plus il y a de nœuds de cluster, plus il y a de données dans le corps du message du paquet Heartbeat. S'il y a plus de 1 000 nœuds, cela entraînera également une congestion du réseau. Par conséquent, l'auteur de redis ne recommande pas que le nombre de nœuds de cluster redis dépasse 1000. Ensuite, pour un cluster redis avec un nombre de nœuds inférieur à 1000, 16384 emplacements suffisent. Il n'est pas nécessaire de passer à 65536.

(3) Plus la taille de l'emplacement est petite et moins il y a de nœuds, plus le taux de compression est élevé

Dans les informations de configuration du nœud maître Redis, l'emplacement de hachage dont il est responsable est enregistré sous la forme d'un bitmap. Pendant le processus de transmission, le bitmap sera compressé, mais si le taux de remplissage bitmap slots / N est très élevé ( N représente le nombre de nœuds), le taux de compression du bitmap est très faible. Si le nombre de nœuds est petit et le nombre d'emplacements de hachage est grand, le taux de compression du bitmap est très faible. ps: Le taux de compression du fichier fait référence au rapport de la taille du fichier avant et après la compression.

Référence: "Redis Design and Implementation"

Redis (huit): cluster Redis