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.
Au-delà des commandes spécifiques à chaque type, Redis a un ensemble de commandes transversales qui s'appliquent à toutes les clés. Ce sont celles que vous utiliserez quotidiennement.
Il n'y a pas de namespaces dans Redis — juste des clés dans un espace plat. La convention universelle est d'utiliser : comme séparateur :
user:42:profile
user:42:sessions
article:redis-intro:views
cache:api:weather:paris
ratelimit:ip:192.168.1.1Ce pattern permet de grouper les clés logiquement et de les retrouver avec SCAN. Évitez les clés trop génériques (data, cache) — en production vous aurez des milliers de clés et il faut pouvoir s'y retrouver.
# Vérifier l'existence d'une clé
EXISTS user:42:profile
# (integer) 1 → existe
# (integer) 0 → n'existe pas
# Supprimer une ou plusieurs clés
DEL user:42:profile user:42:sessions
# (integer) 2 → nombre de clés supprimées
# Connaître le type d'une clé
TYPE user:42:profile
# hash
# Renommer une clé
RENAME old:key new:key
# Lister toutes les clés (JAMAIS en production)
KEYS *
KEYS user:*
# Scanner les clés sans bloquer (à utiliser en production)
SCAN 0 MATCH user:* COUNT 100KEYS * bloque Redis pendant toute la durée du scan. Sur une base avec 1 million de clés, ça peut prendre plusieurs secondes et mettre le serveur hors-service. Utilisez SCAN en production — il parcourt les clés de façon itérative.
Redis peut supprimer automatiquement une clé après un délai. C'est l'une de ses fonctionnalités les plus utiles.
# Définir une expiration en secondes
EXPIRE session:abc123 3600 # expire dans 1 heure
# Définir une expiration en millisecondes
PEXPIRE session:abc123 3600000
# Définir une expiration absolue (timestamp Unix)
EXPIREAT session:abc123 1800000000
# Vérifier le TTL restant (en secondes)
TTL session:abc123
# (integer) 3547 → secondes restantes
# (integer) -1 → pas d'expiration
# (integer) -2 → clé inexistante
# Supprimer l'expiration (rendre la clé persistante)
PERSIST session:abc123
# SET avec expiration en une seule commande
SET token:xyz "abc" EX 900 # expire dans 15 min
SET token:xyz "abc" PX 900000 # idem en ms
SET token:xyz "abc" EXAT 1800000000 # timestamp absoluRedis est single-threaded côté exécution : toutes les commandes s'exécutent séquentiellement. Chaque commande individuelle est atomique par nature.
Pour grouper plusieurs commandes en une seule transaction :
# Transaction : MULTI / EXEC
MULTI
SET user:42:name "Alice"
INCR user:42:login_count
SET user:42:last_login "2026-06-19"
EXEC
# 1) OK
# 2) (integer) 5
# 3) OKSi une commande dans le bloc échoue (erreur de type, par exemple), les autres s'exécutent quand même. Ce n'est pas un rollback ACID — c'est une exécution groupée sans interleaving d'autres clients.
# Définir une valeur et retourner l'ancienne
GETSET compteur 0
# "15" → ancienne valeur, maintenant 0
# Définir uniquement si la clé n'existe pas (NX = Not eXists)
SET verrou:paiement "processing" NX EX 30
# OK → clé créée, verrou acquis
# (nil) → clé déjà existante, verrou non acquis
# Supprimer et retourner la valeur
GETDEL session:abc123
# "{"userId":42}" → valeur retournée et clé suppriméeSET ... NX EX est le pattern standard pour les distributed locks : un seul client peut acquérir le verrou, et il expire automatiquement si le client plante.
Redis optimise automatiquement la représentation interne selon la taille des données :
OBJECT ENCODING user:42:profile
# "ziplist" → petit hash (<128 champs, valeurs <64 bytes)
# "hashtable" → hash plus largeCes détails d'implémentation impactent la consommation mémoire. Un hash avec peu de champs courts est jusqu'à 10x plus efficace qu'un string JSON pour stocker la même information.
Vous avez les commandes de base. Le chapitre suivant explique l'expiration avancée et les deux modes de persistance — RDB et AOF.