Journal AOF Ce qui est stocké est la séquence d'instructions séquentielles du serveur Redis. .
En supposant que le journal AOF enregistre toutes les séquences d'instructions modifiées depuis la création de l'instance Redis, alors la mémoire de l'instance Redis actuelle peut être restaurée en exécutant séquentiellement toutes les instructions sur une instance Redis vide, c'est-à-dire en "rejouant" le état de la structure des données.
Comparaison des journaux de pré-écriture et de post-écriture
Write Ahead Log (WAL) : écrivez les données modifiées dans le fichier journal avant d'écrire réellement les données, erreur la récupération est garantie.
Par exemple, le journal redo (redo log) dans le moteur de stockage MySQL Innodb est un journal de données qui enregistre les modifications. Le journal des modifications est enregistré avant que les données ne soient réellement modifiées et que les données soient modifiées.
Journal post-écriture : exécutez d'abord la demande de commande « écriture », écrivez les données dans la mémoire, puis enregistrez le journal.
Commande post-écriture AOFFormat du journal
Lorsque Redis reçoit la commande "set key MageByte" , Une fois les données écrites dans la mémoire, Redis écrira le fichier AOF au format suivant.
"*3": Indique que la commande actuelle est divisée en trois parties, chaque partie commence par "$ + numéro", suivi de la "commande, clé" spécifique de cette partie ,valeur".
"Number" : Indique la taille des octets occupés par cette partie de la commande, la clé et la valeur. Par exemple, "$3" signifie que cette partie contient 3 octets, ce qui correspond à la commande "set".
Format du journal AOF «65 Brother : Pourquoi Redis utilise-t-il la journalisation post-écriture ?
»
Les journaux de post-écriture évitent une surcharge de vérification supplémentaire et ne nécessitent pas de vérification de la syntaxe des commandes exécutées. Si vous utilisez la journalisation à écriture anticipée, vous devez d'abord vérifier si la syntaxe est correcte. Sinon, le journal enregistre des commandes incorrectes et une erreur se produira lors de l'utilisation de la récupération du journal.
De plus, l'enregistrement du journal après l'écriture ne bloquera pas l'exécution de la commande "write" en cours.
«Frère 65 : Alors avec AOF, c'est infaillible ?
»
Petit idiot, ce n'est pas si simple. Si Redis vient de terminer l'exécution de la commande et plante avant d'enregistrer le journal, les données liées à la commande risquent d'être perdues.
De plus, AOF évite le blocage de la commande en cours, mais peut entraîner un risque de blocage sur la commande suivante. Le journal AOF est exécuté par le thread principal. Pendant le processus d'écriture du journal sur le disque, si la pression du disque est élevée, l'écriture sur le disque sera très lente, provoquant le blocage des instructions « d'écriture » ultérieures.
Avez-vous découvert que ces deux problèmes sont liés à la réécriture du disque. Si le moment de l'écriture du journal AOF sur le disque après l'exécution de la commande "write" peut être raisonnablement contrôlé, le problème sera résolu.
Stratégie de réécriture
Afin d'améliorer l'efficacité de l'écriture du fichier, lorsque l'utilisateur appelle la fonction write pour écrire des données dans le fichier, le système d'exploitation les enregistre généralement temporairement dans une mémoire tampon et attendez que l'espace tampon soit rempli ou que le délai spécifié soit dépassé avant que les données du tampon ne soient réellement écrites sur le disque.
Bien que cette approche améliore l'efficacité, elle pose également des problèmes de sécurité aux données écrites, car si l'ordinateur s'éteint, les données écrites stockées dans la mémoire tampon seront perdues.
À cet effet, le système fournit deux fonctions de synchronisation, fsync et fdatasync, qui peuvent forcer le système d'exploitation à écrire immédiatement les données du tampon sur le disque dur, assurant ainsi la sécurité du données écrites.
Les éléments de configuration AOF fournis par RedisappendfsyncLa stratégie de réécriture détermine directement l'efficacité et la sécurité de la fonction de persistance AOF.
toujours : écriture synchrone, le contenu du tampon aof_buf sera vidé dans le fichier AOF immédiatement après l'exécution de la commande d'écriture.
everysec : Réécrivez toutes les secondes. Une fois la commande d'écriture exécutée, le journal sera uniquement écrit dans le tampon du fichier AOF et le contenu du tampon sera synchronisé avec le disque toutes les secondes. .
non : Contrôlé par le système d'exploitation, une fois l'exécution de l'écriture terminée, le journal est écrit dans la mémoire tampon du fichier AOF et le système d'exploitation décide quand le vider sur le disque .
Il n'y a pas de stratégie du meilleur des deux mondes, nous devons faire un compromis entre performances et fiabilité.
alwaysL'écriture synchrone peut empêcher la perte de données, mais chaque commande « écriture » doit être écrite sur le disque, qui présente les pires performances.
everysecRéécrivez chaque seconde, évitant ainsi la surcharge de performances de l'écriture synchrone. En cas de temps d'arrêt, les données écrites sur le disque peuvent être perdues pendant une seconde, ce qui constitue un compromis entre performances et fiabilité.
noContrôle du système d'exploitation, après avoir exécuté la commande d'écriture, elle est écrite dans le tampon du fichier AOF, puis les commandes "d'écriture" suivantes peuvent être exécutées. Les performances sont les meilleures, mais beaucoup de données peuvent être exécutées. être perdu.
«65 Frère : Alors comment dois-je choisir une stratégie ?
”
Nous pouvons choisir la stratégie de réécriture en fonction des exigences du système en matière de hautes performances et de haute fiabilité. Pour résumer : si vous souhaitez obtenir des performances élevées, choisissez la stratégie Non si vous souhaitez obtenir une garantie de fiabilité élevée, Choisissez simplement la stratégie Always ; si vous autorisez une petite perte de données mais souhaitez que les performances soient grandement affectées, choisissez la stratégie Everysec. Avantages et inconvénients : Le journal est enregistré uniquement une fois l'exécution réussie, ce qui évite la surcharge des instructions. vérification de la syntaxe. Dans le même temps, l'instruction « écriture » en cours ne sera pas bloquée.
Inconvénients : étant donné qu'AOF enregistre le contenu de chaque instruction, veuillez consulter le format de journal ci-dessus pour le format spécifique. Chaque commande doit être exécutée pendant la récupération après erreur. Si le fichier journal est trop volumineux, l'ensemble du processus de récupération sera très lent. De plus, le système de fichiers a également des restrictions sur la taille des fichiers. Les fichiers trop volumineux ne peuvent pas être enregistrés. À mesure que le fichier devient plus volumineux, l'efficacité de l'ajout diminue.
Le journal est trop volumineux : mécanisme de réécriture AOF
«
65 Frère : Que dois-je faire si le fichier journal AOF est trop volumineux ? ”Le journal de pré-écriture AOF enregistre chaque opération de commande « écriture ». Cela n'entraînera pas de perte de performances comme l'instantané complet de RDB, mais la vitesse d'exécution n'est pas aussi rapide que celle de RDB. En même temps, des fichiers journaux trop volumineux entraîneront également des problèmes de performances pour un vrai homme comme Redis qui veut seulement être rapide. il ne peut absolument pas tolérer les problèmes causés par des bûches trop volumineuses.
Par conséquent, Redis a conçu un "mécanisme de réécriture AOF". Redis fournit la commande pour affiner le journal AOF.
Le principe est d'ouvrir un sous-processus pour parcourir la mémoire et de la convertir en une série d'instructions d'opération Redis, qui sont sérialisées dans un nouveau fichier journal AOF. Une fois la sérialisation terminée, le journal AOF incrémentiel généré pendant l'opération est ajouté au nouveau fichier journal AOF. Une fois l'ajout terminé, l'ancien fichier journal AOF est immédiatement remplacé et le travail d'amincissement est terminé. "Brother 65 : Pourquoi le mécanisme de réécriture AOF peut-il réduire la taille du fichier journal ?bgrewriteaof"
Le mécanisme de réécriture a une fonction "plusieurs modifications en une", qui convertit les anciens journaux en instructions multiples devenues une seule instruction après la réécriture.
est la suivante :
Mécanisme de réécriture AOF (correction d'erreur : 3 instructions ont été enregistrées avant la réécriture) "65 Frère : Après la réécriture, le journal AOF devient plus petit, et finalement le journal des opérations des dernières données de l'ensemble de la base de données est vidé sur le disque. La réécriture bloquera-t-elle le thread principal ? Comme mentionné ci-dessus, le journal AOF est réécrit par le principal ? Le processus de réécriture AOF est en fait complété par le sous-processus en arrière-plan bgrewriteaof pour éviter de bloquer le thread principal. 
Le processus de réécriture est différent du journal AOF réécrit par le thread principal. Le processus de réécriture est complété par le sous-processus d'arrière-plan bgrewriteaof. et entraînant une diminution des performances de la base de données. En général, il existe deux journaux, une copie des données mémoire, qui sont l'ancien journal AOF, le nouveau journal de réécriture AOF et la copie des données Redis.
Redis enregistrera l'opération de commande "write" reçue pendant le processus de réécriture à la fois dans l'ancien tampon AOF et dans le tampon de réécriture AOF, de sorte que le journal de réécriture enregistre également les dernières opérations. Une fois que tous les enregistrements d'opérations des données copiées ont été réécrits, les dernières opérations enregistrées dans le tampon de réécriture seront également écrites dans le nouveau fichier AOF. Chaque fois qu'AOF est réécrit, Redis effectuera d'abord une copie de mémoire pour parcourir les données et générer des enregistrements de réécriture ; utiliser deux journaux pour garantir que les données nouvellement écrites ne seront pas perdues pendant le processus de réécriture et conserver les données. cohérence.
Processus de réécriture AOF
«
65 Brother : La réécriture AOF a également un journal de réécriture, pourquoi ne partage-t-elle pas le journal en utilisant AOF lui-même ? Quoi ? "
C'est une bonne question pour les deux raisons suivantes : 
L'une des raisons est que l'écriture du même fichier entre les processus parent et enfant sera inévitablement provoquer des problèmes de concurrence, contrôler la concurrence signifie affecter les performances du processus parent.
Si le processus de réécriture AOF échoue, le fichier AOF d'origine équivaut à être contaminé et ne peut pas être restauré. Par conséquent, Redis AOF réécrit un nouveau fichier si la réécriture échoue, supprimez simplement le fichier directement. Cela n'affectera pas le fichier AOF d'origine. Une fois la réécriture terminée, remplacez simplement l'ancien fichier.
Modèle de journal hybride Redis 4.0
- Lors du redémarrage de Redis, nous utilisons rarement rdb pour restaurer l'état de la mémoire car beaucoup de données seront perdues . Nous utilisons généralement la relecture des journaux AOF, mais les performances de la relecture des journaux AOF sont beaucoup plus lentes que celles de RDB, donc lorsque l'instance Redis est volumineuse, le démarrage prend beaucoup de temps. Afin de résoudre ce problème, Redis 4.0 apporte une nouvelle option de persistance : la persistance hybride. Stockez le contenu du fichier rdb avec le fichier journal AOF incrémentiel. Le journal AOF ici n'est plus le journal complet, mais le journal AOF incrémentiel qui s'est produit pendant la période allant du début de la persistance à la fin de la persistance. Habituellement, cette partie du journal AOF est très petite.
Ainsi, lorsque Redis redémarre, vous pouvez d'abord charger le contenu rdb, puis relire le journal AOF incrémentiel, qui peut remplacer complètement la relecture complète du fichier AOF précédente, et l'efficacité du redémarrage est grandement améliorée.
Les instantanés de mémoire RDB sont donc effectués à une fréquence légèrement plus lente, en utilisant la journalisation AOF entre deux instantanés RDB pour enregistrer toutes les opérations « d'écriture » survenues pendant la période.
De cette façon, les instantanés n'ont pas besoin d'être exécutés fréquemment. En même temps, comme AOF n'a besoin que d'enregistrer les instructions « d'écriture » qui se produisent entre deux instantanés, il n'a pas besoin d'enregistrer toutes les opérations pour. évitez une taille de fichier excessive.
Résumé
Redis a conçu bgsave et copy-on-write pour éviter l'impact sur les instructions de lecture et d'écriture lors de l'exécution d'instantanés fréquents exerceront une pression sur le disque et. fork bloque le fil principal.
Redis a conçu deux fonctionnalités majeures pour permettre une récupération rapide après un temps d'arrêt sans perte de données.
Pour éviter que le journal ne soit trop volumineux, un mécanisme de réécriture AOF est fourni. Selon le dernier état des données de la base de données, l'opération d'écriture des données est générée en tant que nouveau journal et s'effectue en arrière-plan sans. bloquer le thread principal.
L'intégration d'AOF et de RDB fournit une nouvelle stratégie de persistance et un modèle de journal hybride dans Redis 4.0. Lorsque Redis redémarre, vous pouvez d'abord charger le contenu rdb, puis relire le journal AOF incrémentiel, qui peut remplacer complètement la relecture complète du fichier AOF précédente, et l'efficacité du redémarrage est grandement améliorée.
Enfin, concernant le choix de l'AOF et du RDB, "Code Byte" propose trois suggestions :
Lorsque les données ne peuvent pas être perdues, l'utilisation mixte des instantanés de mémoire et de l'AOF C'est un bon choix ;
Si la perte de données au niveau minute est autorisée, vous ne pouvez utiliser RDB que
Si vous utilisez uniquement AOF ; , soyez prioritaire. Utilisez l'option de configuration Everysec car elle établit un équilibre entre fiabilité et performances.
Après deux articles de la série Redis, les lecteurs devraient avoir une compréhension globale de Redis.
65 Brother : Le fichier RDB peut-il être exécuté toutes les secondes, de sorte que même en cas de temps d'arrêt, jusqu'à 1 seconde de données seront perdues. 
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
