Introduction à plusieurs méthodes de persistance Redis

1. Introduction

Redis est une base de données clé-valeur avancée. Il est similaire à Memcached, mais les données peuvent être conservées et prennent en charge un large éventail de types de données. Il existe des chaînes, des listes chaînées, des ensembles et des ensembles triés. Il prend en charge le calcul de l'union, de l'intersection et du complément (différence) des ensembles côté serveur, et prend également en charge diverses fonctions de tri. Redis peut donc également être considéré comme un serveur de structure de données. (Recommandé : Tutoriel vidéo Redis)

Toutes les données dans Redis sont stockées en mémoire puis enregistrées sur le disque de manière asynchrone de temps en temps (c'est ce qu'on appelle le « mode semi-persistant » ); Vous pouvez également écrire chaque modification de données dans un fichier d'ajout uniquement (aof) (c'est ce qu'on appelle le « mode de persistance complète »).

Étant donné que les données Redis sont stockées en mémoire, si la persistance n'est pas configurée, toutes les données seront perdues après le redémarrage de Redis. Par conséquent, vous devez activer la fonction de persistance de Redis et enregistrer les données sur le disque. redémarre, Ensuite, les données peuvent être récupérées à partir du disque.

Redis propose deux méthodes de persistance, l'une est la persistance RDB (le principe est de vider régulièrement les enregistrements de la base de données de Reids en mémoire vers la persistance RDB sur le disque), et l'autre est AOF ( ajouter uniquement le fichier) persistance (le principe est d'écrire le journal des opérations de Reids dans le fichier de manière annexée). Alors quelle est la différence entre ces deux méthodes de persistance, et comment choisir ? La plupart des informations que j'ai lues sur Internet expliquent comment configurer et utiliser ces deux méthodes, mais elles n'expliquent pas la différence entre les deux ni les scénarios d'application dans lesquels elles sont utilisées.

2. La différence entre les deux

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é. Fork est un processus enfant et écrit 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é à l'aide d'une compression binaire.

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 seront pas enregistrées, mais seront enregistrées sous forme de texte. . Vous pouvez ouvrir le fichier pour afficher les enregistrements détaillés des opérations.

3. Avantages et inconvénients des deux

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). Pour la reprise après sinistre, RDB est un très bon choix. Parce que nous pouvons facilement compresser un seul fichier puis le transférer sur d’autres supports de stockage.

3). Maximisez 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, toutes 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 clairement formaté 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 lors des opérations d'écriture. sont fréquents. Lorsque vous exécutez la sauvegarde manuellement, effectuez à nouveau la sauvegarde (rdb). RDB a une signification finalement plus cohérente.

4. Configurations communes

Configuration de la persistance RDB

Redis videra l'instantané de l'ensemble de données vers dump.rdb dans le dossier. De plus, nous pouvons également modifier la fréquence des instantanés de dump du serveur Redis via le fichier de configuration. Après avoir ouvert le fichier 6379.conf, nous recherchons save et pouvons voir les informations de configuration suivantes :

save 900 1​​.​​ #900 secondes (15 minutes) plus tard, si au moins une clé change, videz l'instantané de la mémoire.

save 300 10 #Après 300 secondes (5 minutes), si au moins 10 clés ont changé, videz l'instantané de la mémoire.

save 60 10000 #Après 60 secondes (1 minute), si au moins 10 000 clés ont changé, videz l'instantané de la mémoire.

Configuration de la persistance AOF

Il existe trois méthodes de synchronisation dans le fichier de configuration Redis, elles sont :

appendfsync toujours #Chaque fois qu'il y a des données Si une modification se produit, elle sera écrite dans le fichier AOF.

appendfsync Everysec #Synchroniser une fois par seconde Cette politique est la politique par défaut d'AOF.

appendfsync no         # Ne jamais synchroniser. Efficace mais les données ne seront pas conservées.

Pour plus de connaissances sur Redis, veuillez faire attention à la colonne Tutoriel de base de données Redis.

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!