Comparaison des compromis de performance entre AOF et RDB

La persistance Redis est un compromis entre la quantité de données que vous pouvez vous permettre de perdre et la charge de travail disque que votre serveur peut absorber. Cependant, lorsque la persistance est activée—permettant de sauvegarder les données sur disque pour une récupération après un redémarrage—les développeurs doivent choisir un mécanisme. Les deux principales méthodes de persistance dans Redis sont le Snapshotting (RDB) et le Fichier Append-Only (AOF). Comprendre les implications de performance, les caractéristiques de durabilité et les compromis de configuration de chacun est crucial pour ajuster Redis afin de répondre aux exigences spécifiques de l'application en matière de vitesse par rapport à la sécurité des données.

Les snapshots RDB sont compacts et rapides à charger. L'AOF enregistre les écritures plus fréquemment et offre généralement de meilleurs points de récupération, mais il coûte plus d'E/S disque.

Comprendre la persistance Redis

Redis stocke l'ensemble de ses données dans une mémoire volatile. Les mécanismes de persistance sont nécessaires pour déplacer ces données sur disque afin que Redis puisse recharger l'ensemble de données lors d'un redémarrage, garantissant ainsi la disponibilité des données en cas d'interruptions de service ou de redémarrages. RDB et AOF atteignent cet objectif par des approches fondamentalement différentes, conduisant à des profils de performance distincts.

1. Snapshotting de la base de données Redis (RDB)

RDB crée un snapshot compact et ponctuel de l'ensemble des données à des intervalles spécifiés. Il sauvegarde ces données dans un fichier binaire (dump.rdb).

Comment fonctionne RDB et son impact sur les performances

La persistance RDB repose fortement sur la commande BGSAVE (Sauvegarde en arrière-plan). Lorsqu'une sauvegarde est déclenchée :

1. Forking : Redis fork le processus principal en un processus enfant.
2. Snapshotting : Le processus enfant écrit l'ensemble des données dans le fichier RDB sur disque.
3. Thread principal non affecté (la plupart du temps) : Le thread principal Redis continue de servir les requêtes des clients sans être bloqué pendant l'opération d'écriture, car l'enfant gère les E/S disque.

Considérations sur les performances :

• Latence d'écriture : Généralement, RDB a un impact minimal sur la latence d'écriture pendant l'opération de sauvegarde car le travail est délégué. Le principal coût de performance est le pic CPU et le pic d'E/S initial requis lors du fork et lors de l'écriture du fichier volumineux.
• Temps de récupération : RDB se charge très rapidement lors du redémarrage car il s'agit d'un fichier unique et optimisé, minimisant ainsi la latence de récupération.
• Compromis de durabilité : Si Redis plante entre les sauvegardes planifiées (par exemple, toutes les 5 minutes), toutes les écritures survenues depuis la dernière sauvegarde sont perdues. Cela rend RDB moins durable que AOF.

Configuration des sauvegardes RDB

Les sauvegardes RDB sont configurées à l'aide de la directive save dans le fichier redis.conf, spécifiant les intervalles de temps et le nombre de modifications :

save 900 1     # Sauvegarder si 1 clé a changé en 900 secondes (15 minutes)
save 300 10    # Sauvegarder si 10 clés ont changé en 300 secondes (5 minutes)
save 60 10000  # Sauvegarder si 10000 clés ont changé en 60 secondes (1 minute)

2. Persistance du fichier Append-Only (AOF)

AOF enregistre chaque opération d'écriture reçue par le serveur Redis dans un fichier journal append-only. Lorsque Redis redémarre, il rejoue ces commandes séquentiellement pour reconstruire l'ensemble des données.

Comment fonctionne AOF et son impact sur les performances

Contrairement à RDB, AOF se concentre sur la journalisation transactionnelle. Le profil de performance dépend fortement de la politique fsync, qui dicte la fréquence à laquelle Redis force le système d'exploitation à écrire les données mises en tampon sur le disque physique.

Politiques Fsync AOF :

Politique	Paramètre appendfsync	Durabilité	Impact sur les performances
Chaque seconde	everysec	Bonne en fonctionnement normal ; un crash peut perdre environ une seconde d'écritures acquittées	Bon équilibre ; choix courant en production.
Aucune synchronisation	no	Mauvaise (dépend du tampon OS)	La plus rapide ; risque maximal de perte de données en cas de crash OS.
Toujours	always	Politique de durabilité AOF la plus forte	La plus lente ; augmentation significative de la latence due à la synchronisation disque sur chaque écriture.

Considérations sur les performances :

• Latence d'écriture : Lors de l'utilisation de appendfsync always, chaque commande d'écriture subit la latence d'une synchronisation disque, ralentissant considérablement les opérations par rapport à RDB ou aux opérations en mémoire. L'utilisation de everysec atténue cela de manière significative en regroupant les fsyncs.
• Temps de récupération : Les fichiers AOF peuvent devenir volumineux et rejouer des millions de commandes peut prendre plus de temps que le chargement d'un fichier RDB compact, entraînant une latence de récupération plus élevée.
• Taille du fichier : Les fichiers AOF sont généralement beaucoup plus volumineux que les fichiers RDB car ils stockent des commandes (par exemple, SET key value) plutôt que l'état final de la structure de données.

