Exemple d'analyse des pratiques de sauvegarde Redis, de reprise après sinistre et de haute disponibilité

1. Une brève introduction à Redis

Redis est une base de données non relationnelle clé-valeur hautes performances En raison de ses caractéristiques de haute performance, elle prend en charge la haute disponibilité, la persistance, plusieurs structures de données, les clusters, etc. le faisant se démarquer, devenant une base de données non relationnelle couramment utilisée.

De plus, Redis propose de nombreux scénarios d'utilisation.

Cache de session

La session de cache Redis présente un très bon avantage, car Redis offre une persistance, qui peut fournir de bonnes performances à long terme dans les scénarios d'application qui nécessitent de maintenir des sessions pendant une longue période, comme les scénarios de prise en charge de session de panier d'achat. offrir aux utilisateurs une bonne expérience d'achat.

Cache complet des pages

Dans WordPress, Pantheon fournit un bon plug-in wp-redis, qui peut charger les pages que vous avez parcourues à la vitesse la plus rapide.

Queue

Redis prend en charge les opérations de liste et d'ensemble, il est donc très approprié pour une utilisation comme plate-forme de file d'attente de messages. Nous utilisons souvent la fonction de file d’attente de Reids pour limiter les achats. Par exemple, pendant les vacances ou les périodes de promotion, certaines activités peuvent être menées pour restreindre le comportement d'achat des utilisateurs, en les limitant à quelques achats seulement aujourd'hui ou à une seule fois sur une période donnée. Il est également plus adapté à l'application.

Ranking

Redis implémente très bien l'opération d'incrémentation ou de décrémentation des nombres en mémoire. Par conséquent, nous utilisons Redis dans de nombreux scénarios de classement. Par exemple, les sites Web de romans classent les romans et recommandent les romans les mieux classés aux utilisateurs en fonction du classement.

Publier/S'abonner

Redis fournit des fonctions de publication et d'abonnement. Il existe de nombreux scénarios de publication et d'abonnement. Par exemple, nous pouvons implémenter un système de discussion construit à l'aide des fonctions de publication et d'abonnement de Redis basé sur des déclencheurs de script de publication et d'abonnement.

De plus, il existe de nombreux autres scénarios dans lesquels Redis fonctionne bien.

2. Problème de point de défaillance unique dans l'utilisation de Redis

Redis est utilisé dans diverses entreprises, et ses multiples excellentes fonctionnalités et ses riches scénarios d'application sont la raison de son existence. Ensuite, les problèmes et les risques viendront. Bien que Redis propose des scénarios d'application riches, certaines entreprises utilisent encore le déploiement à nœud unique de manière relativement conservatrice lors de la pratique des applications Redis, ce qui entraîne des risques de sécurité pour la maintenance future.

J'ai déjà été confronté à un problème d'interruption d'activité causé par un point de défaillance unique en 2015. Lorsque Redis a été déployé pour la première fois, il utilisait un déploiement à nœud unique plutôt qu'un déploiement distribué et ne prenait pas en compte les problèmes de reprise après sinistre.

À cette époque, nous utilisions le serveur Redis pour contrôler l'achat de produits à prix réduit par l'utilisateur. Cependant, pour des raisons inconnues, le serveur du nœud Redis est tombé en panne, ce qui nous a empêché de contrôler le comportement d'achat de l'utilisateur. l'utilisateur peut acheter plusieurs fois au cours d'une période donnée. Le comportement des marchandises à prix réduit.

On peut dire que ce type d'accident d'arrêt a causé des pertes irréparables à l'entreprise. Le problème de risque de sécurité est très grave. En tant que personne qui exploitait et entretenait le système à l'époque, il était nécessaire pour moi de réparer ce problème et de le réparer. améliorer l'architecture. Par conséquent, j'ai commencé à rechercher et à apprendre des moyens de résoudre le point de défaillance unique de Redis dans les applications non distribuées.

3. Sauvegarde et reprise après sinistre des applications Redis dans des scénarios non distribués

La réplication maître-esclave Redis devrait être très courante désormais. Les architectures de réplication maître-esclave couramment utilisées incluent les deux solutions d'architecture suivantes.

Réplication maître-esclave Redis couramment utilisée

Option 1

Généralement, cette structure est la plus courante, c'est-à-dire un nœud maître et deux nœuds esclaves. Lorsque le client écrit des données, il écrit sur le nœud maître et lors de la lecture, il lit à partir de deux esclaves. Cela permet une extension de lecture et réduit la charge de lecture sur le nœud maître.

Option 2

Cette architecture comporte également un maître et deux esclaves. Master et Slave1 utilisent keepalived pour implémenter la migration VIP de différentes manières. Lorsque le client se connecte au maître, il se connecte via VIP. Cela évite la situation de changement d’adresse IP dans la solution 1.

Avantages et inconvénients de la réplication maître-esclave Redis

Avantages

Une fois le maître défaillant, le nœud esclave peut être promu au rang de nouveau maître et remplacer l'ancien maître pour continuer. pour fournir des services

implémentation Lire l'extension. L'architecture de réplication maître-esclave est généralement utilisée pour réaliser une extension de lecture. Le maître implémente principalement la fonction d'écriture et l'esclave implémente la fonction de lecture

Insuffisant

Solution architecturale 1

