Notes partagées : Lien : https://pan.baidu.com/s/1FkzaOQ73NfBITmsEk3GjiA?pwd=apeb Code d'extraction : apeb

Septième, la persistance de Redis

Redis est une base de données en mémoire, donc sa performance est très élevée. Mais il existe un problème : les données en mémoire ne sont pas persistantes, si l'hôte tombe en panne ou si Redis s'arrête et redémarre, toutes les données en mémoire seront perdues.

Redis a une fonction de persistance, la persistance de Redis se divise en deux types :

• RDB : forme de capture instantanée qui stocke les données sur le disque
• AOF : forme de journal d'opérations qui stocke les données sur le disque

Principe de base de la persistance de Redis

• Désactivation

La persistance de Redis est également appelée désactivation, c'est-à-dire que les informations d'état de la base de données en mémoire sont sauvegardées sur le disque.

Par des méthodes manuelles, ou par des méthodes automatiques à intervalles réguliers, ou par des déclenchements automatiques selon certaines conditions, les informations d'état de la base de données en mémoire sont écrites dans un fichier de persistance spécifié.

Ce n'est qu'une technologie de persistance différente, les informations d'état des données sont différentes, les fichiers de persistance générés sont également différents.

Mais leur objectif est le même : éviter la perte accidentelle de données.

• Activation

Lorsque le système redémarre, le fichier de persistance est chargé automatiquement, et les données sont restaurées en mémoire selon les informations d'état de la base de données contenues dans le fichier, ce processus de restauration est également appelé activation.

Ce processus de désactivation et d'activation est le principe de base de la persistance de Redis.

Cependant, d'après l'analyse ci-dessus, pour Redis en mode simple, qu'il s'agisse de méthodes manuelles, d'intervalles ou de déclenchements conditionnels, il existe un problème de perte de données : si Redis tombe en panne avant qu'une sauvegarde manuelle ou automatique ne soit effectuée, alors les données créées entre la dernière sauvegarde et la panne seront perdues.

Les taux de perte de données diffèrent selon les méthodes de persistance.

Il convient de noter que RDB est la méthode de persistance par défaut, mais Redis permet d'activer à la fois les technologies de persistance RDB et AOF. Dans ce cas, le système utilise la méthode AOF pour la persistance, c'est-à-dire que la priorité de la technique de persistance AOF est plus élevée.

De la même manière, lorsqu'on active simultanément les deux techniques, si les deux fichiers de persistance existent, le système charge en priorité le fichier de persistance AOF.

1. Persistance RDB

RDB (Redis DataBase) fait référence à la technique de persistance qui écrit une copie d'état complète des données en mémoire dans un fichier rdb spécifique.

La persistance RDB est activée par défaut.

Lorsque Redis démarre, il lit automatiquement le fichier de capture instantanée RDB et charge les données du disque en mémoire pour restaurer l'état de la base de données avant l'arrêt de Redis.

7.1.1. Exécution de la persistance

Il y a trois façons d'exécuter la persistance RDB

• Commande save manuelle
• Commande bgsave manuelle
• Déclenchement automatique des conditions

(1). Commande save manuelle

En exécutant la commande save dans le client redis-cli, on peut effectuer immédiatement une sauvegarde.

La commande save bloque le processus redis-server pendant son exécution jusqu'à ce que le processus de persistance soit terminé.

Pendant la période de blocage du processus redis-server, Redis ne peut pas traiter aucune demande de lecture ou d'écriture, et ne peut donc pas fournir de service.

[Exemple]

Insérer quelques données et appeler manuellement la méthode save.

(2). Commande bgsave manuelle

En exécutant la commande bgsave dans le client redis-cli, on peut effectuer immédiatement une sauvegarde.

La commande bgsave génère un sous-processus pour le serveur redis-server, qui est responsable de la sauvegarde.

Pendant le processus de sauvegarde, le sous-processus ne bloque pas le traitement des demandes de lecture et d'écriture du client par le processus redis-server.

(3). Déclenchement automatique des conditions

