Maîtriser Redis de zéro : types de données, commandes essentielles, expiration, persistance, cas d'usage réels (cache, sessions, files d'attente) et intégration Node.js.
Redis devient utile quand on sait quel pattern utiliser pour quel problème. Ce chapitre couvre les patterns les plus courants en production — tous implémentables avec les commandes vues précédemment.
Le cas le plus fréquent. Stocker la réponse d'une API ou d'une requête de base de données pour éviter de la recalculer.
# Pattern : cache-aside
# 1. Vérifier si la clé existe
GET cache:api:articles:page:1
# Si nil → requête base de données → stocker le résultat
SET cache:api:articles:page:1 '{"articles":[...]}' EX 300 # 5 min
# Invalider le cache lors d'une mise à jour
DEL cache:api:articles:page:1
DEL cache:api:articles:page:2
# Ou invalider tout le namespace
# (nécessite SCAN en production)Points d'attention :
Stocker les données de session côté serveur avec un ID aléatoire dans le cookie du client.
# Créer une session
SET session:a1b2c3d4e5f6 '{"userId":42,"role":"admin","lastSeen":"2026-06-19"}' EX 86400
# Lire une session
GET session:a1b2c3d4e5f6
# Renouveler le TTL à chaque requête (sliding expiration)
EXPIRE session:a1b2c3d4e5f6 86400
# Déconnecter (supprimer la session)
DEL session:a1b2c3d4e5f6
# Lister toutes les sessions d'un utilisateur
# (nécessite de stocker les IDs de sessions par user)
SADD user:42:sessions "a1b2c3d4e5f6"
SADD user:42:sessions "x9y8z7w6v5u4"
# Déconnecter partout
SMEMBERS user:42:sessions
# → supprimer chaque session puis vider le setLimiter le nombre de requêtes par IP ou par utilisateur sur une fenêtre de temps.
# Pattern : compteur avec TTL
# 1 requête → incrémenter le compteur
INCR ratelimit:ip:192.168.1.1:2026-06-19-14
# (integer) 1
# Définir le TTL sur la première requête de la fenêtre
EXPIRE ratelimit:ip:192.168.1.1:2026-06-19-14 3600
# Vérifier avant de servir
GET ratelimit:ip:192.168.1.1:2026-06-19-14
# Si > 1000 → renvoyer HTTP 429
# Atomic : INCR + EXPIRE en une seule passe
# (en réalité, géré dans le code applicatif)Fenêtre glissante avec Sorted Set (plus précis) :
# Score = timestamp en ms, member = ID unique de la requête
ZADD ratelimit:user:42 1750373800000 "req:uuid-1"
ZADD ratelimit:user:42 1750373801500 "req:uuid-2"
# Supprimer les entrées hors fenêtre (> 1 min)
ZREMRANGEBYSCORE ratelimit:user:42 0 1750373740000
# Compter les requêtes dans la fenêtre
ZCARD ratelimit:user:42
# Si > 100 → limiterRedis comme broker simple pour traitement asynchrone.
# Producteur : ajouter une tâche
LPUSH queue:emails '{"to":"alice@example.com","subject":"Bienvenue","template":"welcome"}'
LPUSH queue:emails '{"to":"bob@example.com","subject":"Facture","template":"invoice"}'
# Consommateur : récupérer une tâche (bloquant si la queue est vide)
BRPOP queue:emails 30
# Attend jusqu'à 30 secondes qu'une tâche arrive
# 1) "queue:emails"
# 2) '{"to":"bob@example.com",...}'
# Taille de la queue
LLEN queue:emails
# Inspecter sans dépiler
LRANGE queue:emails 0 9BRPOP est la commande clé : elle bloque le client jusqu'à ce qu'un élément soit disponible, avec un timeout. C'est bien plus efficace qu'un polling actif.
Redis comme bus de messages pour la communication entre services ou entre instances.
# Abonné (dans un terminal)
SUBSCRIBE channel:notifications
# Éditeur (dans un autre terminal)
PUBLISH channel:notifications '{"type":"new_article","slug":"redis-guide"}'
# L'abonné reçoit :
# 1) "message"
# 2) "channel:notifications"
# 3) '{"type":"new_article","slug":"redis-guide"}'
# S'abonner à plusieurs channels avec wildcard
PSUBSCRIBE channel:*Limitation : Pub/Sub n'est pas persistant. Si un abonné est déconnecté quand un message est publié, il le perd. Pour de la persistance, utilisez les Streams (Redis 5+) ou une vraie file d'attente avec BRPOP.
# Pages vues par article
INCR stats:article:redis-guide:views
# Utilisateurs uniques avec HyperLogLog (approximatif, très efficace en mémoire)
PFADD visitors:2026-06-19 "user:42" "user:99" "ip:1.2.3.4"
PFADD visitors:2026-06-19 "user:42" # dédupliqué
PFCOUNT visitors:2026-06-19
# (integer) 3
# HyperLogLog utilise max 12KB quel que soit le nombre d'éléments uniquesLes patterns sont en place. Le chapitre suivant implémente ces patterns en Node.js avec ioredis.