Redis est une base de données clé et valeur avancée. C’est similaire à memcached, mais les données peuvent être conservées et les types de données sont riches. Il y a des chaînes, des listes chaînées, des ensembles et des collections ordonnées. Il supporte le calcul de la somme, de l’intersection et du complément (différence) des collections côté serveur, et prend également en charge diverses fonctions de tri. Ainsi, Redis peut aussi être vu comme un serveur de structures de données.
Toutes les données Redis sont stockées en mémoire puis stockées sur le disque de manière asynchrone de temps en temps (ce qu’on appelle le « mode semi-persistant ») ; Vous pouvez également écrire chaque modification de données dans un fichier Append Only File (AOF) (ce qu’on appelle le « mode persistance complète »).
La première méthode est le filesnapshotting : le redis par défaut fera persister les données sur le disque sous forme d’instantané (un fichier binaire, dump.rdb, ce nom de fichier peut être spécifié), et le format dans le fichier de configuration est : save N M signifie qu’en N secondes, redis prendra un instantané sur disque si au moins M modifications surviennent dans les redis. Bien sûr, nous pouvons aussi effectuer manuellement un save ou un bgsave (asynchrone) pour prendre des instantanés.
Voici une brève introduction au fonctionnement : lorsque Redis doit persister, Redis forke un processus enfant ; Le processus enfant écrit les données dans un fichier RDB temporaire sur le disque ; Lorsque le sous-processus termine d’écrire le fichier temporaire, il remplace la RDB originale, qui a l’avantage de la copie à l’écriture
Il existe aussi une méthode de persistance : Append-only :filesnapshotting méthode Lorsque redis est anormalement mort, les données récentes seront perdues (la quantité de données perdues dépend de la configuration de votre politique de sauvegarde), c’est donc son principal inconvénient : lorsque le volume d’affaires est important, les données perdues sont importantes. La méthode d’ajout uniquement peut obtenir toutes les pertes de données, mais les performances de Redis sont moins performantes. AOF peut être persisté tout au long du processus, il suffit d’être activé dans le fichier de configuration (par défaut est non), seulement « oui » (appendiligne) après activation de l’AOF, chaque fois que Redis exécute une commande pour modifier les données, celle-ci sera ajoutée au fichier AOF, et lorsque Redis est redémarré, le fichier AOF sera lu pour une « relecture » afin de le restaurer jusqu’au dernier moment avant la fermeture de Reddis.
Réécriture LOG À mesure que le fichier AOF devient de plus en plus volumineux à mesure que les données sont modifiées, dont beaucoup enregistrent des changements dans une clé. Par conséquent, redis possède une fonctionnalité intéressante : reconstruire le fichier AOF en arrière-plan sans affecter l’opération côté client. Exécuter la commande BGREWRITEAOF à tout moment écrira la séquence la plus courte de commandes dans la mémoire actuelle sur disque, et ces commandes peuvent construire entièrement la situation de données actuelle sans changements inutiles (comme des changements d’état, des changements de compteurs, etc.), réduisant ainsi la taille du fichier AAF. Donc, lorsqu’on utilise OF, redis recommande aussi d’utiliser BGREWRITEAOF.
Il existe trois façons de rafraîchir le fichier AOF, voir le paramètre de configuration appendfsync : appendfsync appelle toujours fsync pour qu’il se flush dans le fichier AOF à chaque fois qu’une commande de modification est envoyée, ce qui est très, très lent, mais aussi très sûr ; appendfsync every ysec appelle fsync chaque seconde pour se vider rapidement vers le fichier AOF, mais peut perdre des données en moins d’une seconde ; appendfsync no dépend du système d’exploitation pour rafraîchir, Redis ne rafraîchit pas activement l’OV, ce qui est le plus rapide, mais la sécurité est médiocre. Le rafraîchissement par seconde est recommandé par défaut, afin que la vitesse et la sécurité soient prises en compte.
Cela peut être dû à des raisons système que l’AOF est corrompu, Redis ne peut plus charger ce fichier OF l’OV, vous pouvez suivre les étapes ci-dessous pour le corriger : D’abord, faites une sauvegarde du fichier AOF et copiez-le à un autre endroit ; Corriger le fichier OF original, exécuter : $redis-check-aof –fix ; Vous pouvez utiliser la commande diff –u pour voir où les fichiers sont incohérents avant et après la réparation. Redémarrez le service Redis.
Fonctionnement de la réécriture LOG : La même méthode utilise le copy-on-write : le premier redis forke un processus enfant ; Le processus enfant écrit la dernière OF dans un fichier temporaire ; Le processus parent écrit progressivement les dernières modifications exécutées en mémoire (à ce stade, l’ancien AOF est toujours écrit, et il est sûr de réécrire en cas de défaillance) ; Lorsque le processus enfant termine de réécrire le fichier temporaire, le processus parent reçoit un signal et écrit les modifications incrémentales précédentes de la mémoire à la fin du fichier temporaire. Redis renomme l’ancien fichier OF, renomme le fichier temporaire, et commence à écrire dans le nouveau OF.
Enfin, au cas où (machine planterait ou disque), n’oubliez pas de sauvegarder régulièrement le fichier *rdb *.aof généré via filesnapshotting ou uniquement Append-only sur la machine distante. J’utilise un crontab pour SCP toutes les demi-heures. Je n’ai pas utilisé la fonction maître-esclave de Redis, car une sauvegarde d’une demi-heure devrait suffire, et je trouve que c’est un peu un gaspillage de la machine si vous avez un maître-esclave. Cela dépend finalement de l’application.
|
Publié sur 24/08/2017 16:37:45
|
|
|
