Options de Persistance Redis : RDB vs AOF Expliqué

Redis est réputé pour sa rapidité en tant que magasin de structures de données en mémoire, souvent utilisé comme cache ou broker de messages. Cependant, bien que les données résident principalement dans la RAM pour la vitesse, les déploiements en production nécessitent des mécanismes pour garantir que les données survivent aux redémarrages ou aux pannes. C'est là que la persistance entre en jeu. Redis offre deux mécanismes de persistance intégrés principaux : Redis Database Backup (RDB) et Append-Only File (AOF). Comprendre les compromis entre ces deux éléments est crucial pour configurer Redis de manière appropriée pour les besoins de durabilité et de performance de votre application.

Ce guide expliquera en détail le fonctionnement de RDB et AOF, comparera leurs avantages et inconvénients, et fournira des conseils sur quand utiliser chaque stratégie.

Comprendre la Persistance Redis

La persistance dans Redis fait référence au processus d'écriture de l'état actuel de l'ensemble de données en mémoire sur le disque. Cela permet à Redis de recharger les données lorsque le serveur redémarre. Sans persistance activée, toutes les données sont perdues à l'arrêt.

Redis prend en charge RDB et AOF simultanément, offrant une approche hybride qui combine les meilleures caractéristiques des deux.

1. Redis Database Backup (RDB)

RDB (Redis Database Backup) est le mécanisme de persistance par défaut de Redis. Il effectue des instantanés périodiques de votre ensemble de données complet à intervalles spécifiés.

Comment fonctionne RDB

RDB fonctionne en forquant le processus Redis principal, créant un processus enfant qui écrit le contenu actuel de la mémoire dans un fichier binaire compressé nommé dump.rdb sur le disque. Comme il s'agit d'un instantané, il capture les données à un moment précis.

Configuration et Instantanés

La configuration RDB est gérée via les directives save dans le fichier redis.conf. Ces directives définissent les conditions dans lesquelles une sauvegarde automatique se produit :

# Sauvegarder la DB si 1000 clés ont changé en 1 minute
save 600 1000
# Sauvegarder la DB si 10 clés ont changé en 10 minutes
save 300 10
# Sauvegarder la DB si 10000 clés ont changé en 1 seconde
save 1 10000

Pour désactiver complètement la persistance RDB, vous pouvez commenter toutes les directives save ou utiliser la commande SAVE uniquement manuellement.

Avantages de RDB

Fichiers Compacts : Les fichiers RDB sont hautement optimisés, compressés et compacts, ce qui les rend idéaux pour les sauvegardes et les transferts rapides.
Récupération Rapide : Comme il s'agit d'un seul fichier d'instantané, le chargement des données au redémarrage est très rapide.
Performances : Les sauvegardes s'effectuent de manière asynchrone en forçant le processus, ce qui signifie que le thread principal n'est pas bloqué pendant l'opération d'écriture (bien que le fork lui-même puisse provoquer de brèves augmentations de latence).

Inconvénients de RDB

Risque de Perte de Données : Si Redis plante entre les points de sauvegarde planifiés, toutes les écritures qui se sont produites après le dernier instantané seront perdues.
Coût du Fork : Sur de très grands ensembles de données, l'opération de fork nécessaire pour créer l'instantané peut consommer des ressources système importantes et provoquer une brève latence.

2. Append-Only File (AOF)

AOF (Append-Only File) offre un niveau de durabilité des données plus élevé. Au lieu d'instantanés, AOF enregistre chaque opération d'écriture reçue par le serveur dans un format append-only.

Comment fonctionne AOF

Lorsque la persistance est activée, Redis redirige chaque commande d'écriture (par exemple, SET, LPUSH) vers un fichier AOF sur disque. Lorsque Redis redémarre, il rejoue ces commandes séquentiellement pour reconstruire l'ensemble de données exactement comme il était avant l'arrêt.

Configuration AOF

La persistance AOF est désactivée par défaut et doit être explicitement activée dans redis.conf :

appendonly yes

