Différent du mode maître-salve ou sentinelle, la plus grande différence entre le cluster et eux est que les deux premiers sont du stockage complet, qui consomme beaucoup de mémoire et a un effet baril, tandis que le cluster cluster est du stockage distribué, c'est-à-dire , chaque Redis stocke un contenu différent.
redis-cluster est conçu pour avoir un total de 16384 emplacements de hachage disponibles, et chaque maître se voit attribuer une partie de l'emplacement. L'algorithme de distribution est : [hash_slot = crc16. (clé) mod 16384] S'il y a {}, prenez la clé disponible de {}, sinon la clé entière peut être disponible. Le cluster doit avoir au moins 3 maîtres et 3 esclaves, et chaque instance utilise un fichier de configuration différent.
Tous les nœuds Redis sont interconnectés les uns aux autres (mécanisme PING-PONG) et utilisent des protocoles binaires en interne pour optimiser la vitesse de transmission et la bande passante.
La défaillance d'un nœud ne prend effet que lorsque plus de la moitié des nœuds du cluster détectent une défaillance.
Le client est directement connecté au nœud Redis, sans avoir besoin d'une couche proxy intermédiaire. Le client n'a pas besoin de se connecter à tous les nœuds du cluster, il suffit de se connecter à n'importe quel nœud disponible. nœud dans le cluster.
redis-cluster mappe tous les nœuds physiques sur l'emplacement [0-16383], et le cluster est responsable de la maintenance du nœudslotvalue
Vote redis-cluster : tolérance aux pannes
1. Le processus de vote implique tous les maîtres du cluster si plus de la moitié des nœuds maîtres communiquent avec le nœud maître au fil du temps (cluster-node-. timeout), le maître actuel est considéré. Le nœud se bloque.
2 Quand l'ensemble du cluster devient-il indisponible (cluster_state:fail) ?
Si un maître du cluster raccroche et que le le maître actuel n'a pas d'esclave et le cluster entre dans l'état d'échec, il peut également Il est entendu que lorsque le mappage des emplacements [0-16383] du cluster est incomplet, il entre dans l'état d'échec
redis-. 3.0.0.rc1 ajoute le paramètre cluster-require-full-coverage, qui est fermé par défaut, et ne parvient pas à ouvrir la partie compatibilité du cluster
Si plus de la moitié des maîtres du cluster meurent, peu importe. Qu'il y ait ou non des esclaves, le cluster entrera dans l'état d'échec.
Dans l'architecture redis-cluster, le nœud redis-master est généralement utilisé pour recevoir des lectures et des écritures, tandis que le nœud redis-slave n'est généralement utilisé que pour la sauvegarde. Il a le même emplacement que le maître correspondant. Si un redis-master échoue de manière inattendue, son esclave correspondant sera mis à niveau vers un redis-master temporaire.
Dans la documentation officielle de Redis, il y a cette description de l'architecture redis-cluster : Sous l'architecture cluster, par défaut, redis-master est généralement utilisé pour recevoir des lectures et des écritures, tandis que redis-slave est utilisé pour Sauvegarde, lorsqu'une requête est faite à l'esclave, elle sera directement redirigée vers le maître où se trouve la clé correspondante pour traitement.
Mais si cela ne vous dérange pas de lire des données potentiellement expirées dans redis-cluster et que vous n'êtes pas intéressé par les demandes d'écriture, vous pouvez également définir l'esclave en lecture via la commande readonly, puis obtenir les informations pertinentes via le esclave. La clé réalise la séparation de la lecture et de l’écriture.
Pour plus de connaissances sur Redis, veuillez faire attention à la colonne Tutoriel d'introduction à Redis.
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!