1. Introduction à redis
REmote DIctionary Server (Redis) est un système de stockage clé-valeur écrit par Salvatore Sanfilippo.
(Partage vidéo d'apprentissage : tutoriel vidéo redis)
Redis est un logiciel open source écrit en langage ANSI C, conforme au protocole BSD, prend en charge le réseau et peut être basé sur la mémoire ou le type de journal persistant, la base de données clé-valeur et fournit des API dans plusieurs langues.
On l'appelle souvent serveur de structure de données car les valeurs peuvent être des chaînes, des hachages, des listes, des ensembles et des ensembles triés) et d'autres types.
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.
Toutes les données dans Redis sont stockées en mémoire, puis enregistrées de manière asynchrone sur le disque de temps en temps (c'est ce qu'on appelle le « mode semi-persistant ») ; chaque modification de données peut également être écrite 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 fournit deux méthodes de persistance, l'une est la persistance RDB (le principe est de vider périodiquement les enregistrements de la base de données Reids en mémoire vers la persistance RDB sur le disque) et l'autre est la persistance AOF (ajouter uniquement un fichier) (le principe est d'écrire l'opération de Reids se connecter au 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é. Le processus opérationnel réel consiste à créer un processus enfant. , Écrivez d'abord l'ensemble de données dans un fichier temporaire. Une fois l'écriture réussie, remplacez le fichier précédent et stockez-le avec compression binaire.
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, 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 le même nombre d’ensembles de données, les fichiers AOF sont généralement plus volumineux 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équentes. Lorsque vous exécutez la sauvegarde manuellement, effectuez à nouveau la sauvegarde (rdb). RDB a une signification finalement plus cohérente.
4. Configurations courantes
Configuration de la persistance RDB
Redis videra l'instantané de l'ensemble de données dans le fichier dump.rdb. 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, ce sont :
appendfsync toujours #Écrire à chaque fois qu'une modification de données se produit Importez 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.
5. Documents de référence
http://blog.csdn.net/jackpk/article/details/30073097 http://www.jb51.net/article/65264.htm
Recommandations associées : Tutoriel sur la 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!