Vous avez besoin d'un cache côté serveur, vous avez lu deux comparatifs et les deux vous ont répondu que « cela dépend ». Très utile. Tranchons donc la question Redis vs Memcached d'emblée : Memcached est la solution idéale si vous recherchez un cache simple et rapide, sans fioritures. Redis est préférable si votre cache doit stocker des données structurées, survivre à un redémarrage ou décharger votre application de certaines tâches.
Redis et Memcached sont tous deux :
La plupart des articles s'arrêtent à cette liste commune. Celui-ci va plus loin, car c'est après que les différences intéressantes commencent.
Tous deux stockent les données en mémoire pour accélérer les applications, mais ils répondent à des besoins différents.
Memcached est simple. Il propose un stockage clé-valeur basique et excelle dans la mise en cache rapide des données grâce à ses performances multithread.
Redis prend en charge des types de données plus complexes et le stockage permanent, ce qui le rend polyvalent pour un éventail de tâches plus large, comme la messagerie et la gestion de sessions. Il offre également des options avancées telles que le partitionnement des données (sharding), qui consiste à répartir un jeu de données sur plusieurs serveurs afin qu'aucune machine ne le contienne en totalité, ainsi qu'un choix de politiques d'éviction.
En m'appuyant sur un projet développé pour un client, je vais aborder la manière dont ils gèrent le stockage des données et l'évolutivité, et déterminer lequel est le plus performant selon les scénarios. Commençons par les bases.
Redis, qui signifie Remote Dictionary Server, a été créé en 2009 par Salvatore Sanfilippo afin d'améliorer l'évolutivité de l'analyseur de logs web que sa startup italienne développait. Le premier prototype a été écrit en Tcl, puis transcrit en C. Lorsque Sanfilippo a rendu le projet open source, celui-ci a commencé à gagner en popularité. GitHub et Instagram ont été parmi les premières entreprises à l'adopter, et la documentation officielle du projet reste aujourd'hui la référence en matière de fonctionnement et de limites.
Memcached est apparu un peu plus tôt, en 2003, créé par Brad Fitzpatrick pour son site web LiveJournal. Initialement développé en Perl, il a ensuite été traduit en C. Certaines des plus grandes entreprises au monde l'utilisent, notamment Facebook, YouTube et Twitter, et son fonctionnement est documenté sur le wiki de Memcached.
Redis n'est pas vraiment un magasin clé-valeur ; c'est un serveur de structures de données. Voici les cinq que vous utiliserez le plus :
Au-delà de ces types, il propose également des bitmaps, des champs de bits, des HyperLogLogs (compteurs de cardinalité probabilistes) et des index géospatiaux, ainsi que des flux pour les journaux en ajout seul. Le JSON, le requêtage, les séries temporelles et — depuis Redis 8 — les ensembles vectoriels sont accessibles via des modules (documentation sur les types de données Redis). On est bien loin des simples « clés et chaînes », et c'est précisément cette richesse qui permet à Redis de se rendre indispensable là où un cache classique ne suffit pas.
Redis prend en charge les opérations sur les types de données, ce qui signifie que vous pouvez lire ou modifier une partie d'un objet sans avoir à charger l'intégralité de celui-ci dans votre application, le modifier, puis le réenregistrer.
Pour la gestion de la mémoire, il utilise une version encapsulée de malloc/free, le mécanisme standard en C pour allouer et libérer de la mémoire. C'est plus simple que le mécanisme de dalles (Slab) de Memcached, que j'aborderai ci-dessous.
Les clés peuvent atteindre 512 Mo, tout comme les valeurs, comme indiqué dans sa documentation sur les types de donnéesPour les types de données agrégées comme les Listes et les Ensembles, cette limite s'applique par élément.
Memcached ne possède pas de types de données. Il stocke des chaînes indexées par une clé textuelle, ce qui lui permet de consommer moins de mémoire vive que Redis.
Il est également limité par la mémoire de la machine sur laquelle il est installé. Lorsqu'elle est saturée, il commence à supprimer les valeurs selon l'ordre de la moins récemment utilisée (LRU). Son mécanisme d'allocation, Slab, segmente la mémoire en blocs de tailles différentes et stocke chaque enregistrement clé-valeur dans le bloc approprié. C'est ce qui évite la fragmentation de la mémoire en espaces trop petits pour être réutilisés.
Les clés sont limitées à 250 octets et les valeurs à 1 Mo. Il s'agit toutefois de valeurs par défaut, et vous pouvez augmenter la taille maximale des blocs au démarrage (voir le wiki de Memcached).
Imaginez un objet mis en cache comme un manteau déposé au vestiaire. Avec Memcached, vous ne pouvez récupérer que le manteau entier : pour modifier le contenu d'une poche, la chaîne doit être chargée, désérialisée, le champ modifié, puis resérialisée et stockée à nouveau.
Redis vous permet d'accéder directement à la poche. Le type de données « hash » vous donne accès à chaque champ individuellement, de sorte que toute opération CRUD (création, lecture, mise à jour, suppression) s'effectue uniquement sur ce champ. Un seul aller-retour réseau, au coût approximatif d'un simple « get » ou « set », remplace quatre échanges et deux étapes de sérialisation.
Voici la même mise à jour de session effectuée des deux manières :
# Memcached — the whole session object is the unit of work
value = mc.get("session:42") # 1. fetch the whole blob
session = deserialise(value) # 2. deserialise in app memory
session["last_seen"] = now() # 3. edit one field
mc.set("session:42", serialise(session)) # 4. serialise + write it all back
# → 2 network round trips, 2 (de)serialisation steps, in your app code
# Redis — the field is the unit of work
HSET session:42 last_seen <now> # one round trip, no (de)serialisation
# → the read-modify-write collapses into a single command on the serverLa raison pour laquelle cela fonctionne n'est pas propre à notre projet. La documentation de Redis ainsi que des benchmarks indépendants montrent que la réduction des allers-retours réseau, plutôt que l'accélération des commandes, est ce qui améliore le débit — voir la section sur les performances ci-dessous pour les chiffres.
Redis est principalement monothread, ce qui signifie qu'un seul cœur exécute les commandes, quel que soit le nombre de cœurs dont dispose la machine. (Le multithreading des entrées/sorties est apparu avec Redis 6, et Redis 8 ainsi que le fork Valkey ont poussé cette approche plus loin, mais les commandes elles-mêmes continuent de s'exécuter sur un seul thread ; AWS souligne cette même distinction entre exécution monothread et entrées/sorties multithreadées dans son Comparaison des moteurs ElastiCache.) Grâce à sa prise en charge native du clustering, il privilégie une montée en charge horizontale.
Le clustering repose sur une architecture maître/esclave, où un nœud accepte les écritures tandis que les autres conservent des copies de ses données. Chaque maître dispose de deux esclaves pour la redondance ; ainsi, en cas de défaillance du maître, le système en promeut automatiquement un autre. Le coût réside dans la maintenance : il est plus complexe de maintenir la santé de plusieurs nœuds fonctionnant de manière synchrone que celle d'un seul.
Memcached assure facilement sa mise à l'échelle verticale, car il est multithread. Il suffit de lui allouer davantage de cœurs et de mémoire, et le tour est joué.
Il assure également sa mise à l'échelle horizontale, côté client, via un algorithme distribué que vous implémentez. Cela demande plus de travail qu'avec Redis, qui propose le clustering en standard.
La différence majeure entre les deux réside dans ce qui survit à un redémarrage. Redis est un magasin de données (principalement) en mémoire qui n'est pas volatil. Memcached est un cache en mémoire qui est volatil : redémarrez le processus et le contenu disparaît.
Redis prend en charge la persistance, ce qui explique pourquoi on le qualifie de magasin de données, de deux manières (Documentation sur la persistance Redis) :
Un processus enfant gère ces fichiers, et ce détail détermine celui que vous choisirez.
Un jeu de données volumineux pose-t-il problème ? Pour le RDB, oui. La création du fichier prend du temps, ce qui impacte les temps de réponse, bien qu'il se charge plus rapidement au démarrage que le journal AOF.
Choisissez l'AOF si la perte de données est totalement inacceptable. Il peut être mis à jour à chaque commande et, étant en ajout seul, il ne présente aucun risque de corruption. Il devient cependant beaucoup plus volumineux qu'un instantané RDB.
Rien, par conception. Pas d'instantané, pas de journal. Un redémarrage, un plantage ou un basculement repartent d'un cache vide, et la première vague de requêtes qui suit atteint directement la base de données.
C'est acceptable lorsque le cache contient des données dérivées faciles à recalculer. Cela devient un problème de planification de capacité dans le cas contraire.
Memcached est limité à la politique d'éviction LRU (least recently used - moins récemment utilisé), tandis que Redis en prend en charge huit (Documentation sur l'éviction des clés Redis) :
Ce que cela vous apporte, c'est le contrôle. Avec Memcached, le mécanisme LRU décide et vous devez faire avec. Avec Redis, vous pouvez protéger les clés qui ne doivent pas disparaître et laisser tout le reste être évincé autour d'elles.
C'est généralement ici que les pages de comparaison remplacent les preuves par des affirmations. Utilisons plutôt des chiffres.
Redis publie ses propres chiffres de débit. Sa documentation de benchmark indique qu'un serveur Linux d'entrée de gamme exécutant une instance Redis unique traite environ 100 000 requêtes par seconde avec de petites charges utiles, avec une latence inférieure à la milliseconde sur un réseau local. Ce plafond concerne un seul cœur. L'exécution des commandes étant monothread, l'ajout de cœurs à la machine ne permet pas de l'augmenter. Redis 6 a ajouté des E/S multithread, qui parallélisent les lectures et écritures sur socket, mais les commandes elles-mêmes s'exécutent toujours sur un seul thread.
Memcached est multithread de bout en bout, son débit augmente donc avec le nombre de cœurs jusqu'à saturation de l'interface réseau. C'est là tout son avantage en termes de performances, et il est réel : sur une machine multicœur servant des valeurs simples et volumineuses, Memcached transfère plus de données par seconde qu'un processus Redis unique. C'est pourquoi AWS documente les deux différemment, même au sein du même service géré : son propre livre blanc note que Memcached « tire parti des tailles d'instances plus grandes avec plusieurs cœurs », tandis que Redis est géré davantage comme une base de données avec état (Memcached vs. Redis : Performances à grande échelle avec Amazon ElastiCache).
Deux nuances comptent plus que les chiffres annoncés. Premièrement, un déploiement Redis est rarement constitué d'un seul processus, et le partitionnement (sharding) entre instances permet de retrouver l'avantage du multicœur au prix d'une maintenance de cluster. Deuxièmement, le nombre d'opérations par seconde est un mauvais indicateur lorsqu'une seule commande Redis remplace plusieurs allers-retours applicatifs. Une mise à jour de champ de hash est un échange réseau unique, là où Memcached nécessite une lecture, une désérialisation, une écriture et une sérialisation. Redis peut être plus lent par opération et pourtant terminer en premier.
Ce n'est pas seulement le fruit de notre expérience ; le mécanisme est documenté et mesurable. Comme chaque commande représente un aller-retour réseau, c'est le temps d'aller-retour — et non l'exécution de la commande — qui limite généralement le débit. Le guide de pipelining de Redis souligne ce point avec force : sur une liaison avec un temps d'aller-retour de 250 ms, un serveur capable de 100 000 requêtes par seconde est limité à environ quatre par seconde tant que vous payez un aller-retour par commande. Des benchmarks indépendants montrent l'ampleur du gain : dans un test largement cité réalisé sur l'infrastructure de DigitalOcean, la réduction des allers-retours a fait passer un redis-benchmark standard d'environ 97 000 GET/s à environ 1,35 million de GET/s — un gain d'environ 14x obtenu entièrement en supprimant les échanges réseau, et non en accélérant les commandes. C'est le même levier que notre changement d'objet de session a actionné, sous une forme différente : une commande de hash à la place d'une lecture, une désérialisation, une modification, une sérialisation et une écriture. (Le pipelining traite plusieurs commandes par lots ; le type hash réduit une opération lecture-modification-écriture — des techniques différentes, mais un principe identique : moins de trajets sur le réseau.)
La règle est donc la suivante : Memcached pour un volume élevé de lectures indépendantes de valeurs complètes sur une grosse machine. Redis lorsque la structure des données vous permet d'effectuer moins d'opérations, mais plus intelligentes.
Trois situations justifient le coût opérationnel, et elles ont un point commun : le cache effectue une tâche que vos serveurs d'application devraient sinon réaliser.
Memcached est adapté lorsque le cache est réellement un cache : des valeurs écrites en bloc, lues en bloc, et dont la perte est sans conséquence.
Voici un aspect rarement abordé sur les pages de comparaison. Nous l'appelons le test du coût de sortie : avant de choisir une solution de cache, demandez-vous ce qu'il en coûterait de la quitter. Les deux réponses ne sont pas symétriques.
Chez Imaginary Cloud, nous avons utilisé les deux solutions sur de nombreux projets clients. Pour l'un d'entre eux, nous avons dû choisir entre les deux. Nous avons commencé avec Memcached pour sa simplicité, sa facilité d'utilisation et sa configuration rapide, car nous avions simplement besoin d'un cache et la persistance n'était pas une exigence. Après quelques tests, nous sommes passés à Redis pour bénéficier de ses types de données.
Les opérations sur les types de données correspondaient parfaitement au type d'informations que nous stockions. Redis propose également une commande pour rechercher des clés correspondant à un modèle, ainsi que de nombreuses autres commandes pour manipuler les clés, ce qui s'est avéré être la fonctionnalité que nous utilisions le plus. Ce fut l'élément décisif de notre migration.
La migration en elle-même a été simple, car Redis prend en charge la plupart des commandes de Memcached. Il suffit de rediriger le client, de laisser le cache se remplir et de continuer.
Faire le chemin inverse est une autre paire de manches. Memcached ne gère pas les types de données ; chaque commande spécifique aux types de données de Redis doit donc être traduite en plusieurs commandes Memcached, avec un traitement des données intermédiaire pour obtenir le même résultat. Cette logique se retrouve alors dans le code applicatif dont vous l'aviez pourtant extraite.
Cette asymétrie constitue le test. Commencez avec Memcached et vous conservez une porte de sortie peu coûteuse vers Redis. Commencez avec Redis, découvrez que vous n'aviez besoin que d'un cache simple, et vous devrez réécrire la logique de votre application pour revenir en arrière. Lorsque les besoins sont réellement incertains, le coût de sortie mérite plus d'attention que n'importe quel benchmark.
Redis est plus flexible et plus performant. Memcached reste très utile pour certains usages et s'avère parfois plus efficace, car le multithreading est un atout majeur lorsqu'il s'agit de traiter d'importants volumes de données simples.
Redis prend en charge les opérations sur les données grâce à ses types de données, ce qui permet de réduire à la fois le nombre d'entrées/sorties réseau et la taille des données traitées. La mise à jour d'un champ de hash a un coût équivalent à une opération get ou set classique ; votre application gagne donc en efficacité sans temps de latence supplémentaire sur le réseau.
Alors, y a-t-il un vainqueur ? Bien sûr que non. Appliquez la règle de performance, puis le test du coût de sortie. Choisissez Memcached pour un volume élevé de lectures indépendantes de valeurs complètes sur une machine puissante. Optez pour Redis lorsque la structure de vos données permet d'effectuer des opérations moins nombreuses et plus intelligentes. Si les deux solutions se valent, choisissez celle dont il est le plus facile de se détacher. D'après notre expérience, peser ces avantages et inconvénients dès le départ vous évitera une migration en plein milieu du projet.
Si vous validez l'architecture plutôt que de la concevoir, la comparaison technique se résume à trois questions commerciales. Nous les appliquons à chaque choix d'infrastructure et de pile technologique, et pas seulement au cache.
1. Quel est le coût d'exploitation ? Memcached génère une surcharge mémoire plus faible par élément, permettant ainsi de faire tenir le même jeu de données dans une instance plus petite. Redis coûte plus cher par gigaoctet mis en cache dès lors que la persistance et la réplication sont activées, car un instantané RDB nécessite une marge pour le processus enfant forké et un cluster répliqué multiplie le nombre d'instances. La différence est négligeable à quelques gigaoctets, mais devient significative à plusieurs centaines.
2. Qui en est responsable au quotidien ? Une instance Memcached unique ne demande quasiment aucune maintenance. Un cluster Redis avec des nœuds maîtres et répliques, une gestion du basculement et un réglage de la persistance constitue un système dont quelqu'un doit être responsable : surveiller, tester le basculement, dimensionner la fenêtre d'instantané. Si personne n'est dédié à cette tâche dans votre équipe, les seules options réalistes sont un service managé ou Memcached. ElastiCache ou MemoryDB transfèrent cette charge au fournisseur et l'intègrent à la facture, ce qui est généralement le meilleur compromis pour une petite équipe.
3. Quels sont les risques liés aux licences et à la continuité ? En mars 2024, Redis est passé de la licence BSD à un modèle double source-disponible (RSALv2 et SSPLv1), ce qui a conduit la Linux Foundation à forker la dernière version BSD (7.2.4) sous le nom de Valkey. En mai 2025, Redis 8 a ajouté l'AGPLv3 — une licence open source approuvée par l'OSI — aux options source-disponible, faisant de Redis un logiciel à triple licence, tandis que Salvatore Sanfilippo avait rejoint l'entreprise l'année précédente. Le fork a néanmoins perduré : AWS signale lui-même que Redis 8.0 Community Edition est sous licence AGPLv3 (une licence copyleft interdite par de nombreuses organisations), alors que Memcached reste sous licence BSD, et recommande désormais Valkey pour les nouvelles charges de travail ElastiCache (AWS : Comparer Redis et Memcached). Cet épisode rappelle que Redis est une dépendance avec un propriétaire commercial et une licence qui a déjà changé sous la pression. Memcached est resté sous licence BSD sans aucun historique de ce type. Pour la plupart des équipes, ce n'est pas un obstacle. Pour quiconque intègre un cache dans un produit redistribué — où la clause copyleft de l'AGPL s'applique — c'est une question à trancher avant même d'écrire le code, et Valkey constitue une alternative permissive qu'il est utile de connaître.
Le délai de mise en valeur favorise généralement la simplicité au démarrage. Memcached est plus rapide à mettre en place et, comme le montre le test des coûts de sortie, migrer vers Redis plus tard ne coûte pas cher. L'inverse n'est pas vrai.
Pas systématiquement. Pour les petites valeurs, les performances par opération sont comparables, et Redis affiche un débit d'environ 100 000 requêtes par seconde pour une instance unique sur du matériel d'entrée de gamme. Memcached étant multithreadé, il traite davantage de données par seconde sur des machines multi-cœurs servant des valeurs simples et volumineuses. Redis l'emporte lorsque ses types de données permettent de remplacer plusieurs allers-retours applicatifs par une seule commande.
Oui, lorsque le besoin se limite strictement à du cache. Pour des données éphémères, des valeurs simples, sans besoin de persistance et avec des cœurs processeur disponibles, Memcached est plus simple à exploiter, plus économe en mémoire et présente une surface opérationnelle quasi nulle.
Oui, et c'est le sens le plus simple, ce qui est tout l'intérêt du test de coût de sortie. Redis prend en charge la plupart des commandes de Memcached ; en pratique, il suffit donc de rediriger le client et de laisser le cache se remplir. Faire l'inverse implique de réécrire les opérations sur les types de données en plusieurs commandes Memcached, complétées par un traitement côté application.
Non. Memcached est un cache volatil en mémoire : au redémarrage, son contenu est perdu. Redis assure la persistance via des instantanés RDB (dumps sur disque à un instant T) ou un journal AOF qui rejoue chaque commande d'écriture au démarrage.
Memcached, sur le plan de l'infrastructure, grâce à une consommation mémoire par élément plus faible et à la simplicité d'une instance unique. Redis coûte généralement plus cher une fois la réplication et la persistance activées. Le calcul change si Redis décharge vos serveurs d'application ou votre base de données, car ces économies peuvent compenser la différence de coût du cache.
Redis propose le clustering en natif, avec des nœuds maîtres et répliques ainsi qu'un basculement automatique. Memcached distribue la charge côté client, via un algorithme de partitionnement que vous implémentez vous-même. Les services managés proposent les deux ; pour les nouveaux déploiements, ElastiCache et Memorystore utilisent désormais par défaut le fork Valkey sous licence BSD, ce qui constitue généralement l'option la plus judicieuse pour les équipes sans ingénieur plateforme dédié.
De plus en plus, oui ; c'est la raison pour laquelle ce comparatif inclut un troisième nom depuis 2024. Valkey est le fork de Redis 7.2.4 sous licence BSD de la Linux Foundation, compatible avec l'API et désormais par défaut sur les principaux services managés. Si votre seule hésitation concernant Redis est liée à la licence, Valkey l'élimine sans modifier votre manière d'interagir avec le cache.
Vous hésitez sur le cache à choisir pour votre architecture ? Nous aidons les équipes techniques à sélectionner une infrastructure qu'elles peuvent se permettre d'exploiter et, tout aussi important, de faire évoluer par la suite. Discutez avec notre équipe de l'évolution de votre système.
Développeur web chez Nuage imaginaire, passionné par Node.js et par tout ce qui concerne le développement back-end.
CEO @ Imaginary Cloud et co-auteur du livre Product Design Process. J'aime la nourriture, le vin et le Krav Maga (pas nécessairement dans cet ordre).
People who read this post, also found these interesting:
.webp)
