Qu'est-ce que le cluster Redis

Introduction au cluster Redis

Redis Cluster est un assembly qui permet le partage de données entre plusieurs nœuds Redis.

Le cluster Redis ne prend pas en charge les commandes pour traiter plusieurs clés, car cela nécessite de déplacer des données entre différents nœuds, ne parvenant ainsi pas à atteindre les mêmes performances que Redis, et peut conduire à une imprévisibilité dans des conditions de charge élevée.

Le cluster Redis offre un certain degré de disponibilité grâce au partitionnement. Dans l'environnement réel, il peut continuer à traiter les commandes lorsqu'un nœud est en panne ou inaccessible :

Divisez automatiquement les données en différents nœuds. .

Peut continuer à traiter les commandes même si certains nœuds de l'ensemble du cluster échouent ou sont inaccessibles.

Partagement des données du cluster Redis

Le cluster Redis n'utilise pas de hachage cohérent, mais introduit le concept d'emplacement de hachage.

Cluster Redis Il y en a 16384 Emplacements de hachage. Chaque clé est vérifiée par CRC16 et le modulo 16384 est utilisé pour déterminer quel emplacement placer. Chaque nœud du cluster est responsable d'une partie des emplacements de hachage. Par exemple, si le cluster actuel a 3 nœuds, alors : 🎜>

Le nœud A contient les emplacements de hachage 0 à 5500.

Le nœud B contient les emplacements de hachage 5501 à 11000.

Le nœud C contient les emplacements de hachage 11001 à 16384.

Cette structure facilite l'ajout ou la suppression de nœuds. Par exemple, si je souhaite ajouter un nouveau nœud D, je dois obtenir des emplacements des nœuds A, B et C vers D. Si je souhaite supprimer le nœud A, vous Vous devez déplacer les emplacements de A vers les nœuds B et C, puis supprimer le nœud A sans aucun emplacement du cluster, car le déplacement de l'emplacement de hachage d'un nœud à un autre n'arrête pas le service. Par conséquent, l'ajout, la suppression ou la modification. le nombre d'emplacements de hachage d'un nœud ne rendra pas le cluster indisponible.

Modèle de réplication maître-esclave du cluster Redis

Afin de rendre le cluster toujours disponible lorsque certains nœuds échouent ou que la plupart des nœuds ne peuvent pas communiquer, le cluster utilise un modèle de réplication maître-esclave et chaque nœud aura N-1 répliques.

Dans notre exemple Dans un cluster avec trois nœuds A, B, et C, sans modèle de réplication, si le nœud B échoue, l'ensemble du cluster sera considéré comme indisponible car il lui manque des emplacements dans la plage 5501-11000.

Cependant, si nous ajoutons un nœud esclave A1, B1, C1 à chaque nœud lorsque le cluster est créé (ou après un certain temps), le cluster entier sera alors composé de trois nœuds maîtres et de trois nœuds esclaves. De cette façon, après l'échec du nœud B, le cluster élira B1 comme nouveau. le nœud maître pour continuer à servir, et l'ensemble du cluster ne sera pas indisponible car l'emplacement est introuvable

Cependant, lorsque B et B1 échouent, le cluster sera indisponible.

Garantie de cohérence Redis

Redis ne garantit pas une forte cohérence des données. Cela signifie qu'en pratique, le cluster peut perdre les opérations d'écriture dans certaines conditions.

La première raison est que le cluster. utilise la réplication asynchrone. Le processus d'opération d'écriture :

Le client écrit une commande sur le nœud maître B.

Le nœud maître B écrit au client Répondre à l'état de la commande.

Le nœud maître copie l'opération d'écriture sur ses nœuds esclaves B1, B2 et B3.

La copie de la commande par le nœud maître se produit après avoir renvoyé la réponse de la commande, car si chaque Si chaque demande de commande doit attendre Pour terminer l'opération de réplication, la vitesse à laquelle le nœud maître traite les demandes de commandes sera considérablement réduite - nous devons faire un compromis entre performances et cohérence. Remarque : Redis Cluster pourrait fournir une méthode d'écriture synchrone à l'avenir. Une autre situation dans laquelle le cluster Redis peut perdre des commandes est lorsque le cluster dispose d'une partition réseau et qu'un client est isolé d'un petit nombre d'instances comprenant au moins un nœud maître.

Par exemple, supposons que le cluster contienne six nœuds A, B, C, A1, B1 et C1, parmi lesquels A, B et C sont les nœuds maîtres, et A1, B1 et C1 sont les esclaves des nœuds A, B et C. et un client Z1. En supposant qu'une partition réseau se produise dans le cluster, le cluster peut être divisé en deux parties. La partie majoritaire contient les nœuds A, C, A1, B1 et C1. et le petit groupe contient le nœud B et les clients. Fin Z1.

Z1 peut toujours écrire sur le nœud maître B. Si la partition réseau se produit pendant une courte période, le cluster continuera à fonctionner normalement si le temps de partition est écoulé. est suffisamment long pour que la plupart des partis élisent B1 comme nouveau maître, alors les données écrites par Z1 dans B seront perdues.

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!