Quelle stratégie de persistance est bonne pour Redis ?

Redis fournit une variété de méthodes de persistance à différents niveaux :

La persistance RDB peut générer des ensembles de données dans un intervalle de temps spécifié. -instantané temporel.

AOF enregistre de manière persistante toutes les commandes d'opération d'écriture exécutées par le serveur et restaure l'ensemble de données en réexécutant ces commandes au démarrage du serveur. Toutes les commandes du fichier AOF sont enregistrées au format de protocole Redis et les nouvelles commandes seront ajoutées à la fin du fichier. Redis peut également réécrire le fichier AOF en arrière-plan afin que la taille du fichier AOF ne dépasse pas la taille réelle requise pour enregistrer l'état de l'ensemble de données.

Redis peut également utiliser la persistance AOF et la persistance RDB en même temps. Dans ce cas, au redémarrage de Redis, il donnera la priorité à l'utilisation du fichier AOF pour restaurer l'ensemble de données, car l'ensemble de données enregistré par le fichier AOF est généralement plus complet que l'ensemble de données enregistré par le fichier RDB.

Vous pouvez même désactiver la persistance afin que les données n'existent que lorsque le serveur est en cours d'exécution.

Points de connaissance RDB

Avantages de RDB

RDB est un fichier très compact qui enregistre l'ensemble de données Redis à un certain moment précis. Ce type de fichier est idéal à des fins de sauvegarde : par exemple, vous pouvez sauvegarder un fichier RDB toutes les heures au cours des dernières 24 heures, et également sauvegarder un fichier RDB tous les jours du mois. De cette façon, même si vous rencontrez un problème, vous pouvez toujours restaurer l'ensemble de données vers une version différente.

RDB est très adapté à la reprise après sinistre : il ne contient qu'un seul fichier, et le contenu est très compact, et il peut être transféré (après cryptage) vers d'autres centres de données, ou vers Amazon S3.

RDB peut maximiser les performances de Redis : la seule chose que le processus parent doit faire lors de la sauvegarde du fichier RDB est de débourser un processus enfant, puis le processus enfant gérera tous les travaux de sauvegarde ultérieurs, et le Le processus parent n'a pas besoin d'effectuer d'opérations d'E/S de disque.

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

Inconvénients de RDB

Si vous devez minimiser la perte de données en cas de panne de serveur, alors RDB n'est pas pour vous. Bien que Redis vous permette de définir différents points de sauvegarde pour contrôler la fréquence de sauvegarde des fichiers RDB, ce n'est pas une opération facile car les fichiers RDB doivent sauvegarder l'état de l'ensemble de données. Par conséquent, vous pouvez enregistrer le fichier RDB au moins une fois toutes les 5 minutes. Dans ce cas, en cas de panne, vous risquez de perdre plusieurs minutes de données.

Chaque fois que le RDB est enregistré, Redis doit fork() un processus enfant, et le processus enfant effectuera le travail de persistance réel. Lorsque l'ensemble de données est volumineux, fork() peut prendre beaucoup de temps, ce qui amène le serveur à arrêter de traiter le client dans une certaine milliseconde ; si l'ensemble de données est très volumineux et que le temps CPU est très serré, ce temps d'arrêt peut alors être atteint ; même être plus long pendant une seconde complète. Bien que la réécriture AOF nécessite également fork(), quelle que soit la durée de l'intervalle d'exécution de la réécriture AOF, il n'y aura aucune perte de durabilité des données.

Points de connaissance AOF

Avantages d'AOF

L'utilisation de la persistance AOF rendra Redis très durable (beaucoup plus durable) : Vous pouvez définir différentes stratégies fsync, telles que no fsync, fsync une fois par seconde ou fsync à chaque fois qu'une commande d'écriture est exécutée. La politique par défaut d'AOF est de fsync une fois par seconde. Dans cette configuration, Redis peut toujours maintenir de bonnes performances, et même en cas de panne, une seule seconde de données sera perdue au maximum (fsync sera exécuté dans un thread en arrière-plan). donc le thread principal peut continuer à travailler dur pour traiter les demandes de commandes).

Le fichier AOF est un fichier journal à ajout uniquement, donc l'écriture dans le fichier AOF ne nécessite pas de recherche, même si le journal contient des commandes incomplètes pour certaines raisons (par exemple, le disque est plein lors de l'écriture, le. l'écriture est arrêtée à mi-chemin, etc.), l'outil redis-check-aof peut également résoudre facilement ce problème.

Redis peut réécrire automatiquement l'AOF en arrière-plan lorsque la taille du fichier AOF devient trop grande : le nouveau fichier AOF après la réécriture contient l'ensemble minimum de commandes requis pour restaurer l'ensemble de données actuel. L'ensemble de l'opération de réécriture est absolument sûr, car Redis continuera à ajouter des commandes au fichier AOF existant pendant le processus de création d'un nouveau fichier AOF. Même en cas d'arrêt pendant le processus de réécriture, le fichier AOF existant ne sera pas perdu. . Une fois le nouveau fichier AOF créé, Redis passera de l'ancien fichier AOF au nouveau fichier AOF et commencera à l'ajouter au nouveau fichier AOF.

Le fichier AOF enregistre toutes les opérations d'écriture effectuées sur la base de données de manière ordonnée. Ces opérations d'écriture sont enregistrées au format du protocole Redis, le contenu du fichier AOF est donc très facile à lire et à analyser. file (analyser) est également très simple. Exporter (exporter) des fichiers AOF est également très simple : par exemple, si vous exécutez accidentellement la commande FLUSHALL, mais tant que le fichier AOF n'a pas été écrasé, alors arrêtez simplement le serveur, supprimez la commande FLUSHALL à la fin de l'AOF et redémarrez Redis. Vous pouvez restaurer l'ensemble de données à l'état avant l'exécution de FLUSHALL.

Inconvénients de l'AOF

Pour un même ensemble de données, la taille des fichiers AOF est généralement plus grande que celle des fichiers RDB.

AOF peut être plus lent que RDB selon la stratégie fsync utilisée. Dans des circonstances normales, les performances de fsync par seconde sont toujours très élevées, et la désactivation de fsync peut rendre AOF aussi rapide que RDB, même sous une charge importante. Cependant, RDB peut fournir une latence maximale plus garantie lors de la gestion d'énormes charges d'écriture.

AOF a eu un tel bug dans le passé : en raison de certaines commandes, lorsque le fichier AOF est rechargé, l'ensemble de données ne peut pas être restauré à l'état d'origine lors de sa sauvegarde. (Par exemple, la commande de blocage BRPOPLPUSH a déjà provoqué un tel bug.) Des tests ont été ajoutés à la suite de tests pour cette situation : ils génèrent automatiquement des ensembles de données aléatoires et complexes et rechargent ces données pour garantir que tout est normal. Bien que ce type de bug ne soit pas courant dans les fichiers AOF, en comparaison, il est presque impossible pour RDB d'avoir ce genre de bug.

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!