Redis

Client du cache in-memory le plus répandu dans les architectures modernes (session store, queue, rate limiter, cache distribué).

Installation


# Debian / Ubuntu
apt install redis-server
systemctl start redis
systemctl enable redis
 
# Docker
docker run -d -p 6379:6379 --name redis redis:7-alpine
 
# CLI interactif
redis-cli

Configuration par défaut : port 6379, bind 127.0.0.1, fichier appendonly.aof dans appendonlydir.

Structures de données

Strings (`SET` / `GET`)


SET key "valeur"                  # valeur binaire jusqu'à 512 Mo
GET key
SETEX key 60 "valeur"             # clé avec expiration (secondes)
PSETEX key 60000 "valeur"         # expiration en millisecondes
INCR key                          # incrémenter de 1 (crée la clé)
INCRBY key 5                      # incrémenter de N
APPEND key "suffixe"              # concaténer à la fin

Lists (`LPUSH` / `RPUSH`)

Ordre d’insertion, taille illimitée.


LPUSH queue "message"             # insérer à gauche (tête)
RPUSH queue "message"             # insérer à droite (queue)
LRANGE queue 0 -1                 # tout récupérer
LPOP queue                        # extraire la tête
RPOP queue                        # extraire la queue
LLEN queue                        # longueur
LINDEX queue 3                    # élément à l'indice 3
BLPOP queue 30                    # blocage jusqu'à 30s ou null

Sets (`SADD` / `SREM`)

Collection non ordonnée, valeurs uniques.


SADD tags "redis" "database"      # ajouter des valeurs
SISMEMBER tags "redis"            # tester l'appartenance
SMEMBERS tags                     # toutes les valeurs
SCARD tags                        # nombre de valeurs
SINTER s1 s2                      # intersection
SUNION s1 s2                      # union
SDIFF s1 s2                       # différence

Hashes (`HSET` / `HGET`)

Map clé-valeur stockée sous un seul nom de clé (économise de l’espace vs. plusieurs strings).


HSET user:1 name "Alice" age 30   # un ou plusieurs champs
HGET user:1 name                  # un champ
HMGET user:1 name age             # plusieurs champs
HGETALL user:1                    # tous les champs
HDEL user:1 age                   # supprimer un champ
HINCRBY user:1 age 2              # incrémenter un champ numérique

Sorted Sets (`ZADD` / `ZRANGE`)

Valeurs uniques avec un score flottant pour le tri.


ZADD leaderboard 100 "Alice" 200 "Bob"   # score + valeur
ZRANGE leaderboard 0 -1 WITHSCORES       # du premier au dernier
ZRANGEBYSCORE leaderboard 100 200        # par fenêtre de score
ZREVRANGE leaderboard 0 9 WITHSCORES     # top 10
ZREM leaderboard "Alice"                 # supprimer une valeur
ZINCRBY leaderboard 50 "Alice"           # incrémenter le score

Streams (`XADD` / `XREAD`)

Log immuable, inspiré de Kafka. Idéal pour event sourcing et queues durables.


XADD events * id "uuid" type "login"    # ajouter un message
XADD events MAXLEN ~ 1000 * id "uuid"   # tronquer automatiquement
XLEN events                             # nombre de messages
XREAD STREAMS events 0                  # lire depuis le début
XREAD STREAMS events $                  # lire les nouveaux messages uniquement
XRANGE events - +                       # tout lire
XACK events group "id"                  # acquitter un message
XINFO STREAM events                     # métadonnées du stream

Pattern cache avec expiration

La clé pour un cache performant est l’expiration automatique.


SET cache:user:42 '{"name":"Alice"}' EX 3600          # expire dans 1h (secondes)
SET cache:user:42 '{"name":"Alice"}' PX 3600000       # expire dans 1h (ms)
SET cache:user:42 '{"name":"Alice"}' EXAT 1700000000  # expire à une date absolue
 
# Modifier l'expiration d'une clé existante sans en changer la valeur
GETEX cache:user:42 EX 7200                           # étendre le TTL à 2h
GETEX cache:user:42 EXAT 1700100000                   # modifier la date d'expiration
 
