Redis

Qu’est-ce que Redis ?

Redis est un serveur de structures de données en mémoire. Il conserve l’intégralité de son jeu de données dans la RAM et répond aux commandes en quelques microsecondes. Chaque valeur est stockée sous une clé de type chaîne de caractères (string), et la valeur peut être une string, un hash, une liste, un set, un sorted set, un stream, un bitmap ou un HyperLogLog.

Lancé en 2009 pour accélérer un produit d’analyse en temps réel, il est rapidement devenu le cache par défaut du web. La raison n’est pas seulement la vitesse. Redis propose également un ensemble de commandes concis et composables, des structures de données utiles, des TTL, la réplication et le scripting — suffisamment pour que les équipes l’utilisent pour bien plus que du simple caching.

Considérez Redis comme une structure de données en mémoire partagée, visible par tous les processus. Cette approche explique à la fois ses forces et ses limites.

Pourquoi Redis est rapide

Trois facteurs expliquent la rapidité de Redis, et aucun d’entre eux n’est un secret.

Premièrement, les données résident en mémoire. Il n’y a pas de recherche sur disque ni de pool de tampons (buffer pool) à gérer lors de la lecture. L’accès à la mémoire se mesure en nanosecondes, tandis qu’un aller-retour réseau se mesure en fractions de milliseconde.

Deuxièmement, il n’y a pas de planificateur de requêtes (query planner). Une commande comme GET user:42 correspond à une recherche dans une table de hachage, et ZADD à une insertion dans une skip-list. Il n’y a pas d’analyse syntaxique d’un langage de requête, pas d’étape d’optimisation et pas de jointures. L’opération est fixe et directe.

Troisièmement, les commandes s’exécutent une par une sur un seul thread. Cela peut ressembler à une faiblesse, mais cela élimine les conflits de verrouillage (lock contention) et rend chaque commande atomique. La boucle d’événements (event loop) gère des milliers de connexions et exécute les commandes séquentiellement, c’est pourquoi une seule instance peut supporter un débit énorme.

Le piège est qu’une seule commande lente bloque tout le reste. Un KEYS * sur des millions de clés, ou un ZRANGE sur un ensemble trié (sorted set) massif, fige tous les autres clients. Gardez vos commandes bornées et utilisez SCAN au lieu de KEYS en production.

Les structures de données essentielles

Le choix de la bonne structure représente l’essentiel de la compétence. Voici l’utilité de chacune d’entre elles.

Les Strings stockent du texte, du JSON, des compteurs et des données binaires. SET, GET, INCR, APPEND et SETEX sont les outils les plus utilisés.

SET user:42:name "Ada"
INCR page:home:views
SETEX token:abc123 900 "opaque-token-value"

Les Hashes stockent un objet sous forme de paires champ-valeur sous une seule clé. Ils sont parfaits pour les sessions et les enregistrements que vous mettez à jour champ par champ, car vous évitez de sérialiser l’objet complet à chaque écriture.

HSET session:9f2c userId 42 role admin
HINCRBY session:9f2c pageViews 1
HGET session:9f2c role

Les Lists sont des séquences ordonnées avec des opérations push et pop en O(1) aux deux extrémités. Elles permettent de créer facilement des files d’attente, des flux d’activités récentes et des logs plafonnés.

LPUSH queue:emails "welcome:42"
RPOP queue:emails
LTRIM feed:global 0 99

Les Sets contiennent des membres uniques et non ordonnés. Utilisez-les pour les tags, les abonnés et les tests d’appartenance.

SADD post:7:tags redis database
SISMEMBER post:7:tags redis
SINTER user:1:follows user:2:follows

Les Sorted sets sont les stars du lot. Chaque membre possède un score, ainsi l’ensemble reste trié par score tandis que les recherches restent en O(log n). Les classements (leaderboards), les files de priorité et les fenêtres de rate-limit les utilisent tous.

ZADD leaderboard 1500 ada
ZINCRBY leaderboard 50 ada
ZREVRANGE leaderboard 0 9 WITHSCORES

Les Streams sont des logs en ajout seul (append-only) avec des groupes de consommateurs, se rapprochant plus de Kafka que d’une liste. Utilisez-les lorsque vous avez besoin de relecture (replay), d’accusés de réception et de plusieurs consommateurs.

XADD events * type signup userId 42
XREADGROUP GROUP workers alice COUNT 10 STREAMS events ">"