Le déclenchement automatique des conditions est en réalité l'exécution de la commande bgsave, mais c'est l'utilisateur qui configure les paramètres dans le fichier de configuration, puis Redis appelle automatiquement la commande bgsave.

La configuration se fait dans le fichier redis.conf en modifiant les paramètres suivants.

Par défaut, si le nombre de modifications dépasse 10000 en 60 secondes, ou 100 en 300 secondes, ou 1 en 3600 secondes, une capture instantanée est déclenchée.

7.1.2. Vérification du moment de la persistance

La commande lastsave permet de vérifier le moment de la dernière persistance, elle renvoie un horodatage Unix, pas le temps écoulé depuis la dernière sauvegarde.

7.1.3. Configuration de la persistance

Les paramètres liés à RDB sont situés dans la section SNAPSHOTTING du fichier redis.conf.

(1). Moments de déclenchement des captures instantanées

Cette configuration est utilisée pour définir les conditions de déclenchement des captures instantanées.

Ces conditions sont basées sur le nombre d'opérations d'écriture effectuées pendant une période donnée.

Par défaut, les conditions de persistance sont définies comme save 3600 1 300 100 60 10000, ce qui équivaut aux trois lignes suivantes :

• save 3600 1 # 1 opération d'écriture après 3600 secondes (1 heure)
• save 300 100 # 100 opérations d'écriture après 300 secondes (5 minutes)
• save 60 10000 # 10 000 opérations d'écriture après 60 secondes (1 minute)

Si vous ne souhaitez pas activer la persistance RDB, il suffit de définir les paramètres save sur une chaîne vide : save "".

(2). Alertes en cas d'erreur

Par défaut, si la persistance RDB est activée (au moins un point de sauvegarde) et que la dernière commande bgsave a échoué, Redis arrête l'acceptation des écritures, afin que l'utilisateur prenne conscience que les données n'ont pas été correctement sauvegardées sur le disque, sinon personne ne le remarquerait et cela pourrait entraîner des catastrophes.

Si la commande bgsave fonctionne normalement par la suite, Redis autorisera automatiquement à nouveau les écritures.

Bien sûr, si vous avez d'autres moyens de surveillance pour surveiller redis, vous pouvez définir sur no.

(3). Compression activée

Lors de la persistance, la compression des objets de chaîne est activée.

Bien que la compression des fichiers RDB consomme des ressources système et réduise les performances, elle réduit considérablement la taille du fichier, facilitant ainsi le stockage sur disque et accélérant la synchronisation des nœuds esclaves dans un cluster principal-secodnaire.

(4). Vérification de la somme de contrôle

À partir de la version RDB5, la somme de contrôle CRC64 est placée à la fin du fichier RDB.

Cela rend le format plus résistant aux dommages du fichier RDB, mais affecte les performances lors de l'enregistrement et du chargement des fichiers RDB (environ 10 %), donc vous pouvez la désactiver en définissant sur no pour obtenir les meilleures performances.

Dans le cas où la somme de contrôle est désactivée, la somme de contrôle du fichier RDB est nulle, ce qui indique au code de chargement de sauter la vérification.

Par défaut, yes signifie que la vérification est activée.

(5). Surveillance de sécurité

La configuration sanitize-dump-payload est utilisée pour définir si la surveillance de sécurité complète des listes zip, listPack, etc., est activée lors du chargement du fichier RDB ou lors de la persistance.

Cette surveillance réduit la possibilité de crash du système lors du traitement des commandes.

Les valeurs possibles sont trois :

• no : pas de surveillance
• yes : toujours surveiller
• clients : uniquement surveiller lorsqu'un client est connecté, excluant la surveillance lors du chargement du fichier RDB et lors de la persistance

La valeur par défaut devrait être clients, mais cela affecte le fonctionnement du cluster Redis, donc la valeur par défaut est no, sans surveillance.

(6). Nom du fichier de capture instantanée

La configuration dbfilename est utilisée pour spécifier le nom par défaut du fichier RDB, qui est par défaut dump.rdb.

(7). Suppression des fichiers de synchronisation