# Vérifier le TTL restant (en secondes, -1 = pas d'expiration, -2 = clé absente)
TTL cache:user:42
 
# Retirer l'expiration (utile en debug)
PERSIST cache:user:42

Mise en garde sur les patterns cache

Cache stampede : un pic de trafic sur une clé périmée peut submerger la base. Utiliser un mutex (SET NX) ou générer la valeur en arrière-plan.
TTL trop long : données périmées consommant de la mémoire. TTL trop court : cache inefficace. Ajuster selon la fraîcheur acceptable des données.
Race condition SETNX : la combinaison SETNX puis EXPIRE introduit une fenêtre où la clé peut être supprimée avant d’avoir un TTL. Depuis Redis 7.0, utiliser SET key value EX seconds NX (opération atomique).

Pub/Sub

Communication événementielle asymétrique. Pas de persistance — un client absent ne reçoit pas les messages publiés entre-temps.


# Côté abonné
SUBSCRIBE channel:news                    # recevoir tous les messages
SUBSCRIBE channel:news channel:alert      # plusieurs canaux
 
# Côté éditeur
PUBLISH channel:news "Nouvel article publié"
PUBLISH channel:alert "Alerte: seuil dépassé"
 
# Canaux avec patron (wildcard)
PSUBSCRIBE channel:*                       # tous les canaux « channel.* »

Limites de Pub/Sub

Pas de persistance des messages.
Pas d’acquittement.
Pas de replay possible.
Pour du message broker durable, utiliser les Streams (XADD / XREADGROUP).

Persistence

Redis est volatile par défaut — la donnée est perdue au redémarrage sans configuration.


# RDB : snapshot binaire périodique (par défaut)
BGSAVE                                  # générer un snapshot en arrière-plan
LASTSAVE                                # timestamp du dernier snapshot
 
# AOF : journal des écritures (recommandé pour la durabilité)
CONFIG SET appendonly yes               # activer l'AOF
CONFIG SET appendfsync everysec         # écrire chaque seconde (répondance)
 
# Chargement au démarrage : AOF puis RDB

Commandes de maintenance


# Informations
DBSIZE                                  # nombre de clés
INFO memory                             # mémoire utilisée, pic, fragmentation
INFO keyspace                           # statistiques par type de clé
KEYS pattern                            # toutes les clés correspondant (à éviter en production)
SCAN 0 MATCH pattern COUNT 100         # alternative non-bloquante à KEYS
 
# Nettoyage
DEL key1 key2                           # supprimer des clés
UNLINK key1                             # suppression asynchrone (ne bloque pas)
FLUSHDB                                 # vider la base courante
FLUSHALL                                # vider toutes les bases
 
# Configuration en cours
CONFIG GET maxmemory                    # limite mémoire
CONFIG SET maxmemory 256mb              # limiter la mémoire
CONFIG REWRITE                          # écrire la conf modifiée dans redis.conf
 
# Clients connectés
CLIENT LIST                             # tous les clients
CLIENT GETNAME                          # nom du client courant
CLIENT KILL ID 42                       # tuer un client par ID
CLIENT PAUSE 5000                       # suspendre tous les clients 5s (debug)
 
# Éviction (quand maxmemory est atteint)
# Policies : allkeys-lru, volatile-lru, allkeys-lfu, volatile-ttl, noeviction
CONFIG SET maxmemory-policy allkeys-lru

Commandes complexes utiles


# Évaluation de scripts Lua (atomique)
EVAL "return redis.call('GET', KEYS[1])" 1 mykey
 
# Transactions
MULTI                                   # début de transaction
SET key1 "valeur1"
SET key2 "valeur2"
EXEC                                      # exécution atomique
DISCARD                                   # annuler
 
# Lua vs transactions : Lua est atomique et retourne des résultats intermédiaires.
# Les transactions (MULTI/EXEC) ne retournent rien tant que le bloc n'est pas exécuté.
 
# Pipeline (réduction de latence réseau)
redis-cli --pipe << EOF
SET key1 "valeur1"
SET key2 "valeur2"
SET key3 "valeur3"
EOF

Références

Documentation officielle Redis
Redis Best Practices
Redis JSON module (module optionnel pour stockage JSON natif)