Quelle est la différence entre le rdb et l'aof de Redis ?

aof et rdb sont deux mécanismes de persistance Redis. Utilisé pour la récupération Redis après un crash. Alors, quelle est la différence entre eux ? L'article suivant vous le présentera, j'espère qu'il vous sera utile.

La différence entre RDB persistant et AOF

La persistance RDB fait référence à l'intervalle de temps spécifié L'instantané de l'ensemble de données dans la mémoire est écrit sur le disque. Le processus opérationnel réel consiste à créer un sous-processus et à écrire d'abord l'ensemble de données dans un fichier temporaire. Une fois l'écriture réussie, le fichier précédent est remplacé et stocké en mode binaire. compression.

RDB conserve toutes les paires clé-valeur dans l'espace clé (y compris les données des dictionnaires expirés) et les enregistre sous forme binaire, qui est conforme aux spécifications du fichier RDB et sera traitée différemment selon les différents types de donné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.

AOF enregistre de manière persistante toutes les commandes d'écriture exécutées par le serveur Redis pour enregistrer l'état de la base de données. Les commandes sont stockées dans le tampon aof_buf avant l'écriture.

Les avantages et inconvénients du RDB et de l'AOF persistants :

Quels sont les avantages du RDB ?

1). Une fois cette méthode adoptée, l'intégralité de votre base de données Redis ne contiendra qu'un seul fichier, ce qui est parfait pour la sauvegarde de fichiers. Par exemple, vous pouvez prévoir d'archiver les données des dernières 24 heures toutes les heures, ainsi que d'archiver les données des 30 derniers jours chaque jour. Grâce à une telle stratégie de sauvegarde, lorsqu'une panne catastrophique survient dans le système, nous pouvons le restaurer très facilement.

2), RDB est un très bon choix pour la reprise après sinistre. Parce que nous pouvons facilement compresser un seul fichier puis le transférer sur d’autres supports de stockage.

3), maximiser les performances. Pour le processus de service Redis, lorsqu'il démarre la persistance, la seule chose qu'il doit faire est de débourser le processus enfant, puis le processus enfant terminera le travail de persistance. Cela peut grandement éviter que le processus de service effectue des opérations d'E/S.

4). Par rapport au mécanisme AOF, si l'ensemble de données est volumineux, l'efficacité du démarrage de RDB sera plus élevée.

Quels sont les inconvénients du RDB ?

1). Si vous souhaitez garantir une haute disponibilité des données, c'est-à-dire éviter au maximum la perte de données, alors RDB ne sera pas un bon choix. Car une fois que le système plante avant la persistance programmée, les données qui n'ont pas eu le temps d'être écrites sur le disque seront perdues.

2). Étant donné que RDB aide à la persistance des données via les processus enfants de fork, si l'ensemble de données est volumineux, l'ensemble du serveur peut cesser de servir pendant des centaines de millisecondes, voire 1 seconde.

Quels sont les avantages de l'AOF ?

1). Ce mécanisme peut apporter une plus grande sécurité des données, c'est-à-dire une persistance des données. Redis propose trois stratégies de synchronisation, à savoir la synchronisation toutes les secondes, la synchronisation à chaque modification et aucune synchronisation. En fait, une synchronisation sur deux est également effectuée de manière asynchrone et son efficacité est également très élevée. La seule différence est qu'une fois le système tombé en panne, les données modifiées au cours de cette seconde seront perdues. Chaque fois qu'une modification est synchronisée, nous pouvons la considérer comme une persistance synchrone, c'est-à-dire que chaque modification de données qui se produit sera immédiatement enregistrée sur le disque. On peut prédire que cette méthode est la moins efficace. Quant à l'absence de synchronisation, inutile d'en dire plus, je pense que tout le monde peut bien le comprendre.

2) Étant donné que ce mécanisme utilise le mode ajout pour écrire les fichiers journaux, même s'il y a un temps d'arrêt pendant le processus d'écriture, le contenu existant dans le fichier journal ne sera pas détruit. Cependant, si nous n'écrivons que la moitié des données lors de cette opération et qu'une panne du système se produit, ne vous inquiétez pas. Avant le prochain démarrage de Redis, nous pouvons utiliser l'outil redis-check-aof pour nous aider à résoudre le problème de cohérence des données.

3). Si le journal est trop volumineux, Redis peut activer automatiquement le mécanisme de réécriture. Autrement dit, Redis écrit en continu les données modifiées sur l'ancien fichier disque en mode ajout. En même temps, Redis crée également un nouveau fichier pour enregistrer les commandes de modification exécutées pendant cette période. Par conséquent, la sécurité des données peut être mieux assurée lors de la réalisation d'une commutation de réécriture.

4), AOF contient un fichier journal clair et facile à comprendre pour enregistrer toutes les opérations de modification. En fait, nous pouvons également compléter la reconstruction des données grâce à ce fichier.

Quels sont les inconvénients de l'AOF ?

1). Pour un même nombre de jeux de données, les fichiers AOF sont généralement plus gros que les fichiers RDB. RDB est plus rapide que AOF lors de la restauration de grands ensembles de données.

2). Selon la stratégie de synchronisation, AOF est souvent plus lent que RDB en termes d'efficacité opérationnelle. En bref, l'efficacité de la stratégie de synchronisation par seconde est relativement élevée et l'efficacité de la stratégie de désactivation de la synchronisation est aussi efficace que celle de RDB.

Le critère de choix entre les deux 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équent et attendez une opération manuelle Lors de la sauvegarde, effectuez une sauvegarde (rdb). RDB a une signification finalement plus cohérente. Cependant, l’environnement de production est en réalité plutôt une combinaison des deux.

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!