Les Bitmaps et HyperLogLogs gèrent le comptage spécialisé. Les Bitmaps suivent des booléens par utilisateur avec un seul bit chacun, idéal pour les utilisateurs actifs quotidiens ; HyperLogLog estime le nombre d’éléments uniques avec environ 12 KB et un faible taux d’erreur.

SETBIT active:2026-09-16 42 1
PFADD visitors:2026-09-16 user:42
PFCOUNT visitors:2026-09-16

Si vous ne devez retenir qu’une seule règle, c’est celle-ci : choisissez la structure qui correspond au mode d’accès aux données, et non celle qui correspond au JSON que vous possédez déjà.

Nommage des clés et espaces de noms (namespacing)

Redis ne possède ni tables, ni schémas, ni espaces de noms. La seule structure est la clé elle-même ; votre convention de nommage fait donc office de schéma.

Un modèle courant consiste à object:id:attribute en segments séparés par des deux-points :

user:42
user:42:sessions
session:9f2c
order:1001:items
rate:203.0.113.7:2026091612

Des clés courtes et prévisibles permettent de réduire la consommation mémoire et facilitent le scan ainsi que le débogage. Ajoutez un préfixe de version ou d’environnement lorsque plusieurs applications partagent une instance : app:v2:user:42. Évitez les clés dérivées d’entrées utilisateur non contrôlées, et n’utilisez jamais d’espaces ou de sauts de ligne.

Comme les clés sont des chaînes de caractères, vous pouvez les lister pour le débogage, mais faites-le avec prudence. SCAN avec un curseur est sans danger ; KEYS ne l’est pas, car cela bloque le serveur pendant qu’il parcourt l’intégralité de l’espace des clés.

Expiration, TTL et éviction

L’expiration est ce qui fait de Redis un cache plutôt qu’une fuite de mémoire. Presque chaque clé que vous créez pour le caching devrait avoir un TTL.

SET user:42 '{"name":"Ada"}' EX 300   # seconds
SET user:42 '{"name":"Ada"}' PX 300000 # milliseconds
EXPIRE user:42 300
TTL user:42
PERSIST user:42

EXPIRE et ses variantes attachent un délai d’expiration ; TTL indique le nombre de secondes restantes. L’expiration est à la fois lazy et active : les clés sont supprimées lorsqu’elles sont accédées après leur expiration, et un cycle en arrière-plan échantillonne et nettoie les clés expirées afin que la mémoire soit récupérée même si elles ne sont plus jamais lues.

Les TTL seuls ne suffisent pas lorsque le jeu de données croît plus vite qu’il n’expire. Configurez maxmemory et une maxmemory-policy :

• noeviction — rejette les écritures lorsque la mémoire est pleine ; le choix par défaut sécurisé pour les données durables.
• allkeys-lru — évince la clé la moins récemment utilisée, quel que soit son type ; le choix classique pour un cache.
• allkeys-lfu — évince la clé la moins fréquemment utilisée, préférable lorsqu’un petit ensemble de données “chaudes” est prioritaire.
• volatile-lru / volatile-ttl — évince uniquement les clés qui possèdent une expiration, protégeant ainsi les clés persistantes.

CONFIG SET maxmemory 2gb
CONFIG SET maxmemory-policy allkeys-lru

Ce choix est important. allkeys-lru n’hésitera pas à évincer une session si c’est la clé la plus “froide” ; volatile-ttl ne le fera pas, car les sessions possèdent toujours une expiration.

Modèles de mise en cache et invalidation

Le modèle le plus courant est le cache-aside. L’application vérifie d’abord Redis, se rabat sur la base de données en cas d’absence (miss), puis réécrit le résultat avec un TTL.

async function getUser(id) {
  const key = `user:${id}`;
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  const user = await db.users.findById(id);
  if (user) await redis.set(key, JSON.stringify(user), { EX: 300 });
  return user;
}

Deux autres modèles valent la peine d’être connus. Le Write-through met à jour simultanément le cache et la base de données, ce qui permet de garder les lectures “chaudes” mais double le chemin d’écriture. Le Write-behind écrit d’abord dans Redis et vide les données vers la base de données de manière asynchrone, ce qui est rapide mais présente un risque de perte de données.

L’invalidation est la partie la plus complexe. Un TTL garantit une correction éventuelle ; les suppressions explicites rendent l’invalidation immédiate. La bonne pratique consiste à mettre à jour la base de données en premier, puis à supprimer la clé du cache, tout en acceptant une courte fenêtre durant laquelle un lecteur concurrent pourrait repopuler le cache avec des données obsolètes.

