Analyse et construction de l'architecture de service Redis hautement disponible

Redis basé sur la mémoire devrait être la base de données clé-valeur la plus couramment utilisée dans diverses entreprises de développement Web. Nous l'utilisons souvent pour stocker le statut de connexion des utilisateurs (stockage de session) dans notre entreprise. certaines requêtes de données chaudes (par rapport à MySQL, la vitesse est améliorée de plusieurs ordres de grandeur), créer des files d'attente de messages simples (LPUSH et BRPOP), des systèmes de publication par abonnement (PUB/SUB), etc. Les grandes sociétés Internet disposent généralement d’équipes dédiées pour fournir le stockage Redis comme service de base pour divers appels professionnels.

Cependant, l'appelant demandera à tout fournisseur de services de base : votre service est-il hautement disponible ? Il est préférable de ne pas faire souffrir mon entreprise à cause de problèmes fréquents avec votre service. Récemment, j'ai également construit un petit service Redis "hautement disponible" dans mon projet. Voici mon résumé et ma réflexion.

Tout d'abord, nous devons définir ce qui constitue la haute disponibilité du service Redis, c'est-à-dire qu'il peut toujours fournir des services normalement dans diverses situations anormales. Ou soyez plus détendu. En cas d'anomalie, les services normaux peuvent être rétablis après seulement une courte période. La soi-disant exception devrait inclure au moins les possibilités suivantes :

[Exception 1] Un processus d'un certain serveur de nœuds est soudainement tombé en panne (par exemple, un développeur a été désactivé et le processus redis-server d'un serveur était en panne). Tué)

[Exception 2] Un certain serveur de nœud est en panne, ce qui équivaut à l'arrêt de tous les processus sur ce nœud (par exemple, un handicap d'exploitation et de maintenance coupe l'alimentation d'un serveur ; par exemple, une ancienne machine a une panne matérielle)

[Exception 3] La communication entre deux serveurs de nœuds quelconques est interrompue (par exemple, un intérimaire avec une main handicapée a déterré le câble optique utilisé pour la communication entre deux salles informatiques)

En fait, toutes les anomalies ci-dessus sont des événements à faible probabilité, et l'idée directrice de base pour atteindre une haute disponibilité est la suivante : la probabilité que plusieurs événements à faible probabilité se produisent en même temps est négligeable. Une haute disponibilité peut être atteinte à condition que le système soit conçu pour tolérer un point de défaillance unique pendant une courte période de temps.

Il existe de nombreuses solutions sur Internet pour créer des services Redis à haute disponibilité, telles que Keepalived, Codis, Twemproxy et Redis Sentinel. Parmi eux, Codis et Twemproxy sont principalement utilisés dans des clusters Redis à grande échelle. Ils étaient également des solutions open source fournies par Twitter et Wandoujia avant que Redis ne publie officiellement Redis Sentinel. La quantité de données dans mon entreprise n'est pas importante, donc fournir des services de cluster est un gaspillage de machines. Finalement, j'ai fait un choix entre Keepalived et Redis Sentinel, et j'ai choisi la solution officielle Redis Sentinel.

Redis Sentinel peut être compris comme un processus qui surveille si le service Redis Server est normal. Une fois qu'une anomalie est détectée, le serveur Redis de sauvegarde (esclave) peut être automatiquement activé, permettant aux utilisateurs externes de détecter les anomalies qui se produisent. au sein du service Redis Aucune perception. Nous suivons les étapes du simple au complexe pour créer un service Redis minimal et hautement disponible.

Option 1 : Version autonome de Redis Server, sans Sentinel

Dans des circonstances normales, nous utilisons Pour les sites Web personnels ou lors du développement quotidien, une seule instance de Redis Server sera mise en place. L'appelant peut se connecter directement au service Redis, et même le client et Redis eux-mêmes sont sur le même serveur. Cette combinaison ne convient que pour l’étude personnelle et le divertissement. Après tout, il y aura toujours un seul point d’échec dans cette configuration qui ne pourra pas être résolu. Une fois le processus du service Redis suspendu ou le serveur 1 arrêté, le service sera indisponible. Et si la persistance des données Redis n'est pas configurée, les données déjà stockées dans Redis seront également perdues.

Option 2 : Synchronisation maître-esclave Redis Server, instance unique Sentinel