Lorsque le maître échoue, le client se déconnecte du maître et ne peut pas implémenter la fonction d'écriture, et l'esclave ne peut pas créer de copies maîtresses.

À ce stade, vous devez effectuer les opérations suivantes (en supposant que Slave1 est promu Master) :

1. Exécutez la commande slaveof no one sur Slave1 pour promouvoir Slave1 en tant que nouveau nœud Master.

2. est configuré en écriture sur Slave1 En effet, dans la plupart des cas, l'esclave est configuré en lecture seule.

3. Dites au client (c'est-à-dire le programme qui se connecte à Redis) l'adresse de connexion du nouveau nœud maître.

4. Configurez Slave2 pour copier les données du nouveau Master.

Plan d'architecture 2

Lorsque le maître échoue, le client peut se connecter à Slave1 pour les opérations de données, mais Slave1 devient un point unique, ce qui conduit à un point de défaillance unique (point de défaillance unique) qui nécessite souvent échec à éviter).

Vous devez ensuite effectuer les opérations suivantes :

1. Exécutez la commande slaveof no one sur Slave1 pour promouvoir Slave1 en tant que nouveau nœud maître

2. Configurez Slave1 comme étant accessible en écriture, car dans la plupart des cas, configurez Slave en lecture seule

3. Configurez Slave2 pour copier les données du nouveau Master

Il convient de noter que toutes les solutions architecturales nécessitent une intervention manuelle pour le basculement. La nécessité d'une intervention manuelle augmente la charge de travail d'exploitation et de maintenance et a également un impact énorme sur l'entreprise. À l'heure actuelle, vous pouvez utiliser la solution haute disponibilité de Redis - Sentinel

4 Introduction à Redis Sentinel

Redis Sentinel fournit une solution haute disponibilité pour Redis. D'un point de vue pratique, l'utilisation de Redis Sentinel peut créer un environnement Redis qui évite certaines pannes sans intervention humaine.

Redis Sentinel adopte une architecture distribuée et exécute plusieurs processus pour une coopération collaborative. Exécutez plusieurs processus Sentinel pour coopérer. Lorsque plusieurs Sentinels ne peuvent plus fournir de services à un maître donné, une détection des pannes sera effectuée, ce qui réduira le risque de faux positifs.

5. Fonction Redis Sentinel

Les principales fonctions de Redis Sentinel dans la solution haute disponibilité Redis sont les suivantes :

Surveillance

Sentinel vérifiera en permanence si le maître et l'esclave fonctionnent normalement comme prévu

Notification

Grâce à l'API, Sentinel peut avertir les administrateurs système et les instances Redis d'échec surveillées par le programme

Basculement automatique

Si le maître ne fonctionne pas comme prévu, Sentinel peut démarrer le processus de basculement, dont l'un deviendra le maître et les autres esclaves seront reconfigurés pour utiliser le nouveau maître. Les applications utilisant le service Redis seront également informées d'utiliser la nouvelle adresse lors de la connexion.

Fournisseur de configuration

Sentinel peut être utilisé comme source d'authentification pour la découverte du service client : le client se connecte à Sentinel pour obtenir l'adresse principale Redis actuellement responsable d'un service donné. En cas de basculement, Sentinel signalera la nouvelle adresse.

6. Architecture Redis Sentinel

7. Principe de mise en œuvre de Redis Sentinel

Le cluster Sentinel se surveille lui-même et la réplication maître-esclave Redis. Lorsqu'il est découvert que le nœud maître échoue, les étapes suivantes seront suivies :

• 1) Une élection a lieu entre les Sentinelles pour élire un leader, et le leader élu effectuera le basculement

• Le leader Sentinelle en sélectionne un. du nœud esclave en tant que nouveau nœud maître. Voici une réécriture de cette phrase : Pour mettre en œuvre l'élection de l'esclave, la méthode d'élection suivante doit être mise en œuvre : a) Le temps de déconnexion du maître

Si le temps de déconnexion du maître dépasse après millisecondes (configuration sentinelle) * 10 secondes plus le temps écoulé depuis Sentinel. En fonction du temps écoulé entre le moment où le maître est déterminé comme étant indisponible et le moment où Sentinel commence à effectuer le basculement, l'esclave est considéré comme non apte à être promu maître.

b) Priorité des esclaves

Chaque esclave a une priorité, qui est stockée dans le fichier de configuration redis.conf. Si les priorités sont les mêmes, continuez.

c) La position du décalage de réplication

Le décalage de réplication enregistre où les données sont copiées à partir du maître. Plus le décalage de réplication est grand, plus de données sont reçues du maître. Si le décalage de réplication est le même, continuez l'élection

.

d) Run ID

Électez l'esclave avec le plus petit Run ID comme nouveau maître

L'organigramme est le suivant :

• 3) Le chef Sentinelle n'exécutera l'esclave de personne sur le nouveau maître élu lors de l'opération précédente, promouvez-le au rang de nœud maître

• 4) Le chef sentinelle envoie des commandes à d'autres esclaves pour faire des esclaves restants les esclaves du nouveau nœud maître

• 5) Le chef sentinelle le fera rétrograder le maître d'origine en esclave. Lorsque le travail normal reprend, le responsable Sentinel enverra une commande pour copier à partir du nouveau maître. Les opérations de basculement ci-dessus sont toutes effectuées par Sentinel lui-même, sans aucune intervention manuelle.

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!