La configuration rdb-del-sync-files est utilisée pour définir si les fichiers RDB sur les nœuds esclaves utilisés pour la synchronisation sont supprimés lors de la réplication maître-esclave.

Par défaut, no ne supprime pas.

Cependant, il faut noter que cela n'est efficace que lorsque les fonctions de persistance RDB et AOF des nœuds esclaves ne sont pas activées.

(8). Répertoire de travail

La configuration dir est utilisée pour spécifier le répertoire de génération des fichiers RDB et AOF.

Par défaut, il s'agit du répertoire d'installation de Redis.

7.1.4. Structure du fichier RDB

Le fichier RDB dump.rdb comporte cinq parties principales

cat /usr/local/install/redis/dump.rdb

(1). SOF

SOF est une constante, une chaîne REDIS, contenant uniquement ces cinq caractères, sa longueur est de 5.

Il sert à identifier le début du fichier RDB, afin de pouvoir rapidement déterminer s'il s'agit d'un fichier RDB lors du chargement.

(2). rdb_version

C'est un entier, de 4 octets, représentant le numéro de version du fichier RDB.

(3). EOF

EOF est une constante, occupant 1 octet, utilisée pour identifier la fin des données RDB, le début de la somme de contrôle.

(4). check_sum

La somme de contrôle check_sum est utilisée pour vérifier si les données du fichier RDB sont endommagées.

Elle utilise l'algorithme CRC.

• Algorithme CRC
• Lors de la persistance

On concatène d'abord les données binaires de SOF, rdb_version et de la capture instantanée de la base de données en mémoire pour former un nombre binaire (appelé a), puis on utilise ce a pour diviser la somme de contrôle check_sum, ce qui donne un reste b, puis on ajoute ce b à la fin de a pour former databases

• Lors du chargement

Il faut d'abord utiliser check_sum pour vérifier les dommages du fichier RDB

Processus de vérification : il suffit de diviser les données du fichier RDB, à l'exception de EOF et check_sum, par check_sum

Si le reste n'est pas 0, cela signifie que le fichier est endommagé

Bien sûr, si le reste est 0, on ne peut pas affirmer que le fichier n'est pas endommagé

Cet algorithme de vérification est une vérification de dommages, pas une vérification de non-dommage.

(5). databases

La partie databases est la partie la plus importante du fichier RDB, pouvant contenir plusieurs bases de données non vides.

Chaque base de données est composée de trois parties :

• SODB : une constante, occupant 1 octet, utilisée pour identifier le début d'une base de données
• db_number : numéro de base de données
• key_value_pairs : les paires clé-valeur de cette base de données

Chaque key_value_pairs est composé de plusieurs éléments décrivant les paires clé-valeur.

• VALUE_TYPE : une constante, occupant 1 octet, utilisée pour identifier le type de value dans cette paire clé-valeur
• EXPIRETIME_UNIT : une constante, occupant 1 octet, utilisée pour identifier si l'unité du délai d'expiration est en secondes ou en millisecondes
• time : le délai d'expiration de la paire clé-valeur actuelle

7.1.5. Processus de persistance

Pour la persistance RDB par défaut de Redis, lors de l'exécution de bgsave, le processus redis-server fork un sous-processus bgsave, qui est responsable de la persistance de manière asynchrone. Pendant le processus de persistance, le processus redis-server ne bloque pas, il continue de recevoir et de traiter les requêtes de lecture et d'écriture des utilisateurs.

Le fonctionnement détaillé du sous-processus bgsave est le suivant

Le sous-processus bgsave copie d'abord l'ensemble des données en mémoire vers un fichier temporaire RDB sur le disque, puis renomme ce fichier en dump.rdb, remplaçant le fichier existant du même nom.

Si le processus redis-server reçoit des demandes d'écriture pendant la persistance, le système copiera une copie des blocs de mémoire modifiés. Une fois que la copie de l'ensemble des données en mémoire est terminée, les données de la copie seront copiées dans le fichier temporaire RDB.

Cette copie est réalisée grâce à la technologie Copy-On-Write de Linux.

7.1.6. Technologie de copie à la demande