Crucialement, AOF permet la configuration de la politique fsync, déterminant la fréquence à laquelle les écritures sont forcées sur le disque :

Politique fsync	Description	Durabilité vs. Performance
`no`	L'OS gère la synchronisation (la moins fréquente).	Le plus rapide, risque de perte le plus élevé.
`everysec`	Synchroniser une fois par seconde (par défaut et recommandé).	Bon équilibre. Au plus, 1 seconde de données est perdue.
`always`	Synchroniser après chaque commande.	Durabilité la plus élevée, impact potentiel significatif sur les performances.

Avantages de AOF

Haute Durabilité : En réglant fsync sur always, vous pouvez obtenir une perte de données quasi nulle.
Rejeu des Logs : Le fichier AOF contient un journal chronologique des opérations, ce qui facilite le débogage d'éventuelles corruptions de données.

Inconvénients de AOF

Fichiers Plus Grands : Les fichiers AOF sont généralement beaucoup plus grands que les fichiers RDB correspondants car ils stockent les commandes plutôt que l'état final des données.
Redémarrage Plus Lent : Le rejeu de potentiellement des milliers de commandes au démarrage prend plus de temps que le chargement d'un seul instantané RDB.
Amplification d'Écriture : Les commandes sont enregistrées individuellement, ce qui peut entraîner une surcharge d'écriture légèrement plus élevée par rapport à la prise d'instantanés RDB.

Réécriture AOF

Pour lutter contre la croissance de la taille des fichiers, Redis implémente la réécriture AOF. Ce processus crée de manière asynchrone un nouveau fichier AOF optimisé contenant uniquement les commandes nécessaires pour atteindre l'état actuel, rejetant efficacement les commandes redondantes ou obsolètes (comme plusieurs mises à jour de la même clé).

RDB vs AOF : Comparaison Directe

Le choix entre RDB, AOF, ou les deux dépend entièrement des exigences de votre application en matière de temps de récupération et de tolérance à la perte de données.

Caractéristique	RDB (Instantané)	AOF (Fichier Append-Only)
Durabilité/Perte de Données	Perte de données potentielle plus élevée (depuis la dernière sauvegarde).	Perte de données minimale (jusqu'à 1 seconde, ou zéro avec `fsync=always`).
Taille du Fichier	Très compact et optimisé.	Plus grand en raison de l'enregistrement des commandes.
Temps de Redémarrage	Chargement très rapide de l'instantané.	Plus lent, nécessite le rejeu des commandes.
Complexité	Simple, configuré par intervalles de temps.	Nécessite une configuration minutieuse de la politique `fsync`.
Cas d'Utilisation	Sauvegardes, reprise après sinistre où la perte de données récentes est tolérable.	Mécanisme de persistance principal nécessitant une haute durabilité.

Meilleure Pratique : Combiner RDB et AOF

Pour la plupart des déploiements de production modernes, l'approche recommandée est d' activer simultanément la persistance RDB et AOF.

Lorsque les deux sont activés :
1. AOF fournit le journal principal de haute durabilité.
2. RDB fournit une sauvegarde d'instantané rapide et compacte.

Au redémarrage, Redis préférera charger le fichier AOF pour une durabilité complète. Si le fichier AOF est manquant ou corrompu, il se rabattra sur le chargement du fichier RDB. De plus, le processus de réécriture AOF utilise souvent le fichier RDB comme point de départ efficace, fusionnant les avantages des deux méthodes.

Comment activer les deux

Assurez-vous que les deux configurations sont définies dans redis.conf :

# Activer AOF
appendonly yes

# Conserver la configuration RDB (par exemple, sauvegarde automatique toutes les heures)
save 3600 1

# Politique fsync recommandée pour AOF
appendfsync everysec

Astuce sur la réécriture AOF : Vous pouvez déclencher manuellement une réécriture AOF à tout moment en utilisant la commande BGREWRITEAOF. Ceci est particulièrement utile après de grosses charges de données en bloc ou des opérations de purge importantes pour réduire immédiatement la taille du fichier AOF.