Découvrez la persistance RDB et AOP dans Redis dans un seul article

Cet article vous fera découvrir les deux mécanismes de persistance (RDB et AOP) dans redis J'espère qu'il vous sera utile !

Redis est une base de données en mémoire et les données sont stockées dans la mémoire. Cependant, nous savons tous que les données en mémoire changent rapidement et sont sujettes à la perte. Heureusement, Redis nous fournit également des mécanismes de persistance, à savoir RDB (Redis DataBase) et AOF (Append Only File). [Recommandations associées : Tutoriel vidéo Redis]

On suppose ici que vous comprenez déjà la syntaxe de base de redis. Un certain site Web d'alphabet a un bon tutoriel, vous pouvez le consulter. Je n’écrirai pas d’articles sur l’utilisation de base, ce sont toutes des commandes couramment utilisées.

Ce qui suit est une introduction à ces deux méthodes. Du superficiel au profond.

1. Processus de persistance

Puisque les données Redis peuvent être enregistrées sur le disque, à quoi ressemble ce processus ?

Les cinq processus suivants sont requis :

(1) Le client envoie une opération d'écriture au serveur (les données sont dans la mémoire du client).

(2) Le serveur de base de données reçoit les données de la requête d'écriture (les données sont dans la mémoire du serveur).

(3) Le serveur appelle l'appel système write pour écrire les données sur le disque (les données sont dans le tampon de la mémoire système).

(4) Le système d'exploitation transfère les données du tampon vers le contrôleur de disque (les données sont dans le cache disque).

(5) Le contrôleur de disque écrit les données sur le support physique du disque (les données tombent en fait sur le disque).

Ces 5 processus sont un processus de sauvegarde normal dans des conditions idéales, mais dans la plupart des cas, nos machines, etc. connaîtront diverses pannes :

(1) Si la base de données Redis échoue, jusqu'à la troisième. L'étape ci-dessus est terminée, elle peut être conservée et les deux étapes restantes seront complétées pour nous par le système d'exploitation.

(2) Si le système d'exploitation tombe en panne, les 5 étapes ci-dessus doivent être complétées.

Ici, nous ne considérons que les éventuels échecs lors du processus de sauvegarde. En fait, les données enregistrées peuvent également être endommagées, nécessitant un certain mécanisme de récupération, mais celui-ci ne sera pas étendu ici. La principale considération est maintenant de savoir comment Redis implémente les cinq étapes ci-dessus pour sauvegarder les disques. Il fournit deux mécanismes de politique, à savoir RDB et AOF.

2. Mécanisme RDB

RDB enregistre en fait les données sur le disque sous forme d'instantanés. Qu'est-ce qu'un instantané ? Vous pouvez le comprendre comme prendre une photo des données au moment présent et les enregistrer.

La persistance RDB fait référence à l'écriture d'un instantané de l'ensemble de données en mémoire sur le disque dans un intervalle de temps spécifié. C'est également la méthode de persistance par défaut. Cette méthode écrit les données en mémoire dans un fichier binaire sous la forme d'un instantané. Le nom de fichier par défaut est dump.rdb.

Après avoir installé Redis, toutes les configurations se trouvent dans le fichier redis.conf, qui stocke diverses configurations des deux mécanismes de persistance, RDB et AOF.

Étant donné que le mécanisme RDB enregistre toutes les données à un certain moment en générant un instantané, il devrait y avoir un mécanisme de déclenchement pour mettre en œuvre ce processus. Pour RDB, trois mécanismes sont fournis : save, bgsave et automation. Jetons un coup d'œil à chacun séparément

1. Méthode de déclenchement de la sauvegarde

Cette commande bloquera le serveur Redis actuel Lors de l'exécution de la commande de sauvegarde, Redis ne pourra pas traiter d'autres commandes tant que le processus RDB n'est pas terminé. Le processus spécifique est le suivant :

S'il existe un ancien fichier RDB une fois l'exécution terminée, remplacez l'ancien par le nouveau. Nos clients peuvent se compter en dizaines de milliers, voire en centaines de milliers, cette approche n’est donc évidemment pas recommandée.

2. Méthode de déclenchement bgsave

Lorsque cette commande est exécutée, Redis effectuera des opérations d'instantané de manière asynchrone en arrière-plan, et l'instantané peut également répondre aux demandes des clients. Le processus spécifique est le suivant :

L'opération spécifique est que le processus Redis effectue une opération fork pour créer un processus enfant. Le processus de persistance RDB est responsable du processus enfant et se termine automatiquement une fois terminé. Le blocage ne se produit que pendant la phase de fourche et est généralement de très courte durée. Fondamentalement, toutes les opérations RDB dans Redis utilisent la commande bgsave.

3. Déclenchement automatique

Le déclenchement automatique est effectué par notre fichier de configuration. Dans le fichier de configuration redis.conf, il y a les configurations suivantes, que nous pouvons définir :

①save : Ceci est utilisé pour configurer les conditions de persistance RDB qui déclenchent Redis, c'est-à-dire quand enregistrer les données en mémoire sur le disque dur. disque. Par exemple "enregistrer m n". Indique que bgsave est automatiquement déclenché lorsque l'ensemble de données est modifié n fois en m secondes.

La configuration par défaut est la suivante :

# signifie que si au moins 1 valeur clé change dans les 900 secondes, enregistrez 900 1# signifie si au moins 10 valeurs clés changent dans les 300 secondes, enregistrez 300 10# signifie si au moins 10 000 clés changent dans les 60 secondes Si la valeur de une clé change, save save 60 10000

