1. La différence entre la persistance RDB AOF
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é, à la création d'un processus enfant et à l'écriture préalable du fichier. ensemble de données Écrivez un fichier temporaire Une fois l'écriture réussie, remplacez le fichier précédent et stockez-le avec une compression binaire.
Opération spécifique : parcourez la table de hachage, utilisez la copie en écriture et enregistrez l'intégralité du dump de la base de données.
Les commandes de sauvegarde, d'arrêt et d'esclave déclencheront cette opération.
Caractéristiques : La granularité est relativement importante. Si la sauvegarde, l'arrêt ou l'esclave se sont écrasés auparavant, les opérations intermédiaires ne peuvent pas être restaurées.
La persistance AOF enregistre chaque opération d'écriture et de suppression traitée par le serveur sous la forme d'un journal. Les opérations de requête ne sont pas enregistrées, mais sont enregistrées dans le texte. Vous pouvez ouvrir le fichier pour voir les enregistrements détaillés des opérations. 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 simultanément la persistance AOF et la persistance RDB. 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 pendant l'exécution du serveur.
Caractéristiques : Plus petite granularité Après un crash, seules les opérations qui n'ont pas eu le temps de se connecter avant le crash ne peuvent pas être récupérées.
Le critère de sélection est de voir si le système est prêt à sacrifier certaines performances en échange d'une cohérence de cache plus élevée (aof), ou s'il est prêt à ne pas activer la sauvegarde en échange de performances plus élevées lorsque les opérations d'écriture sont fréquentes, et à attendre que save est exécuté manuellement, puis effectuez une sauvegarde (rdb). RDB a une signification finalement plus cohérente.
2. Avantages et inconvénients d'AOF RDB
AOF :
Avantages : L'utilisation de la persistance AOF rendra Redis beaucoup plus durable : vous pouvez définir différentes stratégies fsync, telles que no fsync, fsync once per second ou fsync à chaque écriture. la commande 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 qui effectue uniquement des opérations d'ajout (ajout uniquement au journal), 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, lorsque l'écriture sur le disque est pleine , 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 réécrit 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. Par conséquent, le contenu du fichier AOF est très facile à lire et il est facile d'analyser le fichier. (analyser). L'exportation de 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é, arrêtez simplement le serveur, supprimez la commande FLUSHALL à la fin du fichier AOF, et redémarrer Redis Vous pouvez restaurer l'ensemble de données à l'état avant l'exécution de FLUSHALL.
Inconvénients :
Pour un même ensemble de données, la taille du fichier AOF est généralement supérieure à la taille du fichier RDB. Selon la stratégie fsync utilisée, AOF peut être plus lent que RDB. 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 élevée. 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 commandes individuelles, 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. Avantages de
RDB :
RDB est un fichier très compact qui enregistre l'ensemble de données Redis à un moment donné. Ce type de fichier est très adapté à la 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 idéal pour la reprise après sinistre : il ne contient qu'un seul fichier, son 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 l'enregistrement du fichier RDB est de débourser un processus enfant, puis le processus enfant gérera tout le travail de sauvegarde ultérieur, et le processus parent n'a pas besoin de le faire. effectuer toutes les opérations d'E/S du disque. RDB est plus rapide que AOF lors de la restauration de grands ensembles de données.
Inconvénients :
Si vous devez éviter de perdre des données en cas de panne du serveur, alors RDB ne vous convient pas. 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 enregistrer l'état de l'ensemble de données. Vous pouvez donc 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.