Redis AOF - Des cas où il est judicieux de désactiver pour la performance

Redis est un puissant système de stockage de données en mémoire. Sa rapidité est essentielle, mais en raison de sa nature "en mémoire", il y a un risque que toutes les données disparaissent lorsque le serveur redémarre. Pour éviter cela, Redis propose deux options de persistance.

1. RDB (Snapshotting) : Prend un instantané complet des données à un moment donné et l'enregistre sur le disque.

2. AOF (Append Only File) : Enregistre chaque commande d'écriture dans un fichier journal de manière séquentielle.

L'AOF garantit une durabilité presque sans risque de perte de données (généralement moins d'une seconde) par rapport à RDB. Cependant, enregistrer chaque opération d'écriture dans un fichier engendre clairement un coût de performance.

"Est-il vraiment nécessaire d'utiliser l'AOF pour tous les cas d'utilisation de Redis ?"

Pour répondre brièvement, "Non, pas du tout."

Aujourd'hui, nous allons clairement distinguer les cas où l'utilisation de l'AOF n'est pas nécessaire, et les cas où l'AOF est indispensable.

Cas où l'AOF n'est pas nécessaire

La valeur clé de l'AOF réside dans la durabilité des données. Si cette durabilité n'est pas importante pour les données, alors l'AOF peut devenir une 'entrave' qui entraîne une baisse de performance inutile.

1. Lorsqu'il est utilisé uniquement comme cache

C'est le cas le plus représentatif.

• Raison : Les données du cache ne sont pas 'originales'. Une base de données (DB) ou d'autres API existent en tant que 'source de vérité'.

• En cas de perte de données : Même si Redis redémarre et que le cache est complètement vidé, l'application sera simplement ralentie pendant un moment (Cache Miss) et pourra remplir le cache à partir des données originales (Cache-Warm up). Les données ne sont pas perdues de façon permanente.

• Conclusion : Pour un usage de cache, il arrive souvent que même RDB soit désactivé, sans parler de l'AOF. Supprimer complètement les E/S disque maximise la vitesse pure en mémoire de Redis.

2. Broker Celery / backend de résultats (tâches peu critiques)

Redis est souvent utilisé avec Celery. Dans la configuration AOF de Redis comme broker et backend de résultats de Celery, l'importance des tâches est un facteur clé.

• Raison : Si les tâches traitées par Celery sont 'sans conséquence' ou 'facilement réessayables', alors l'AOF est inutile.

• Exemples :

  • Analyse de journaux d'utilisateur (perdre quelques secondes de journaux n'est pas un gros problème)

  • Nettoyage périodique des données (peut être exécuté à la prochaine période)

  • Création d'images miniatures (puisque l'image originale existe, elle peut être recréée)

• Conclusion : Dans ce scénario, si le serveur Redis plante, les tâches ou les résultats dans la file d'attente peuvent disparaître. Mais si cette perte peut être 'acceptée' commercialement, il est sage de désactiver l'AOF pour garantir la performance du broker.

3. Statistiques simples et données en temps réel (volatile)

Lorsque vous examinez des tendances à court terme ou des données qui se mettent à jour rapidement.

• Raison : Les données se mettent à jour à des intervalles très courts, ou un instantané à un moment précis n'a pas beaucoup de signification.

• Exemples :

  • Nombre de visiteurs sur le site au cours de la dernière minute

  • Classement de jeu en temps réel (changement à la seconde)

  • Données de session temporaires (expirent en quelques minutes)

• Conclusion : Puisque ces données disparaîtront ou seront mises à jour de toute façon, il est beaucoup plus important de traiter rapidement un grand nombre de requêtes d'écriture que de perdre quelques secondes de données. L'AOF n'est pas adapté à ce type d'environnement.

Cas où l'utilisation de l'AOF est fortement recommandée

En revanche, lorsque la perte de données de Redis entraîne des problèmes graves, l'AOF devient un besoin plutôt qu'un choix.

1. File de messages 'fiable' (Critical Celery Jobs)

Ce cas est à l'opposé de l'exemple de Celery ci-dessus.

• Raison : Les tâches elles-mêmes sont liées à de l'argent ou à des logiques commerciales essentielles.

• Exemples :

  • Traitement des paiements

  • Confirmation d'inscription et envoi d'e-mail de vérification

  • Traitement des commandes

• Conclusion : Si l'utilisateur appuie sur le bouton 'payer' et que Redis redémarre, entraînant la perte de la demande, c'est un problème sérieux. Dans ce scénario, il est impératif d'activer l'AOF avec l'option fsync everysec (valeur par défaut) pour garantir que les demandes soient enregistrées sur le disque dès qu'elles entrent dans la file.

2. Lorsqu'il utilise Redis comme base de données principale

Lorsque Redis est utilisé non pas simplement comme cache, mais comme source de vérité.

• Raison : Comme il n'y a pas d'autre base de données, et que Redis lui-même stocke les données originales, la perte de données signifie une perte permanente.

• Exemples :

  • Informations de profil utilisateur

  • Sessions utilisateurs devant être conservées de manière permanente

  • Informations sur les ressources du jeu (or, objets)

• Conclusion : Dans ce cas, l'AOF est essentiel et doit être utilisé avec des instantanés RDB pour établir une stratégie de sauvegarde et de récupération.

3. Données de transaction et d'agrégation

Lorsque la cohérence et l'exactitude des données sont extrêmement importantes.

• Raison : Le RDB stocke un 'instantané à un moment donné', donc toutes les données après le dernier instantané sont perdues. L'AOF stocke 'toute l'historique des modifications', réduisant ainsi la perte de données au minimum (maximum 1 seconde).

• Exemples :

  • Relations de suivi/désabonnement

  • Comptage précis des votes

  • Données financières (rapports simples de crédits et débits)

• Conclusion : Dans les cas où la cohérence finale des données est cruciale, la nature 'Append-Only' de l'AOF est beaucoup plus appropriée que le RDB.

Conclusion : Compromis entre durabilité et performance

L'AOF est une fonctionnalité puissante qui confère à Redis durabilité. Cependant, cette fonctionnalité a un coût en termes de performance.

Si vous hésitez à activer l'AOF, les développeurs devraient réfléchir aux questions suivantes :

"Si le serveur Redis tombait en panne sans avertissement maintenant, la perte de données de quelques minutes (RDB) ou d'une seconde (AOF) causerait-elle un problème grave pour notre service ?"

• "Non, nous pouvons recalculer (cache)." -> Désactivez l'AOF.

• "Oui, l'historique des paiements serait perdu." -> Activez absolument l'AOF.

Comme pour toute décision technique, il n'y a pas de réponseunique. Il est crucial de bien comprendre les caractéristiques et exigences des données de votre service et de faire un compromis approprié.