Pratique de haute disponibilité Redis

Redis est une base de données de valeurs-clés de type journal open source écrite en langage ANSI C, prend en charge le réseau, peut être basée sur la mémoire et persistante, et fournit des API dans plusieurs langues.

De nos jours, les données commerciales sur Internet croissent à un rythme plus rapide et les types de données deviennent de plus en plus abondants, ce qui met en avant des exigences plus élevées en matière de vitesse et de capacités de traitement des données. Redis est une base de données non relationnelle en mémoire open source qui apporte une expérience disruptive aux développeurs. Conçue du début à la fin dans un souci de hautes performances, Redis est la base de données NoSQL la plus rapide disponible aujourd'hui.

Tout en considérant la haute performance, la haute disponibilité est également une considération très importante. Internet fournit un service ininterrompu 7×24 et un basculement à la vitesse la plus rapide en cas de panne, ce qui peut entraîner des pertes minimes pour l'entreprise.

Alors, quelles sont les architectures à haute disponibilité dans les applications pratiques ? Quels sont les avantages et les inconvénients entre les architectures ? Comment devrions-nous choisir ? Quelles sont les bonnes pratiques ?

Avant d'expliquer la solution de haute disponibilité Redis, jetons d'abord un œil au Principe de Redis Sentinel.

1. Le cluster Sentinel découvre le maître via le fichier de configuration donné et surveille le maître lors de son démarrage. Obtenez tous les serveurs esclaves sous ce serveur en envoyant des informations au maître.
2. Le cluster Sentinel envoie des informations de bonjour (une fois par seconde) aux serveurs maître et esclave surveillés via des connexions de commande. Ces informations incluent l'adresse IP, le port, l'identifiant de Sentinel, etc., afin d'annoncer son existence aux autres Sentinels.
3. Le cluster Sentinel reçoit les informations de bonjour envoyées par d'autres Sentinels via des connexions d'abonnement pour découvrir d'autres Sentinels surveillant le même serveur maître ; les clusters créeront des connexions de commande entre eux pour la communication, car il existe déjà des serveurs maître-esclave comme expéditeurs. Non une connexion d'abonnement sera créée entre Sentinel et l'intermédiaire qui reçoit les informations hello.
4. Le cluster Sentinel utilise la commande ping pour détecter l'état de l'instance. S'il n'y a pas de réponse dans le délai spécifié (arrêt après millisecondes) ou si une réponse incorrecte est renvoyée, l'instance est considérée comme hors ligne.
5. Lorsque le basculement actif/veille est déclenché, le basculement ne se déroulera pas immédiatement. La majorité des Sentinelles du Sentinel doivent être autorisées avant que le basculement puisse être effectué. obtenir l'autorisation du quorum Sentinels désigné, entrer dans l'état ODOWN après succès. Par exemple, si 2 quorums sont configurés parmi 5 Sentinels, le basculement sera exécuté lorsque les 2 Sentinels penseront que le maître est mort.
6. Sentinel envoie la commande SLAVEOF NO ONE à l'esclave sélectionné comme maître. La condition de sélection de l'esclave est que Sentinel triera d'abord les esclaves selon leurs priorités. Si les priorités sont les mêmes, vérifiez l'indice de réplication, celui qui reçoit le plus de données de réplication du maître sera classé en premier. Si la priorité et l'index sont identiques, celui avec l'ID de processus le plus petit est sélectionné.
7. Une fois Sentinel autorisé, il obtiendra le dernier numéro de version de configuration (config-epoch) du maître défaillant. Une fois l'exécution du basculement terminée, ce numéro de version sera utilisé pour la dernière configuration via la diffusion Notifier les autres Sentinels dans. le formulaire, et d'autres Sentinels mettent à jour la configuration du maître correspondant.

1 à 3 sont des mécanismes de découverte automatique :

• Envoyez la commande d'information au maître surveillé toutes les 10 secondes et obtenez les informations actuelles du maître en fonction de la réponse.
• Envoyez des commandes PING à tous les serveurs Redis, y compris Sentinel, à une fréquence de 1 seconde, et déterminez si le serveur est en ligne grâce à la réponse.
• Envoyer le message d'information du maître Sentinel actuel à tous les serveurs maîtres et esclaves surveillés à une fréquence de 2 secondes.

4 est le mécanisme de détection, 5 et 6 sont des mécanismes de basculement et 7 est le mécanisme de configuration de mise à jour. [1]

Après avoir expliqué le principe de Redis Sentinel, expliquons l'architecture haute disponibilité Redis couramment utilisée.

• Cluster Redis Sentinel + DNS intranet + script personnalisé
• Redis Sentinel Cluster + VIP + Script personnalisé
• Encapsulez le client pour vous connecter directement au port Redis Sentinel
  • JedisSentinelPool, adapté à Java
  • PHP est auto-emballé basé sur PHPredis
• Redis Sentinel Cluster + Keepalived/Haproxy
• Redis M/S + Keepalived
• Cluster Redis
• Twemproxy
• Codis