La technologie de copie à la demande est une technologie de gestion de processus du système Linux.

Initialement, dans les systèmes Unix, lorsqu'un processus principal crée un processus enfant via l'appel système fork(), le noyau copie l'ensemble des données de l'espace mémoire du processus principal, puis les alloue au processus enfant. Ce processus présente les problèmes suivants :

• Ce processus est très chronophage
• Ce processus réduit les performances du système
• Si le processus principal modifie ses données en mémoire, les données du processus enfant ne sont pas modifiées (c'est-à-dire qu'il y a une redondance de données), et la redondance de données est le principal problème de la garantie de cohérence des données

Les systèmes Linux modernes utilisent un moyen plus efficace : la copie à la demande.

Le processus enfant hérite de toutes les ressources du processus parent, y compris l'espace mémoire du processus principal. Cela signifie que le processus enfant et le processus parent partagent la mémoire. Tant que la mémoire est partagée, elle est en lecture seule (protégée en écriture). Lorsqu'une partie veut écrire dans la mémoire partagée, une exception se produit, et le noyau copiera les données nécessaires dans une autre zone de mémoire non partagée.

2. Persistance AOF

AOF (Append Only File) désigne la technique de persistance où chaque opération d'écriture est enregistrée sous forme de journal dans un fichier AOF.

Lorsqu'il est nécessaire de restaurer les données en mémoire, ces opérations d'écriture sont exécutées à nouveau, ce qui permet de retrouver l'état des données en mémoire précédent.

7.2.1. Configuration AOF

(1). Activer la configuration AOF

Par défaut, la persistance AOF n'est pas activée. En modifiant l'attribut appendonly du fichier de configuration en yes, on peut l'activer.

AOF et RDB peuvent être activés en même temps. Si AOF est activé au démarrage, Redis chargera AOF, c'est-à-dire que le fichier a une meilleure garantie de persistance.

Attention, lors de la modification de cette valeur dans le fichier de configuration de la base de données existante, le redémarrage du serveur peut entraîner une perte de données. Il faut d'abord configurer via la commande CONFIG sur le serveur en temps réel.

config get appendonly

config set appendonly yes

config get appendonly

config rewrite

(2). Configuration du nom du fichier

Redis 7 a subi un changement majeur ici. Il n'y avait qu'un seul fichier appendonly.aof auparavant, maintenant il existe trois types de fichiers.

• Fichier de base

Peut être au format RDF ou AOF

Le contenu stocké est le snapshot de la mémoire au moment de la conversion de RDB en AOF

Ce fichier peut avoir plusieurs instances

• Fichier incrémental

Enregistre les opérations d'écriture sous forme de journal incrémental

Ce fichier peut avoir plusieurs instances

• Fichier de liste

Utilisé pour maintenir l'ordre de création des fichiers AOF, assurer l'ordre d'application lors de l'activation

Ce fichier n'en a qu'un seul

(3). Configuration du répertoire

Pour faciliter la gestion, on peut spécifier un répertoire dédié pour les fichiers de persistance AOF.

Le nom du répertoire est spécifié par l'attribut appenddirname, il est stocké dans le répertoire spécifié par l'attribut dir du fichier de configuration redis.conf, par défaut c'est le répertoire d'installation de Redis.

(4). Configuration de la stratégie de synchronisation

appendfsync est utilisé pour configurer la stratégie de synchronisation.

Lorsqu'une commande d'écriture du client est soumise, cette commande est d'abord insérée dans aof_buf (tampon AOF), et le processus de persistance des données dans aof_buf vers le fichier AOF sur le disque est appelé synchronisation des données.

En utilisant différentes stratégies de synchronisation des données, les moments de synchronisation sont différents, il y a trois stratégies :

• always

Après l'écriture de la commande d'écriture dans aof_buf, fsync() est immédiatement appelé, ajoutant la commande au fichier AOF

Cette stratégie a une faible efficacité, mais est plus sécurisée, ne perdant pas trop de données, au maximum la dernière commande d'écriture qui n'a pas encore été synchronisée avant une panne ou un redémarrage, ce qui entraîne la perte de cette commande