Afin d'atteindre haute disponibilité, Pour le problème de point de défaillance unique décrit dans la solution 1, nous devons ajouter un service de sauvegarde, c'est-à-dire démarrer un processus Redis Server sur chacun des deux serveurs. Généralement, le maître fournit des services et l'esclave en est seul responsable. pour la synchronisation et la sauvegarde. Dans le même temps, un processus Sentinel supplémentaire est lancé pour surveiller la disponibilité de deux instances de serveur Redis afin que lorsque le maître raccroche, l'esclave puisse être promu au rôle de maître à temps pour continuer à fournir des services. Cela permet d'obtenir une haute disponibilité. du serveur Redis. Ceci est basé sur une base de conception de service à haute disponibilité, c'est-à-dire qu'un point de défaillance unique est lui-même un événement à faible probabilité, et plusieurs défaillances ponctuelles multiples en même temps (c'est-à-dire que le maître et l'esclave raccrochent en même temps). temps) peut être considéré comme un événement (fondamentalement) impossible.

Pour l'appelant du service Redis, c'est le service Redis Sentinel qui doit être connecté maintenant, et non le serveur Redis. Le processus d'appel courant est que le client se connecte d'abord à Redis Sentinel et demande quel service du serveur Redis actuel est le maître et lequel est l'esclave, puis se connecte au serveur Redis correspondant pour le fonctionnement. Bien entendu, les bibliothèques tierces actuelles ont généralement implémenté ce processus d'appel, et nous n'avons plus besoin de l'implémenter manuellement (comme les ioredis de Nodejs, les predis de PHP, les go-redis/redis de Golang, les jedis de JAVA, etc.).

Cependant, après avoir implémenté la commutation maître-esclave du service Redis Server, un nouveau problème a été introduit, c'est-à-dire que Redis Sentinel lui-même est également un service unique. Une fois le processus Sentinel bloqué, le client a. rien à faire. Lié à Sentinel. Par conséquent, la configuration de l’option 2 ne peut pas atteindre la haute disponibilité.

Solution 3 : Synchronisation maître-esclave Redis Server, Sentinel double instance

Pour la solution 2 Question , nous démarrons également un processus Redis Sentinel supplémentaire. Les deux processus Sentinel fournissent simultanément des fonctions de découverte de services pour le client. Pour le client, il peut se connecter à n'importe quel service Redis Sentinel pour obtenir des informations de base sur l'instance actuelle de Redis Server. Normalement, nous configurons plusieurs adresses de lien Redis Sentinel côté client. Une fois que le client constate qu'une certaine adresse ne peut pas être connectée, il essaiera de se connecter à d'autres instances Sentinel. Bien sûr, cela ne nous oblige pas à l'implémenter manuellement. divers langages de développement Les bibliothèques de connexion Redis les plus populaires nous ont aidés à réaliser cette fonction. Nous nous attendons à ce que même si l'un des Redis Sentinels raccroche, il y aura un autre Sentinel qui pourra fournir des services.

Cependant, la vision est belle, mais la réalité est très cruelle. Avec une telle architecture, il est toujours impossible d'atteindre une haute disponibilité du service Redis. Dans le diagramme schématique de l'option 3, la ligne rouge représente la communication entre les deux serveurs, et le scénario anormal que nous avons envisagé ([Anomalie 2]) est qu'un certain serveur est en panne dans son ensemble. Autant supposer que le serveur 1. est en panne pour le moment, seuls les processus Redis Sentinel et Redis Server esclave sur le serveur 2. À ce stade, Sentinel ne basculera pas réellement l'esclave restant vers le maître pour continuer le service, ce qui entraînera l'indisponibilité du service Redis, car le paramètre de Redis est uniquement lorsque plus de 50 % des processus Sentinel peuvent se connecter et votez pour le nouveau maître, la commutation maître-esclave se produira réellement. Dans cet exemple, une seule des deux Sentinelles peut être connectée, ce qui équivaut à 50 % et ne se situe pas dans un scénario où la commutation maître-esclave est possible.

Vous vous demandez peut-être pourquoi Redis a-t-il ce paramètre de 50 % ? En supposant que nous autorisons une connectivité inférieure ou égale à 50 % de Sentinel, une commutation maître-esclave peut également être effectuée. Imaginez simplement [Exception 3], c'est-à-dire que le réseau entre le serveur 1 et le serveur 2 est interrompu, mais le serveur lui-même est opérationnel. Comme le montre la figure ci-dessous :

En fait, pour le serveur 2, si le serveur 1 est directement en panne, cela a le même effet que si le serveur 1 ne parvient pas à se connecter à le réseau. Quoi qu'il en soit, il devient soudainement indisponible. Aucune communication n'a été effectuée. Supposons que lorsque le réseau est interrompu, nous autorisons Sentinel du serveur 2 à passer de l'esclave au maître. Le résultat est que vous disposez désormais de deux serveurs Redis pouvant fournir des services externes. Toute opération d'ajout, de suppression et de modification effectuée par le Client peut tomber sur le Redis du Serveur 1 ou sur le Redis du Serveur 2 (selon le Sentinel auquel le Client est connecté), provoquant une confusion des données. Même si le réseau entre le Serveur 1 et le Serveur 2 est restauré ultérieurement, on ne pourra pas unifier les données (deux données différentes, à qui faire confiance ?), et la cohérence des données est complètement détruite.