Ce qui suit sera expliqué un par un avec des images et du texte.

L'image ci-dessus est une solution qui a été appliquée dans un environnement en ligne. La couche inférieure est le cluster Redis Sentinel, qui agit comme agent pour le maître et l'esclave Redis. Le côté Web se connecte au DNS intranet pour fournir des services. Le DNS intranet est attribué selon certaines règles, telles que xxxx.redis.cache/queue.port.xxx.xxx Le premier segment indique l'abréviation de l'entreprise, le deuxième segment indique qu'il s'agit du nom de domaine intranet Redis et le le troisième segment représente le type Redis, le cache représente le cache, la file d'attente représente la file d'attente, le quatrième segment représente le port Redis et les cinquième et sixième segments représentent le nom de domaine principal de l'intranet.

Lorsque le nœud maître échoue, comme une panne de machine, une panne de nœud Redis ou une inaccessibilité du réseau, le cluster Sentinel appellera le script configuré client-reconfig-script pour modifier le nom de domaine intranet du port correspondant. Le nom de domaine intranet du port correspondant pointe vers le nouveau nœud maître Redis.

Avantages :

• Commutation de deuxième niveau, effectuez toute l'opération de commutation en 10 secondes
• Personnalisation du script et architecture contrôlable
• Transparent à l'application, le front-end n'a pas à se soucier des changements dans le back-end

Inconvénients :

• Le coût de maintenance est légèrement élevé. Il est recommandé d'investir dans plus de 3 machines pour le cluster Redis Sentinel
• Dépend du DNS, il y a un délai de résolution
• Le service en mode Sentinelle sera indisponible pendant une courte période
• Cette solution ne peut pas être utilisée si le service est accessible via le réseau externe

Ce plan est légèrement différent du précédent. La première solution utilise le DNS intranet et la seconde solution remplace le DNS intranet par une IP virtuelle. La couche inférieure est le cluster Redis Sentinel, qui agit comme un agent pour le maître et l'esclave Redis, et le côté Web fournit des services via VIP. Lors du déploiement maître-esclave Redis, vous devez lier l'adresse IP virtuelle au nœud maître Redis actuel. Lorsque le nœud maître échoue, comme une panne de machine, une panne de nœud Redis ou une inaccessibilité du réseau, le cluster Sentinel appellera le script configuré par client-reconfig-script pour faire flotter le VIP vers le nouveau nœud maître.

Avantages :

• Commutation de deuxième niveau, effectuez toute l'opération de commutation en 5 secondes
• Personnalisation du script et architecture contrôlable
• Transparent à l'application, le front-end n'a pas à se soucier des changements dans le back-end

Inconvénients :

• Le coût de maintenance est légèrement élevé. Il est recommandé d'investir dans plus de 3 machines pour le cluster Redis Sentinel
• L'utilisation de VIP augmente les coûts de maintenance et risque le chaos IP
• Le service en mode Sentinelle sera indisponible pendant une courte période

Certaines entreprises ne peuvent accéder à Redis que via le réseau externe. Aucune des deux solutions ci-dessus n'est disponible, cette solution a donc été dérivée. Web utilise le client pour se connecter à un certain port d'une machine dans l'un des clusters Redis Sentinel, puis obtient le nœud maître actuel via ce port, puis se connecte au véritable nœud maître Redis pour effectuer les opérations de vendeur correspondantes. Il est important de noter que le port Redis Sentinel et le nœud maître Redis nécessitent un accès ouvert. Si l'entreprise front-end utilise Java, JedisSentinelPool peut être réutilisé ; si l'entreprise front-end utilise PHP, l'encapsulation secondaire peut être effectuée sur la base de phpredis.

Avantages :

• Le service détecte rapidement les défauts
• Le coût de maintenance DBA est faible

Inconvénients :

• Dépend du support client Sentinel
• Le serveur Sentinel et les nœuds Redis nécessitent un accès ouvert
• Intrusif pour l'application

La couche inférieure est le cluster Redis Sentinel, qui agit comme un agent pour le maître et l'esclave Redis, et le côté Web fournit des services via VIP. Lorsque le nœud maître tombe en panne, comme une panne de machine, une panne de nœud Redis ou une inaccessibilité du réseau, la commutation entre Redis est garantie par le mécanisme interne de Redis Sentinel et la commutation VIP est garantie par Keepalived.

Avantages :

• Changez en quelques secondes
• Transparent à l'application

Inconvénients :

• Coût de maintenance élevé
• Avoir un cerveau divisé
• Le service en mode Sentinelle sera indisponible pendant une courte période

Cette solution n'utilise pas Redis Sentinel. Cette solution utilise le maître-esclave natif et la commutation Keepalived VIP est garantie par Keepalived. La commutation entre maître-esclave Redis nécessite des scripts personnalisés.

Avantages :

• Changez en quelques secondes
• Transparent à l'application
• Déploiement simple et faible coût de maintenance

Inconvénients :

• Nécessite un script pour implémenter la fonction de commutation
• Avoir un cerveau divisé