ne nécessite pas de persistance, vous pouvez alors commenter toutes les lignes de sauvegarde pour désactiver la fonction de sauvegarde.

②stop-writes-on-bgsave-error : La valeur par défaut est oui. Lorsque RDB est activé et que la dernière sauvegarde des données en arrière-plan échoue, si Redis cesse de recevoir des données. Cela permettrait à l'utilisateur de se rendre compte que les données n'ont pas été correctement conservées sur le disque, sinon personne ne remarquerait qu'un sinistre s'est produit. Si Redis est redémarré, il peut recommencer à recevoir des données

③rdbcompression, la valeur par défaut est oui. Pour les instantanés stockés sur disque, vous pouvez définir s'il convient de les compresser pour le stockage.

④rdbchecksum : La valeur par défaut est oui. Après avoir stocké l'instantané, nous pouvons également laisser Redis utiliser l'algorithme CRC64 pour la vérification des données, mais cela augmentera la consommation de performances d'environ 10 %. Si vous souhaitez obtenir une amélioration maximale des performances, vous pouvez désactiver cette fonction.

⑤dbfilename : définissez le nom de fichier de l'instantané, la valeur par défaut est dump.rdb

⑥dir : définissez le chemin de stockage du fichier d'instantané. Cet élément de configuration doit être un répertoire, pas un nom de fichier.

Nous pouvons modifier ces configurations pour obtenir les effets souhaités. Parce que la troisième méthode est configurée, nous faisons une comparaison des deux premières :

4 Avantages et inconvénients de RDB

①, avantages

(1) Le fichier RDB est compact et une sauvegarde complète, idéal pour la sauvegarde et la reprise après sinistre.

(2) Lors de la génération d'un fichier RDB, le processus principal Redis fork() un sous-processus pour gérer tous les travaux de sauvegarde. Le processus principal n'a pas besoin d'effectuer d'opérations d'E/S sur disque.

(3) RDB est plus rapide que AOF lors de la restauration de grands ensembles de données.

② Inconvénients

L'instantané RDB est une sauvegarde complète, qui stocke la forme sérialisée binaire des données de mémoire et est très compacte en termes de stockage. Lorsque la persistance des instantanés est effectuée, un processus enfant sera démarré spécifiquement responsable de la persistance des instantanés. Le processus enfant sera propriétaire des données de mémoire du processus parent. Les modifications apportées à la mémoire par le processus parent ne seront pas reflétées par le processus enfant. les données modifiées pendant la persistance de l'instantané ne seront pas reflétées si elles sont enregistrées, les données peuvent être perdues.

3. Mécanisme AOF

La sauvegarde complète prend toujours du temps. Parfois, nous proposons un moyen plus efficace. Le mécanisme de travail est très simple. Redis ajoutera chaque commande d'écriture reçue via la fonction d'écriture dans le fichier. La compréhension populaire est la journalisation.

1. Principe de persistance

Regardez l'image ci-dessous pour son principe :

Chaque fois qu'une commande d'écriture arrive, elle est enregistrée directement dans notre fichier AOF.

2. Principe de réécriture de fichiers

La méthode AOF pose également un autre problème. Les fichiers de persistance deviendront de plus en plus volumineux. Afin de compresser le fichier de persistance de aof. Redis fournit la commande bgrewriteaof. Enregistrez les données en mémoire dans un fichier temporaire sous la forme d'une commande et lancez en même temps un nouveau processus pour réécrire le fichier.

L'opération de réécriture du fichier aof ne lit pas l'ancien fichier aof, mais réécrit tout le contenu de la base de données en mémoire dans un nouveau fichier aof à l'aide de commandes.

3. AOF dispose également de trois mécanismes de déclenchement

(1) Synchronisation à chaque modification toujours : Chaque fois qu'un changement de données se produit, il sera immédiatement enregistré sur le disque. l'intégrité des données est meilleure

( 2) Synchronisez chaque seconde : fonctionnement asynchrone, enregistrez chaque seconde Si la machine tombe en panne en une seconde, les données seront perdues

(3) Non différent : jamais synchronisé

4.

(1) AOF peut Pour mieux protéger les données contre la perte, AOF effectuera généralement une opération fsync via un thread d'arrière-plan toutes les 1 seconde, et un maximum de 1 seconde de données sera perdue. (2) Les fichiers journaux AOF n'ont pas de surcharge d'adressage disque, les performances d'écriture sont très élevées et les fichiers ne sont pas facilement endommagés.

(3) Même si le fichier journal AOF est trop volumineux, les opérations de réécriture en arrière-plan n'affecteront pas la lecture et l'écriture du client.

(4) Les commandes du fichier journal AOF sont enregistrées de manière très lisible. Cette fonctionnalité est très adaptée à la récupération d'urgence d'une suppression accidentelle catastrophique. Par exemple, quelqu'un efface accidentellement toutes les données à l'aide de la commande flushall. Tant que la réécriture en arrière-plan n'a pas eu lieu à ce moment-là, le fichier AOF peut être copié immédiatement, la dernière commande flushall est supprimée, puis le fichier AOF est remis en place. Récupérez automatiquement toutes les données via le mécanisme de récupération

5.

(1) Pour les mêmes données, les fichiers journaux AOF sont généralement plus volumineux que les fichiers d'instantanés de données RDB

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!