• no

Après l'écriture de la commande d'écriture dans aof_buf, rien n'est fait, fsync() n'est pas appelé

La synchronisation des données de aof_buf vers le disque est gérée par le système d'exploitation

Le système Linux synchronise par défaut toutes les 30 secondes, ce qui est efficace

• everysec

Stratégie par défaut

Après l'écriture de la commande d'écriture dans aof_buf, fsync() n'est pas appelé directement, mais une fois par seconde, fsync() est appelé pour effectuer la synchronisation

Cette stratégie équilibre les performances et la sécurité, c'est une solution intermédiaire

(5). Synchronisation pendant la réécriture

La propriété no-appendfsync-on-rewrite est utilisée pour spécifier si le processus principal appelle fsync() pour la synchronisation des données lorsqu'elle est configurée sur always ou everysec, et que le processus principal crée un sous-processus pour exécuter bgsave ou bgrewriteaof.

• Défini sur no

Double négation signifie affirmation, le processus principal appelle fsync() pour la synchronisation

Si fsync() est appelé, lorsqu'une grande quantité de données doit être synchronisée, cela bloquera le processus principal pour fournir un service, c'est-à-dire qu'il y aura un retard

• Défini sur yes

Ne pas appeler fsync() pour la synchronisation des données

Si fsync() n'est pas appelé, la stratégie de synchronisation AOF est équivalente à no, risquant une perte de données de 30 secondes

(5). Moment de la réécriture

• auto-aof-rewrite-percentage

Pourcentage d'augmentation pour activer la réécriture, par défaut 100%

Si défini sur 0, la réécriture est désactivée

La valeur par défaut est 100

• auto-aof-rewrite-min-size

Taille minimale du fichier de réécriture, empêchant une croissance rapide du pourcentage lorsque le fichier est petit, ce qui pourrait entraîner une baisse des performances

La valeur par défaut est de 64 Mo

(6). Troncature du fichier

La configuration aof-load-truncated est utilisée pour spécifier si le fichier AOF est tronqué lorsqu'il est endommagé.

Pendant le processus de persistance AOF, il peut survenir une panne soudaine du système, ce qui signifie que la dernière donnée écrite dans le fichier AOF peut être incomplète.

Lorsque l'hôte redémarre, si le fichier AOF est incomplet, il est possible de lancer Redis, en fonction de la configuration de aof-load-truncated.

Sa valeur est :

• yes : les données inachevées à la fin du fichier AOF sont tronquées directement, sans affecter le lancement de Redis
• no : les données inachevées à la fin du fichier AOF ne peuvent pas être tronquées, Redis ne peut pas démarrer

(7). Activer la persistance mixte

La configuration aof-use-rdb-preamble est utilisée pour activer la persistance mixte.

Pour le fichier de base, il peut être au format RDF ou AOF, et la sélection est faite via la propriété aof-use-rdb-preamble.

Sa valeur par défaut est yes, c'est-à-dire que le fichier de base de la persistance AOF est un fichier au format RDB, c'est-à-dire que la persistance mixte est utilisée par défaut.

(8). Ajout d'une horodatage

La propriété aof-timestamp-enabled définie sur yes active la fonction d'affichage de l'horodatage dans le fichier AOF, facilitant la récupération des données par date.

Cependant, cela peut ne pas être compatible avec le parseur AOF, donc la valeur par défaut est no, sans activation.

(9). Configuration de la taille de flush

Lorsque bgrewriteaof est exécuté, il écrit d'abord les résultats de la réécriture dans aof_rewrite_buf, puis lorsque la quantité de données dans le tampon atteint un seuil, il appelle fsync() pour le flush, c'est-à-dire la synchronisation des données, écrivant les données dans un fichier temporaire.

La propriété aof-rewrite-incremental-fsync est utilisée pour contrôler la taille maximale du flush par fsync() de 4 Mo, évitant ainsi un blocage prolongé causé par un volume de flush trop important.

7.2.2. Format du fichier AOF

Le fichier AOF comprend trois types de fichiers.