Activation et configuration de AOF

AOF est désactivé par défaut et activé en définissant appendonly yes dans redis.conf. Le paramètre crucial est appendfsync :

appendonly yes
appendfilename "appendonly.aof"
# Paramètre recommandé pour le compromis durabilité vs vitesse
appendfsync everysec 

Analyse des compromis de performance : AOF vs. RDB

Choisir entre RDB et AOF nécessite de prioriser soit la vitesse opérationnelle brute (latence), soit la récupération garantie des données.

Latence et débit

• RDB (Meilleur pour la vitesse brute) : Étant donné que les écritures sont gérées par un processus en arrière-plan, le thread principal Redis voit un impact E/S direct minimal pendant les sauvegardes. Cela se traduit généralement par une latence d'écriture globale plus faible, sauf si le système est fortement chargé lorsque le fork BGSAVE se produit.
• AOF (mode always) : Cette configuration est la plus lente car la latence disque est introduite directement dans chaque commande d'écriture client, entraînant des latences p99 plus élevées.
• AOF (mode everysec) : Cela offre des performances presque similaires à RDB pour la plupart des opérations, car les opérations fsync sont mises en tampon et moins fréquentes.

Durabilité et risque de perte de données

• AOF (Meilleur pour la durabilité) : Offre la durabilité la plus élevée, surtout avec appendfsync always. Même avec everysec, la perte de données est limitée à une seconde.
• RDB (Pire pour la durabilité) : La perte de données peut s'étendre sur des minutes ou des heures, selon le calendrier de sauvegarde.

Temps de récupération

• RDB (Récupération rapide) : Temps de redémarrage plus rapides grâce au format binaire compact et optimisé.
• AOF (Récupération plus lente) : Rejouer un journal de commandes volumineux peut prendre plus de temps que le chargement d'un snapshot, augmentant le temps d'arrêt lors des redémarrages.

Bonne pratique : Utiliser les deux méthodes de persistance

Pour les environnements exigeant à la fois des performances élevées et de fortes garanties de durabilité, l'approche recommandée est d'activer simultanément la persistance RDB et AOF.

Lorsque les deux sont activés, Redis utilise le fichier AOF pour la relecture lors du démarrage afin d'atteindre une cohérence maximale des données. Il continue de générer périodiquement des snapshots RDB.

Pourquoi utiliser les deux ?

1. Meilleurs choix de récupération : Redis charge normalement AOF en premier lorsque les deux sont activés car il est généralement plus complet. Conserver RDB vous donne un artefact de repli supplémentaire pour les sauvegardes et la reprise après sinistre.
2. Flexibilité opérationnelle : RDB est compact et facile à archiver, tandis que AOF réduit la fenêtre de perte de données. Ensemble, ils couvrent différents modes de défaillance.

Extrait de configuration pour les deux :

# 1. Activer RDB
save 900 1

# 2. Activer AOF avec synchronisation 'everysec'
appendonly yes
appendfsync everysec

Gestion de la taille du fichier AOF (Réécriture)

Une préoccupation opérationnelle importante avec AOF est la croissance de la taille du fichier. Au fil du temps, le fichier AOF peut devenir massif car il enregistre chaque modification, même celles qui écrasent des valeurs précédentes. Pour contrer cela, Redis offre la réécriture AOF.

La réécriture AOF génère un nouveau fichier AOF optimisé qui contient uniquement l'ensemble minimal de commandes nécessaires pour reconstruire l'état actuel de l'ensemble de données. Ce processus est déclenché automatiquement lorsque la taille du fichier AOF actuel dépasse un certain multiple de la taille de base.

auto-aof-rewrite-percentage 100  # Réécrire lorsque le fichier AOF est 100% plus grand que la taille de base
auto-aof-rewrite-min-size 64mb    # Ne pas réécrire à moins que le fichier ne fasse au moins 64 Mo

Avertissement sur la réécriture : Comme la sauvegarde RDB, la réécriture AOF implique un fork du processus. Si votre système est limité en mémoire, ce doublement temporaire de l'utilisation de la mémoire (l'instance active plus la copie en cours de réécriture) peut entraîner une instabilité ou du swapping.

Conclusion

Utilisez RDB lorsque le redémarrage rapide, les sauvegardes compactes et la faible surcharge d'écriture sont plus importants que la perte d'écritures récentes. Utilisez AOF avec appendfsync everysec lorsque vous avez besoin d'une fenêtre de récupération plus serrée sans synchroniser chaque écriture. Pour de nombreux systèmes de production, activer les deux vous donne un mélange pratique de durabilité, de commodité de sauvegarde et d'options de récupération.