async function updateUser(id, patch) {
  const user = await db.users.update(id, patch);
  await redis.del(`user:${id}`);
  return user;
}

Évitez la tentation de conserver un cache indéfiniment sous prétexte que l’invalidation est fastidieuse. Les données obsolètes et une mémoire non bornée sont des problèmes bien plus graves qu’un taux de succès (hit rate) légèrement inférieur.

Sessions, limitation de débit et classements

Redis excelle dès qu’un état doit être partagé entre plusieurs processus et survivre aux redémarrages.

Les sessions sont un hash ou une chaîne sérialisée avec un TTL qui se renouvelle à chaque requête.

await redis.set(`session:${sid}`, JSON.stringify(data), { EX: 3600 });
await redis.expire(`session:${sid}`, 3600); // sliding window

La limitation de débit (rate limiting) est un compteur avec une expiration. Une fenêtre fixe nécessite deux commandes ; une fenêtre glissante utilise un sorted set d’horodatages.

const minute = Math.floor(Date.now() / 60_000);
const key = `rate:${ip}:${minute}`;
const replies = await redis.multi().incr(key).expire(key, 60).exec();
if (replies[0] > 100) throw new Error("rate_limited");

Les classements (leaderboards) sont un sorted set. ZADD enregistre un score, ZINCRBY l’ajuste, et ZREVRANGE retourne les meilleurs joueurs avec leurs scores. ZRANK donne la position d’un seul joueur, ce qui est exactement ce dont une page de profil a besoin.

ZADD leaderboard 1500 ada
ZINCRBY leaderboard 50 ada
ZREVRANGE leaderboard 0 9 WITHSCORES
ZRANK leaderboard ada

Ces trois modèles reposent sur les deux mêmes propriétés : les commandes sont atomiques et chaque clé peut expirer.

Files d’attente et pub/sub

Les listes constituent une file d’attente de travail fiable. Producteurs LPUSH, workers BRPOP — le pop bloquant permet à un worker de rester en veille jusqu’à l’arrivée d’une tâche au lieu d’effectuer du polling.

LPUSH queue:emails "welcome:42"
BRPOP queue:emails 30

Pour une file d’attente robuste, déplacez les tâches vers une liste de traitement avant de les gérer, et ne les supprimez qu’en cas de succès. De cette façon, un worker qui plante ne perdra pas silencieusement une tâche.

Le Pub/sub est un système de messagerie de type “fire-and-forget” : les éditeurs PUBLISH publient, et les abonnés reçoivent sur des canaux. C’est excellent pour les notifications en temps réel et les signaux de cache-busting, mais il n’y a ni persistance ni garantie de livraison. Si un abonné est hors ligne, le message est perdu.

PUBLISH notifications:user:42 "You have a new follower"
SUBSCRIBE notifications:user:42

Lorsque vous avez besoin de persistance, d’accusés de réception et de relecture, utilisez plutôt des streams avec des groupes de consommateurs. Les streams sont la réponse moderne au besoin de “pub/sub, mais fiable”.

Pipelines, transactions et Lua

Une commande représente un aller-retour réseau. Si vous avez besoin de dix valeurs, dix GET séquentiels passeront la majeure partie de leur temps à attendre le réseau. Un pipeline les envoie ensemble et lit toutes les réponses d’un coup.

const [name, plan, logins] = await redis
  .multi()
  .hget("user:42", "name")
  .hget("user:42", "plan")
  .hget("user:42", "logins")
  .exec();

Un pipeline n’est pas automatiquement une transaction. Le fait d’envelopper des commandes dans MULTI/EXEC permet de les exécuter comme un seul bloc atomique, sans qu’aucune commande d’un autre client ne vienne s’intercaler. Redis n’effectue pas de rollback en cas d’erreur de commande comme le fait SQL ; il continue simplement son exécution, veillez donc à valider vos entrées avant de les mettre en file d’attente.

Pour la logique qui doit s’exécuter de manière atomique sur le serveur, utilisez un script Lua. Il s’exécute comme une commande unique, peut lire et écrire plusieurs clés, et constitue l’outil approprié pour les opérations de type “compare-and-set”, comme le fait de libérer un verrou uniquement si vous en êtes toujours le propriétaire.

const release = `
  if redis.call("get", KEYS[1]) == ARGV[1] then
    return redis.call("del", KEYS[1])
  end
  return 0
`;

