Redis ou Memcached : choisir le bon cache en mémoire
Les applications web modernes utilisent souvent une base de données en mémoire pour réduire la latence, absorber les pics de trafic et éviter de solliciter constamment PostgreSQL, MySQL ou MongoDB. Redis et Memcached sont les deux solutions les plus connues dans cette catégorie, mais elles ne répondent pas exactement aux mêmes besoins.
Leur point commun est simple : conserver temporairement des données en RAM afin de les retrouver rapidement. Leur philosophie diffère ensuite fortement. Redis propose un véritable moteur de structures de données, tandis que Memcached reste centré sur un modèle clé-valeur volontairement minimaliste.
Le choix dépend donc de la nature des données, du niveau de tolérance à la perte du cache, de la topologie de déploiement et des fonctionnalités attendues par l’application. Les ressources pratiques de Développeur Web permettent également de replacer ce choix dans une architecture complète, avec l’API, le stockage principal et l’infrastructure cloud.
Le rôle d’une base de données en mémoire
Un cache en mémoire stocke une copie temporaire d’une information déjà disponible ailleurs : résultat d’une requête SQL, réponse d’une API, session utilisateur, jeton d’authentification ou contenu calculé. Lorsqu’une requête identique arrive, l’application lit cette copie au lieu de refaire le traitement complet.
Cette approche diminue le temps de réponse et la charge sur les services persistants. Elle exige cependant une stratégie cohérente d’expiration et d’invalidation. Une donnée conservée trop longtemps peut devenir obsolète, tandis qu’une durée de vie trop courte réduit fortement le taux de réussite du cache.
Redis comme Memcached fonctionnent principalement avec des données volatiles. Ils ne doivent pas être considérés automatiquement comme le remplacement d’une base relationnelle ou documentaire. Le stockage permanent, la cohérence métier et la récupération après sinistre doivent rester assurés par un système adapté.
Redis mise sur la richesse fonctionnelle
Redis accepte les chaînes de caractères, listes, ensembles, ensembles triés, tables de hachage, flux et bitmaps. Ces structures permettent de modéliser directement des files d’attente, des classements, des compteurs, des paniers ou des sessions complexes sans sérialiser systématiquement toutes les données dans une simple chaîne.
Le serveur propose aussi des opérations atomiques, des transactions, des scripts Lua, des notifications Pub/Sub et des mécanismes de verrouillage distribués. Les flux Redis sont particulièrement utiles pour construire des pipelines d’événements légers, même si un besoin de journalisation durable et de relecture avancée peut justifier Kafka ou un autre broker spécialisé.
Redis dispose de fonctionnalités de persistance avec RDB et AOF, de réplication, de Sentinel et de Redis Cluster. Ces options augmentent les possibilités de haute disponibilité, mais aussi la complexité opérationnelle. La configuration du modèle de données, de la mémoire et de la réplication doit être surveillée avec précision.
Memcached privilégie la simplicité
Memcached fournit un dictionnaire distribué de paires clé-valeur. Une application écrit une valeur sous une clé, définit éventuellement une expiration, puis la récupère lors d’un accès ultérieur. Cette simplicité facilite l’intégration et limite la surface fonctionnelle à administrer.
Le serveur est conçu pour le cache éphémère. Il ne propose pas de persistance native, de réplication intégrée ou de structures de données comparables à celles de Redis. Si un nœud disparaît, les entrées qu’il contenait sont perdues et doivent être recalculées depuis la source principale.
Son architecture multithread peut être efficace pour un grand nombre de requêtes indépendantes. L’allocation par classes de taille et les politiques d’éviction, généralement fondées sur la logique LRU, permettent d’exploiter la mémoire disponible avec une implémentation relativement directe. Memcached convient ainsi très bien à un cache de fragments HTML, de résultats SQL ou de réponses d’API.
Les différences essentielles en pratique
Le choix ne repose pas uniquement sur le débit maximal annoncé. Il faut examiner les garanties de récupération, le comportement lorsque la mémoire est saturée, le modèle de cohérence et les capacités de supervision. Une fonctionnalité supplémentaire n’a de valeur que si elle répond réellement au fonctionnement de l’application.
| Critère | Redis | Memcached |
|---|---|---|
| Modèle de données | Clés, chaînes, listes, ensembles, hachages, flux | Clés et valeurs simples |
| Persistance | RDB et AOF disponibles | Aucune persistance native |
| Réplication | Réplication et options de haute disponibilité | Généralement gérée par l’application ou la plateforme |
| Expiration | TTL, suppression volontaire, politiques d’éviction | TTL et éviction selon la mémoire disponible |
| Opérations atomiques | Nombreuses commandes et scripts Lua | Opérations simples, avec CAS |
| Distribution | Redis Cluster, Sentinel et services managés | Partitionnement côté client ou service managé |
| Cas d’usage | Cache, sessions, files, compteurs, événements | Cache de réponses et d’objets temporaires |
| Complexité | Plus riche, donc plus exigeante | Faible pour un cache classique |
Redis s’impose lorsqu’il faut manipuler les données directement dans le cache. Un classement de joueurs, un compteur atomique ou une file de tâches bénéficient de commandes spécialisées. Memcached reste pertinent lorsqu’une valeur complète est simplement stockée puis relue, sans traitement intermédiaire.
Adapter le choix à la charge applicative
Pour un site de contenu, un catalogue ou une API dont les requêtes répétitives produisent des objets sérialisés, Memcached peut offrir un excellent rapport entre simplicité et performance. Il réduit le nombre de dépendances conceptuelles et rend le comportement du cache facile à expliquer à toute l’équipe.
Redis devient plus intéressant lorsque les sessions doivent être partagées entre plusieurs instances, lorsque les compteurs doivent être atomiques ou lorsque l’application utilise des files de travail et des événements temps réel. Il peut aussi servir de cache de second niveau devant une base SQL, à condition de définir clairement la source de vérité.
Les coûts doivent être évalués sur la durée : consommation de RAM, réplication, sauvegardes, surveillance, mises à jour et compétences nécessaires. Un cluster Redis richement configuré peut être disproportionné pour une simple mise en cache de pages. À l’inverse, détourner Memcached pour simuler une file ou une base persistante crée une dette technique difficile à maîtriser.
Sécuriser et exploiter le cache
Un service en mémoire ne doit pas être exposé directement à Internet. Le réseau doit limiter les accès aux serveurs applicatifs, avec des règles de pare-feu, des sous-réseaux privés et, lorsque c’est disponible, le chiffrement des connexions. Les identifiants, les données personnelles et les jetons sensibles nécessitent une politique de durée de vie et de protection adaptée.
La supervision doit suivre le taux de succès du cache, la latence, la consommation mémoire, les évictions, les erreurs de connexion et le volume de commandes. Un taux de réussite élevé n’est pas forcément positif si les données sont trop anciennes ; la fraîcheur et l’impact métier doivent aussi être observés.
Avant de retenir une solution, vérifiez les éléments suivants :
- la donnée peut-elle être reconstruite après une panne du cache ;
- le modèle clé-valeur suffit-il aux traitements prévus ;
- quelles sont les durées d’expiration et les règles d’invalidation ;
- la solution managée choisie fournit-elle sauvegarde, chiffrement et haute disponibilité ;
- quels indicateurs permettront de mesurer son bénéfice réel.
Tester avant de généraliser
Un benchmark réaliste doit reproduire la taille des valeurs, le taux de lecture et d’écriture, la concurrence, les expirations et les scénarios de panne. Un test limité à de petites chaînes en mémoire ne reflète pas nécessairement le comportement d’une application qui stocke de gros objets JSON ou des sessions volumineuses.
Il est également utile de mesurer l’application complète plutôt que le seul serveur de cache. Une baisse de quelques microsecondes côté Redis ou Memcached ne compensera pas une sérialisation inefficace, une mauvaise stratégie de clés ou un accès réseau mal placé.
Commencez par un cas d’usage isolé, documentez la politique d’expiration et conservez une solution de repli vers la source principale. Déployez ensuite avec des métriques et des alertes adaptées. Analysez les résultats, puis choisissez Redis pour ses structures et sa résilience ou Memcached pour son cache simple, rapide et facile à maintenir.