Quelles sont les solutions de cluster Redis ?

La quantité de données Redis augmente de jour en jour, et de plus en plus d'entreprises les utilisent. Elles ne sont pas seulement utilisées pour la mise en cache, mais tendent également à les stocker. Promouvoir le développement de clusters et de diverses entreprises. Je collecte également des solutions de cluster qui me conviennent. Actuellement, les architectures de cluster suivantes sont couramment utilisées dans l'industrie. La plupart d'entre elles utilisent la technologie de partitionnement pour résoudre une série de problèmes causés par l'augmentation du nombre d'instances uniques. mémoire.

Cet article présente brièvement cinq solutions :

Solution de cluster officielle

Solution proxy twemproxy

Mode Sentinelle

codis

Partage client

Solution cluster officielle

À partir de la version 3.0 de redis, le cluster redis-cluster est pris en charge. Chaque nœud enregistre les données et l'état complet du cluster, et chaque nœud est connecté à d'autres nœuds. redis-cluster est une technologie de partitionnement côté serveur.

Schéma d'architecture redis-cluster

Fonctionnalités redis-cluster :

Chaque nœud communique avec n-1 nœuds, cela s'appelle un bus de cluster. Ils utilisent un numéro de port spécial, qui correspond au numéro de port du service externe plus 10 000. Par conséquent, il est nécessaire de conserver les informations de chaque nœud de ce cluster, sinon l'ensemble du cluster sera indisponible. Un protocole binaire spécial est utilisé en interne pour optimiser la vitesse de transmission et la bande passante.

redis-cluster mappe tous les nœuds physiques sur [0,16383] slot (slot), et le cluster est responsable du maintien de la valeur du nœud--slot--.

Le cluster est pré-divisé en 16384 buckets Lorsque des données doivent être insérées dans le cluster redis, il est décidé en fonction de la valeur du CRC16(KEY) mod 16384 dans quel bucket une clé doit être placée.

Le client est directement connecté au nœud redis. Il n'est pas nécessaire de se connecter à tous les nœuds du cluster, connectez-vous simplement à n'importe quel nœud disponible du cluster.

Le script redis-trib.rb (langage rub) est un outil de gestion de cluster, tel que l'ajout automatique de nœuds, la planification d'emplacements, la migration de données et une série d'opérations.

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.

L'ensemble du cluster est considéré comme un tout. Le client peut se connecter à n'importe quel nœud pour fonctionner. Lorsque la clé actionnée par le client n'est pas allouée sur le nœud, redis renverra une instruction de pilotage pour pointer vers le bon. nœud.

Afin d'augmenter l'accessibilité du cluster, la solution officiellement recommandée est de configurer le nœud dans une structure maître-esclave, c'est-à-dire un nœud maître et n nœuds esclaves. Si le nœud maître échoue, le cluster Redis sélectionnera l'un des nœuds esclaves à promouvoir au rang de nœud maître selon l'algorithme d'élection, et l'ensemble du cluster continuera à fournir des services au monde extérieur.

Solution proxy twemproxy

Schéma d'architecture du proxy twemproxy :

Middleware proxy Redis twemproxy est une sorte de partitionnement qui utilise la technologie middleware. Twemproxy se situe entre le client et le serveur. Il traite la demande du client (sharding) puis la transmet au véritable serveur Redis en back-end. En d'autres termes, le client n'accède pas directement au serveur Redis, mais y accède indirectement via le middleware proxy twemproxy. Réduit le nombre de connexions client directes aux serveurs principaux et prend en charge l'expansion horizontale des clusters de serveurs.

Le traitement interne du middleware twemproxy est sans état et peut être facilement regroupé lui-même, ce qui évite des points uniques de stress ou d'échec.

twemproxy, également connu sous le nom de Casse-Noisette, est issu du proxy léger des clusters Redis et Memcached du système Twitter.

Adresse du code source de Github (https://github.com/twitter/twemproxy)

D'après le schéma d'architecture ci-dessus, nous pouvons voir que twemproxy est un point unique, qui peut facilement mettre un beaucoup de pression dessus. Par conséquent, keepalived est généralement combiné pour obtenir une haute disponibilité de twemproy. À ce moment-là, généralement un seul twemproxy fonctionne et l'autre est en veille. Lorsque l'on raccroche, VIP dérive automatiquement et la machine de veille prend en charge le travail. Concernant l’utilisation de keepalived, vous pouvez vérifier les informations en ligne.

Mode Sentinel

Sentinel Sentinel

Sentinel est une solution haute disponibilité pour Redis : un système Sentinel composé d'une ou plusieurs instances Sentinel peut surveiller n'importe quel nombre de serveurs maîtres. et tous les serveurs esclaves sous ces serveurs maîtres, et lorsque le serveur maître surveillé se déconnecte, met automatiquement à niveau un serveur esclave sous le serveur maître hors ligne vers un nouveau serveur maître.

Par exemple :

Après la mise hors ligne du serveur 1 :

Mettre à niveau le serveur 2 en tant que nouveau maître Serveur :

Comment fonctionne Sentinel

Chaque Sentinel envoie des messages au maître, à l'esclave et aux autres instances Sentinel qu'il connaît une fois par seconde. Une commande PING.

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

Si un maître est marqué comme subjectif hors ligne, toutes les sentinelles qui surveillent le maître doivent confirmer une fois par seconde que le maître est effectivement entré dans l'état subjectif hors ligne.

Lorsqu'un nombre suffisant de Sentinelles (supérieur ou égal à la valeur spécifiée dans le fichier de configuration) confirment que le Maître est effectivement entré dans un état subjectif hors ligne dans la plage de temps spécifiée, le Maître sera marqué comme étant objectivement hors ligne.

Dans des circonstances normales, chaque Sentinelle enverra des commandes INFO à tous les maîtres et esclaves qu'elle connaît une fois toutes les 10 secondes.

Lorsque le maître est marqué comme objectivement hors ligne par Sentinel, la fréquence à laquelle Sentinel envoie des commandes INFO à tous les esclaves du maître hors ligne passera d'une fois toutes les 10 secondes à une fois par seconde.

S'il n'y a pas suffisamment de Sentinelles pour convenir que le Maître est hors ligne, le statut objectif hors ligne du Maître sera supprimé. Si le maître renvoie à nouveau une valeur valide à la commande PING de Sentinel, l'état subjectif hors ligne du maître sera supprimé.

codis

codis est une solution Redis distribuée, open source par Wandoujia. Pour les applications de couche supérieure, il n'y a pas de différence évidente entre la connexion au proxy codis et la connexion au serveur redis natif. La couche supérieure L'application peut être utilisée comme un Redis autonome. La couche inférieure de Codis gérera le transfert des requêtes, la migration non-stop des données, etc. Toutes les choses suivantes sont transparentes pour le client précédent. Je pense que la connexion derrière est un service Redis avec une mémoire illimitée.

Partagement côté client

La logique de partitionnement est implémentée côté client, et le client choisit quel nœud demander. La solution peut faire référence à un hachage cohérent. Cette solution convient généralement aux scénarios dans lesquels l'utilisateur a un contrôle total sur le comportement du client.

Résumé : Il n’y a pas de meilleure solution, seulement la solution la plus adaptée.

Pour plus d'articles techniques liés à Redis, veuillez visiter la colonne Tutoriel Redis pour apprendre !

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!