await redis.eval(release, { keys: ["lock:order:1001"], arguments: [token] });

Les scripts doivent être courts et déterministes. N’exécutez rien sans limite définie à l’intérieur d’un script, car l’ensemble du serveur attend sa fin d’exécution.

Persistance : RDB et AOF

Le stockage en mémoire ne signifie pas nécessairement que les données sont éphémères, mais la durabilité est un compromis que vous devez choisir.

RDB écrit des instantanés (snapshots) du jeu de données sur le disque, soit selon un planning, soit à la demande. Les snapshots sont compacts, se restaurent rapidement et sont idéaux pour les sauvegardes. L’inconvénient est qu’en cas de crash, tout ce qui a été écrit depuis le dernier snapshot est perdu.

SAVE     # blocking snapshot, avoid in production
BGSAVE   # fork and snapshot in the background

AOF ajoute chaque commande d’écriture à un journal (log). Avec appendfsync everysec, vous perdez au maximum environ une seconde d’écritures ; avec always, vous ne perdez presque rien, mais au prix d’un coût d’écriture beaucoup plus élevé. Les fichiers AOF peuvent être réécrits en arrière-plan pour rester compacts.

CONFIG SET appendonly yes
CONFIG SET appendfsync everysec

De nombreux déploiements activent les deux : RDB pour des restaurations rapides et AOF pour limiter la fenêtre de perte de données. Si vous utilisez Redis purement comme cache, vous pouvez désactiver complètement la persistance et laisser le cache froid se remplir à nouveau depuis la base de données. Si vous l’utilisez pour des files d’attente ou des compteurs importants, maintenez la persistance activée et comprenez exactement quelle quantité de données un crash peut vous coûter.

Réplication, Sentinel et Cluster

Un replica se connecte à un primaire et reçoit un flux d’écritures, conservant ainsi une copie en quasi temps réel. Les replicas peuvent gérer les lectures, ce qui décharge le primaire, et ils constituent la base du basculement (failover).

Sentinel surveille un primaire et ses replicas, et promeut un replica lorsque le primaire tombe en panne. Il communique également l’adresse du nouveau primaire aux clients. Sentinel assure la haute disponibilité pour un jeu de données pouvant tenir sur un seul nœud.

Redis Cluster fragmente (shard) les données entre plusieurs nœuds en utilisant 16 384 hash slots. Chaque clé est associée à un slot via le hachage de son nom, et chaque nœud possède une plage de slots. Les clients peuvent communiquer avec n’importe quel nœud et sont redirigés vers le bon. Cluster permet une mise à l’échelle horizontale et le basculement, au prix d’une complexité accrue : les opérations multi-clés doivent maintenir les clés dans le même slot, généralement via des hash tags tels que user:{42}:name.

Le parcours classique consiste à commencer par une instance unique, puis un replica, ensuite Sentinel, et enfin Cluster uniquement lorsque la mémoire ne suffit plus sur une seule machine.

Anti-patterns courants

• Redis comme unique base de données. Sans une persistance et une réplication configurées pour la durabilité, un crash peut entraîner une perte de données. Conservez un système d’enregistrement durable.
• Clés sans limite de durée. Chaque clé mise en cache doit avoir un TTL, sinon la mémoire se remplit et l’éviction commence à supprimer des éléments dont vous avez besoin.
• Clés et collections volumineuses. Un seul hash avec des millions de champs, ou une liste avec des millions d’entrées, est lent à supprimer et peut bloquer le serveur.
• KEYS en production. Cela bloque l’event loop. Utilisez SCAN.
• Une seule clé pour tout. Sérialiser un objet entier à chaque modification provoque une amplification d’écriture. Utilisez des hashes et mettez à jour les champs individuellement.
• Ignorer la politique d’éviction. allkeys-lru peut évincer des sessions et des verrous, et pas seulement des entrées de cache.

Connexion depuis Node

Deux clients dominent l’écosystème Node : node-redis et ioredis. Tous deux utilisent le même protocole et exposent une méthode par commande ; le choix se résume donc généralement à une préférence pour l’API ou au support du clustering.

import { createClient } from "redis";

const redis = createClient({ url: process.env.REDIS_URL });
redis.on("error", (err) => console.error("redis", err));
await redis.connect();

await redis.set("health", "ok", { EX: 60 });
const value = await redis.get("health");

