|
|
Publié sur 04/02/2021 13:47:27
|
|
|
|
1. Préface
Récemment, Redis a été utilisé comme cache dans le projet pour faciliter le partage de données entre plusieurs processus métier. Puisque 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, il faut donc activer la fonction de persistance de Redis pour sauvegarder les données sur le disque, et lorsque Redis est redémarré, vous pouvez récupérer les données du disque. Redis offre deux façons de persister : la persistance RDB (le principe consiste à transférer les enregistrements de la base de données de Reids en mémoire vers la persistance RDB sur disque) et l’autre est la persistance AOF (le principe consiste à écrire les journaux d’opérations de Reids dans un fichier sous forme d’annexe). Alors, quelle est la différence entre ces deux méthodes de persistance, et comment choisir de la modifier ? La plupart des choses que j’ai lues sur Internet expliquent comment configurer et utiliser ces deux méthodes, mais il n’y a pas d’introduction à la différence entre les deux, ni aux scénarios applicatifs à utiliser.
2. La différence entre les deux
La persistance RDB consiste à écrire un instantané du jeu de données en mémoire sur disque dans un intervalle de temps spécifié, et le processus opérationnel réel consiste à forker un sous-processus, d’abord écrire le jeu de données dans un fichier temporaire, puis remplacer le fichier précédent après la réussite de l’écriture, et le stocker avec une compression binaire.
La persistance AOF enregistre chaque opération d’écriture et de suppression traitée par le serveur sous forme de journal, et l’opération de requête ne sera pas enregistrée, mais sera enregistrée en texte, et vous pourrez ouvrir le fichier pour voir l’enregistrement détaillé de l’opération.
3. Avantages et inconvénients des deux
Quels sont les avantages du RDB ?
1). Une fois cela utilisé, toute votre base de données Redis ne contiendra qu’un seul fichier, ce qui est parfait pour les sauvegardes de fichiers. Par exemple, vous pouvez vouloir archiver les dernières 24 heures chaque heure, ainsi que les 30 derniers jours chaque jour. Avec une telle stratégie de secours, nous pouvons facilement nous remettre en cas de défaillance catastrophique du système.
2). RDB est un très bon choix pour la reprise après sinistre. Parce que nous pouvons facilement compresser un seul fichier et le transférer sur un autre support de stockage.
3). Maximiser la performance. Pour le processus de service Redis, la seule chose à faire au démarrage de la persistance est de générer les processus enfants, puis les processus enfants accompliront ces tâches de persistance, ce qui peut fortement empêcher le processus de service d’effectuer des opérations d’E/S.
4). Comparé au mécanisme AOF, si le jeu de données est grand, l’efficacité de démarrage de RDB sera plus élevée.
Quels sont les inconvénients de la RDB ?
1) Si vous souhaitez garantir une haute disponibilité des données, c’est-à-dire éviter la perte de données au maximum, alors RDB ne sera pas un bon choix. Car une fois que le système tombe en panne avant la persistance prévue, les données précédemment écrites sur le disque seront perdues.
2). Puisque la RDB aide à la persistance des données via les sous-processus de la fourche, si l’ensemble de données est grand, cela peut entraîner l’arrêt du service de l’ensemble du serveur pendant des centaines de millisecondes, voire 1 seconde.
Quels sont les avantages de l’AOF ?
1). Ce mécanisme peut améliorer la sécurité des données, c’est-à-dire la persistance des données. Deux stratégies de synchronisation sont proposées dans Redis, à savoir la synchronisation par seconde, la synchronisation par modification et la désynchronisation. En fait, la synchronisation par seconde est également faite de façon asynchrone, et son efficacité est également très élevée, la différence étant qu’une fois le système en panne, les données modifiées seront perdues dans cette seconde. Et chaque fois qu’une modification est synchronisée, on peut la considérer comme une persistance de synchronisation, c’est-à-dire que chaque changement de données qui se produit est immédiatement enregistré sur le disque. Il est prévisible que cette méthode soit la moins efficace. Quant à l’absence de synchronisation, il n’est pas nécessaire d’en dire plus, je pense que tout le monde peut bien comprendre.
2). Puisque le mécanisme adopte le mode append pour écrire les fichiers journaliers, même s’il y a un temps mort pendant le processus d’écriture, le contenu déjà présent dans le fichier journal ne sera pas détruit. Cependant, si nous n’écrivons que la moitié des données et que le système plante cette fois, ne vous inquiétez pas, nous pouvons utiliser l’outil redis-check-aof pour nous aider à résoudre le problème de cohérence des données avant le prochain démarrage de Redis.
3). Si le journal est trop grand, Redis peut activer automatiquement le mécanisme de réécriture. C’est-à-dire que Redis écrit en continu les données de modification dans l’ancien fichier disque en mode append, et Redis crée également un nouveau fichier pour enregistrer les commandes de modification exécutées durant cette période. Ainsi, la sécurité des données peut être mieux garantie lors du passage entre les réécritures.
4). AOF contient un fichier journal clair et facile à comprendre qui enregistre toutes les modifications. En fait, nous pouvons aussi compléter la reconstruction des données via ce fichier.
Quels sont les inconvénients de l’OV ?
1). Pour le même nombre de jeux de données, les fichiers OF sont généralement plus grands que les fichiers RDB. RDB récupère de grands ensembles de données plus rapidement qu’AOF.
2). Selon la stratégie de synchronisation, AOF tend à être plus lent que RDB en termes d’efficacité de fonctionnement. En résumé, l’efficacité de la politique de synchronisation par seconde est relativement élevée, et l’efficacité de la politique de désactivation synchrone est aussi efficace que celle de RDB.
Les critères pour choisir les deux sont de savoir si le système est prêt à sacrifier une partie des performances en échange d’une plus grande cohérence du cache (AOF), ou s’il est prêt à ne pas activer les sauvegardes en échange de meilleures performances lorsque les opérations d’écriture sont fréquentes, puis à effectuer des sauvegardes (RDB) lors de l’exécution manuelle de sauvegarde. RDB a une signification plus finale et cohérente. Cependant, l’environnement de production est en réalité plutôt une combinaison des deux.
4. Configurations courantes
Configuration de persistance RDB
Redis dépose un instantané du jeu 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 nous pouvons voir les informations de configuration suivantes :
Configuration persistante AOF
Il existe trois façons de synchroniser dans le profil Redis, à savoir :
Configuration complète :
Un nouveau fichier « appendonly.aof » sera créé sous le répertoire de test, comme suit :
|
Précédent:DataTables implémente l’exportation de tables, Excel, CSV et l’impressionProchain:SQL Server définit le niveau d’isolation des transactions
|
Propriétaire|
Publié sur 08/02/2021 11:45:25
|
Publié sur 22/09/2021 20:26:16