Option 4 : Synchronisation maître-esclave Redis Server, trois instances de Sentinel

Depuis l'option 3 ne le fait pas. Pour obtenir une haute disponibilité, notre version finale est la solution 4 présentée dans la figure ci-dessus. En fait, c’est l’architecture que nous avons fini par construire. Nous avons introduit le serveur 3 et construit un processus Redis Sentinel sur 3. Désormais, trois processus Sentinel gèrent deux instances de serveur Redis. Dans ce scénario, qu'il s'agisse d'une panne d'un seul processus, d'une panne d'une seule machine ou d'une panne de communication réseau entre deux machines, les services Redis peuvent continuer à être fournis au monde extérieur.

En fait, si votre machine est relativement inactive, vous pouvez bien sûr également ouvrir un serveur Redis sur le serveur 3 pour former une architecture 1 maître + 2 esclaves. Chaque donnée dispose de deux sauvegardes, et la disponibilité sera améliorée. . Quelques. Bien sûr, plus il y a d’esclaves, mieux c’est. Après tout, la synchronisation maître-esclave coûte aussi du temps.

Dans le scénario 4, une fois la communication entre le serveur 1 et les autres serveurs complètement interrompue, les serveurs 2 et 3 passeront d'esclave à maître. Pour le client, il y a actuellement 2 maîtres qui fournissent des services, et une fois le réseau restauré, toutes les nouvelles données tombées sur le serveur 1 lors de la panne seront perdues. Si vous souhaitez résoudre partiellement ce problème, vous pouvez configurer le processus du serveur Redis de sorte que lorsqu'il détecte un problème avec son propre réseau, il arrête immédiatement le service pour éviter que de nouvelles données n'arrivent lors de la panne du réseau (reportez-vous au min- slaves-to-write et min-slaves-max-lag deux éléments de configuration).

À ce stade, nous avons construit un service Redis hautement disponible utilisant 3 machines. En fait, il existe une méthode plus économe en machine sur Internet, qui consiste à placer un processus Sentinel sur la machine client au lieu de celle du fournisseur de services. C'est juste que dans l'entreprise, les prestataires et les appelants des services généraux ne viennent pas de la même équipe. Lorsque deux équipes exploitent ensemble la même machine, il est facile que des erreurs de fonctionnement se produisent en raison de problèmes de communication. Par conséquent, pour des raisons de facteurs humains, nous avons quand même adopté l'architecture du Plan 4. Et comme il n'y a qu'un seul processus Sentinel en cours d'exécution sur le serveur 3, il ne consomme pas beaucoup de ressources du serveur. Le serveur 3 peut également être utilisé pour exécuter d'autres services.

Facilité d'utilisation : utilisez Redis Sentinel comme une version autonome de Redis

En tant que fournisseur de services, nous parlons toujours de l'expérience des utilisateurs problèmes. Parmi les solutions ci-dessus, il y a toujours quelque chose qui rend leur utilisation moins confortable pour le client. Pour la version autonome de Redis, le client se connecte directement au serveur Redis. Il suffit de donner une IP et un port, et le client peut utiliser notre service. Après s'être transformé en mode Sentinel, le Client doit utiliser certains packages de dépendances externes prenant en charge le mode Sentinel, et doit également modifier sa propre configuration de connexion Redis, ce qui est évidemment inacceptable pour les utilisateurs « hypocrites ». Existe-t-il un moyen de fournir des services en donnant simplement au client une adresse IP et un port fixes, comme en utilisant la version autonome de Redis ?

La réponse est bien sûr oui. Cela peut nécessiter l'introduction d'une IP virtuelle (Virtual IP, VIP), comme le montre la figure ci-dessus. Nous pouvons pointer l'IP virtuelle vers le serveur où se trouve le maître du serveur Redis Lorsqu'un commutateur maître-esclave Redis se produit, un script de rappel sera déclenché. Le script de rappel bascule le VIP vers le serveur où se trouve l'esclave. De cette façon, pour le client, il semble qu'il utilise toujours une version autonome du service Redis hautement disponible.

Conclusion

Il est en fait très simple de créer n'importe quel service et de le rendre "utilisable", tout comme nous exécutons une version autonome Redis. Mais dès que l’on souhaite atteindre la « haute disponibilité », les choses se compliquent. Deux serveurs supplémentaires sont utilisés dans l'entreprise, 3 processus Sentinel + 1 processus Slave, juste pour garantir que le service est toujours disponible dans le cas peu probable d'un accident. Dans les affaires réelles, nous permettons également au superviseur de surveiller les processus. Une fois que le processus se termine de manière inattendue, il tentera automatiquement de redémarrer.

Apprentissage recommandé : Tutoriel vidéo 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!