Créez le client une seule fois au démarrage et partagez-le. Une connexion est un socket avec une file d’attente de commandes, et en ouvrir une par requête ajoute de la latence et consomme des descripteurs de fichiers. Attachez toujours un gestionnaire error : sans lui, une déconnexion peut se manifester sous la forme d’une exception non gérée.

La plupart des commandes retournent des valeurs simples, mais les options sont passées sous forme d’objet. SET accepte { EX: 300 } pour les secondes, { NX: true } pour écrire uniquement si la clé est absente, et { KEEPTTL: true } pour préserver une expiration existante. NX combiné à un TTL est la recette standard pour un verrou distribué (distributed lock).

const acquired = await redis.set(`lock:order:${id}`, token, {
  NX: true,
  EX: 30,
});

Pour un déploiement shardé, choisissez un client qui comprend les redirections de cluster et les hash tags. Les deux clients principaux le font ; l’important est de garder les clés liées dans le même slot lorsqu’une commande en touche plus d’une.

Surveiller une instance en cours d’exécution

Quelques commandes suffisent pour obtenir presque toutes les informations sur la santé d’une instance Redis.

INFO memory
INFO stats
DBSIZE
SLOWLOG GET 10

INFO memory indique used_memory, maxmemory ainsi que la politique actuelle. INFO stats inclut keyspace_hits et keyspace_misses, dont le ratio représente votre taux de succès du cache (cache hit rate) — la valeur à surveiller lors de l’ajustement des TTL. DBSIZE compte les clés, et SLOWLOG enregistre les commandes ayant dépassé un seuil de latence.

CONFIG SET slowlog-log-slower-than 10000  # microseconds
CONFIG RESETSTAT

Deux autres outils sont utiles mais dangereux. MONITOR diffuse en temps réel chaque commande traitée par le serveur ; c’est un outil précieux pour le débogage, mais trop coûteux pour être laissé activé en production. SCAN parcourt l’espace des clés par lots de taille curseur et est sécurisé, contrairement à KEYS.

Surveillez trois indicateurs sur un tableau de bord : l’utilisation de la mémoire par rapport à maxmemory, le nombre d’expulsions (eviction count) et le taux de succès du cache. Un taux de succès en baisse accompagné d’une hausse des expulsions signifie généralement que les TTL sont trop courts ou que le jeu de données ne tient plus en mémoire ; il est alors préférable d’ajouter de la mémoire ou de corriger les clés plutôt que d’augmenter la limite et de laisser l’instance utiliser le swap.

Bonnes pratiques

• Définissez un TTL sur chaque clé mise en cache et choisissez une politique d’éviction adaptée aux données.
• Utilisez un schéma de nommage object:id:attribute cohérent et documentez-le.
• Choisissez la structure de données qui correspond au mode d’accès avant d’écrire le code.
• Réutilisez une seule connexion client et utilisez le pipelining pour les commandes indépendantes.
• Utilisez Lua ou MULTI pour les opérations atomiques en plusieurs étapes, et gardez-les concises.
• Privilégiez SCAN à KEYS, et limitez la taille de chaque clé.
• Activez la persistance et la réplication pour les données que vous ne pouvez pas reconstruire, et testez la restauration.
• Surveillez la mémoire, le taux de succès (hit rate), les évictions et les commandes lentes avant qu’elles ne deviennent des incidents.

Erreurs courantes

• Mettre en cache sans TTL et épuiser progressivement la mémoire.
• Utiliser KEYS * pour rechercher des clés et bloquer tous les autres clients.
• Traiter le pub/sub comme une file d’attente fiable et perdre des messages lorsqu’un abonné est hors ligne.
• Stocker un objet volumineux sous forme d’une seule chaîne JSON et le réécrire pour chaque petite modification.
• Supposer que MULTI effectue un rollback comme une transaction SQL ; ce n’est pas le cas.
• Laisser une “hot key” ou un ensemble trié (sorted set) trop volumineux devenir un goulot d’étranglement.
• Oublier que allkeys-lru peut expulser des sessions, des verrous et des compteurs de limitation de débit (rate-limit).
• Exécuter Redis sans persistance et sans réplica, puis perdre des données lors du redémarrage.

Et après ?

Redis est l’application concrète du caching, et sa maîtrise permet de rendre tangibles les patterns de mise en cache de la backend roadmap. Associez-le à un système de stockage durable : PostgreSQL pour les données relationnelles ou MongoDB pour les documents. Connectez ensuite le tout à un service Node et revenez aux Node.js basics pour comprendre comment le client s’intègre dans votre flux de requêtes.