De : http://intro2libsys.com/focused-redis-topics/day-one/intro-redis-cluster

Redis 3.0.0 est officiellement sorti le 2 avril 2015, il y a plus de deux ans. Le cluster Redis adopte le mode P2P et n'est pas centralisé. Divisez la clé en 16 384 emplacements, et chaque instance est responsable d'une partie des emplacements. Le client demande les données correspondantes. Si l'emplacement d'instance ne contient pas de données correspondantes, l'instance sera transmise à l'instance correspondante. De plus, le cluster Redis synchronise les informations sur les nœuds via le protocole Gossip.

Avantages :

• Les composants sont tout-en-boîte, faciles à déployer et économisent les ressources de la machine
• Les performances sont meilleures que le mode proxy
• Basculement automatique et données disponibles lors de la migration des emplacements
• Solution de cluster natif officielle, mises à jour et support garantis

Inconvénients :

• L'architecture est relativement nouvelle et il existe peu de bonnes pratiques
• La prise en charge des opérations multi-touches est limitée (le conducteur peut sauver le pays dans les virages)
• Afin d'améliorer les performances, le client doit mettre en cache les informations de la table de routage
• Les opérations de découverte de nœuds et de repartitionnement ne sont pas suffisamment automatisées

De : http://engineering.bloomreach.com/the-evolution-of-fault-tolerant-redis-cluster

Plusieurs Twemproxy isomorphes (même configuration) fonctionnent en même temps, acceptent les demandes des clients et les transmettent au Redis correspondant selon l'algorithme de hachage.

La solution Twemproxy est relativement mature. Notre équipe utilise cette solution depuis longtemps, mais l'effet n'est pas très satisfaisant. D'une part, le problème de positionnement est plus difficile, et d'autre part, sa prise en charge de l'élimination automatique des nœuds n'est pas très conviviale.

Avantages :

• Facile à développer et presque transparent pour l'application
• Longue histoire et solutions matures

Inconvénients :

• Le proxy affecte les performances
• LVS et Twemproxy auront des goulots d'étranglement en termes de performances des nœuds
• L'expansion de Redis est très gênante
• Twitter a abandonné l'utilisation de cette solution en interne, et la nouvelle architecture n'est pas open source

De : https://github.com/CodisLabs/codis

Codis est un produit open source de Wandoujia et implique de nombreux composants, parmi lesquels ZooKeeper stocke les tables de routage et les métadonnées des nœuds proxy, et distribue les commandes Codis-Config ; Codis-Config est un outil de gestion intégré avec une interface Web à utiliser ; Proxy est un proxy sans état compatible avec le protocole Redis ; Codis-Redis est un développement secondaire basé sur la version Redis 2.8, ajoutant la prise en charge des emplacements pour faciliter la migration des données.

Avantages :

• Facile à développer et presque transparent pour l'application
• Les performances sont meilleures que celles de Twemproxy
• Possède une interface graphique, une extension facile et un fonctionnement et une maintenance pratiques

Inconvénients :

• Le proxy affecte toujours les performances
• Trop de composants, nécessitant beaucoup de ressources machine
• Le code Redis a été modifié, entraînant l'impossibilité de se synchroniser avec le code officiel, et le suivi des nouvelles fonctionnalités est lent
• L'équipe de développement se prépare à promouvoir reborndb basé sur la transformation Redis

Les meilleures pratiques sont les pratiques les plus adaptées à des scénarios spécifiques.

Nous recommandons principalement les forfaits suivants :

• Cluster Redis Sentinel + DNS intranet + script personnalisé
• Redis Sentinel Cluster + VIP + Script personnalisé

Voici les meilleures pratiques résumées lors du combat réel :

• Le cluster Redis Sentinel est recommandé pour utiliser >= 5 machines
• Différentes grandes entreprises peuvent utiliser un cluster Redis Sentinel pour proxyer tous les ports de l'entreprise
• Répartissez la gamme de ports Redis selon les différentes entreprises
• Il est recommandé d'implémenter des scripts personnalisés en Python pour une expansion facile
• Les scripts personnalisés doivent faire attention pour déterminer le rôle actuel de Sentinel
• Transmettez les paramètres du script personnalisé : Les scripts personnalisés nécessitent un SSH distant pour faire fonctionner la machine. Il est recommandé d'utiliser la bibliothèque
paramiko
• pour éviter d'établir des connexions SSH à plusieurs reprises et de perdre du temps. Pour accélérer la connexion SSH, il est recommandé de désactiver les deux paramètres suivants
• Utilisez le numéro DNS
  • GSSAPINuméro d'authentification
  Si vous recevez une alerte via WeChat ou par e-mail, il est recommandé de créer un processus pour éviter de bloquer le processus principal
• Commutation et basculement automatiques, il est recommandé que toutes les opérations soient terminées dans les 15 secondes

), ou envoyer un email à : dbarobinwen@gmail.com Téléchargement PPT ci-joint : https://github.com/dbarobin/slides

Lecture vidéo : meilleures pratiques pour l'architecture haute disponibilité 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!