• Fichier de base

Généralement au format RDB

• Fichier incrémental
• Fichier de liste

(1). Protocole Redis

Le fichier incrémental a l'extension .aof et utilise le format AOF.

Le format AOF est en réalité le format du protocole de communication Redis. Le fichier de persistance AOF est essentiellement un texte basé sur le protocole de communication Redis, où les commandes sont écrites en tant que texte brut dans le fichier.

Le protocole Redis stipule :

• Les textes Redis sont divisés en lignes, chaque ligne se termine par \r\n
• Chaque ligne a un en-tête de message, qui indique le type de message
• L'en-tête est représenté par six symboles différents, dont les significations sont les suivantes :
• (+) indique un message d'état correct
• (-) indique un message d'erreur
• (*) indique le nombre total de lignes du corps du message, sans inclure la ligne actuelle
• ($) indique la longueur des données du prochain message, sans inclure la longueur de \r\n
• ( ) indique une donnée de message
• (😃 indique un nombre renvoyé

(2). Affichage du fichier AOF

Ouvrez le fichier appendonly.aof.1.incr.aof, vous verrez le format suivant :

Le contenu encadré représente trois commandes : une commande de changement de base de données SELECT 0, deux commandes set.

Leur signification est la suivante :

*2	-- indique que la commande actuelle contient 2 paramètres
$6	-- indique que le premier paramètre contient 6 caractères
SELECT	-- premier paramètre
$1	-- indique que le deuxième paramètre contient 1 caractère
0	-- deuxième paramètre
*3	-- indique que la commande actuelle contient 3 paramètres
$3	-- indique que le premier paramètre contient 3 caractères
set	-- premier paramètre
$3	-- indique que le deuxième paramètre contient 3 caractères
k11	-- deuxième paramètre
$3	-- indique que le troisième paramètre contient 2 caractères
v11	-- troisième paramètre
*3	

(3). Fichier de liste

Ouvrez le fichier de liste appendonly.aof.manifest, consultez son contenu comme suit :

Ce fichier liste d'abord tous les fichiers de base selon le numéro de séquence seq, le type de fichier de base est b, puis liste tous les fichiers incrémentaux selon le numéro de séquence seq, le type de fichier incrémental est i.

Lors de la récupération des données lors du démarrage de Redis, il charge les données de ces fichiers dans l'ordre.

7.2.3. Mécanisme de réécriture

Au fil du temps, le fichier AOF devient de plus en plus volumineux.

Pour éviter que le fichier AOF ne prenne trop de place sur le disque, ralentissant les performances, Redis a introduit le mécanisme de réécriture pour compresser le fichier AOF.

(1). Qu'est-ce que la réécriture ?

La réécriture est en fait une réécriture et une optimisation du fichier AOF.

Lorsque la réécriture est activée, le processus principal redis-server crée un sous-processus bgrewriteaof, qui effectue le processus de réécriture.

Il commence par effectuer une réécriture du fichier AOF existant, écrit les résultats de la réécriture dans un fichier temporaire, puis renomme ce fichier temporaire en nom de fichier AOF original, remplaçant le fichier original.

(2). Règles de calcul de la réécriture

Le calcul de la réécriture est appelé stratégie de réécriture.

Le calcul de la réécriture suit les règles suivantes :

• Les commandes de lecture ne sont pas écrites dans le fichier
• Les commandes inutiles ne sont pas écrites dans le fichier
• Les données expirées ne sont pas écrites dans le fichier
• Plusieurs commandes sont écrites dans le fichier

(3). Mode d'activation de la réécriture

L'exécution du processus de réécriture se fait en deux modes :

• Via la commande bgrewriteaof manuelle
• Via la configuration automatique des conditions

Activation manuelle de la réécriture

Voici la méthode d'activation manuelle

Cette commande fera créer au processus principal redis-server un sous-processus bgrewriteaof, qui effectuera le processus de réécriture.

Pendant la réécriture, redis-server peut continuer à fournir des services de lecture et d'écriture.

Activation automatique de la réécriture

La méthode manuelle nécessite une intervention humaine, donc on utilise généralement la méthode automatique.

Étant donné que le processus de réécriture est un processus de calcul, il consomme beaucoup de ressources système, ce qui réduit les performances du système. Par conséquent, le processus de réécriture n'est pas lancé à tout moment, mais est déclenché uniquement lorsqu'un certain seuil est atteint, afin de réduire l'impact sur les performances.

Voici la configuration dans le fichier de configuration pour les conditions d'activation automatique de la réécriture :

• auto-aof-rewrite-percentage

Pourcentage d'augmentation pour activer la réécriture, par défaut 100%

Spécifier 0 désactive la réécriture automatique

• auto-aof-rewrite-min-size

Taille minimale du fichier AOF pour activer la réécriture, par défaut 64 Mo

Cette valeur est principalement configurée pour empêcher les petits fichiers AOF d'être réécrits, ce qui pourrait entraîner une baisse des performances

Lorsque la taille du fichier AOF augmente à un pourcentage prédéfini, le processus principal redis-server fera un fork d'un sous-processus bgrewriteaof pour effectuer le processus de réécriture.

Son fonctionnement est le suivant : Redis se souvient de la taille du fichier AOF après la dernière réécriture comme taille de base. Si aucun réécriture n'a eu lieu depuis le démarrage du serveur, la taille de base sera la taille du fichier AOF au démarrage.

Si le fichier AOF actuel est supérieur au pourcentage seuil spécifié dans le fichier de configuration par rapport à la taille de base, et si le fichier AOF actuel est supérieur à la taille seuil minimale spécifiée dans le fichier de configuration, la réécriture est déclenchée.

7.2.4. Processus de persistance

Le processus détaillé de la persistance AOF est le suivant

1. Les commandes d'écriture reçues par Redis ne sont pas directement ajoutées au fichier AOF sur le disque, mais sont temporairement ajoutées au tampon AOF aof_buf selon le format du protocole Redis.
2. Selon la stratégie de synchronisation des données configurée, lorsqu'elle est satisfaite, les données du tampon sont écrites en une seule fois sur le fichier AOF sur le disque, afin de réduire le nombre d'accès au disque et d'améliorer les performances.
3. Lorsque la taille du fichier AOF sur le disque atteint les conditions de réécriture, le processus principal redis-server fera un fork d'un sous-processus bgrewriteaof, qui effectuera le processus de réécriture.
4. Le sous-processus bgrewriteaof effectue d'abord un calcul de réécriture sur le fichier AOF sur le disque, écrit les résultats du calcul dans un fichier temporaire, puis renomme ce fichier temporaire en le nom du fichier AOF original, remplaçant le fichier original.
5. Si des commandes d'écriture sont ajoutées pendant le processus de réécriture, ces données seront temporairement écrites dans le tampon aof_rewrite_buf. Une fois que les résultats de la réécriture ont été entièrement écrits dans le fichier temporaire, les données du tampon aof_rewrite_buf seront d'abord écrites dans le fichier temporaire, puis renommées en le nom du fichier AOF original, remplaçant le fichier original.

3. Comparaison entre RDB et AOF

7.3.1. Avantages et inconvénients de RDB

(1). Avantages de RDB

• Le fichier RDB est petit
• La restauration des données est rapide

(2). Inconvénients de RDB

• La sécurité des données est faible
• La copie à la demande réduit les performances
• Le fichier RDB est peu lisible

7.3.2. Avantages et inconvénients de AOF

(1). Avantages de AOF

• La sécurité des données est élevée
• Le fichier AOF est facile à lire

(2). Inconvénients de AOF

• Le fichier AOF est volumineux
• Les opérations d'écriture affectent les performances
• La restauration des données est lente

7.3.3. Choix de la technologie de persistance

• La recommandation officielle est d'utiliser la persistance mixte RDB et AOF
• Si la sécurité des données n'est pas très importante, la persistance pure RDB est recommandée
• Il est déconseillé d'utiliser la persistance pure AOF
• Si Redis est utilisé uniquement comme cache, aucune technologie de persistance n'est nécessaire