Redis : structures et persistance

Prérequis : cours précédent.

Pourquoi

Utiliser Redis « comme un hash géant », c'est rater 80 % de l'outil — et se prendre les 20 % de risques (perte au restart). Structures adaptées + persistance comprise = Redis serein.

Concepts

• Persistance : RDB (snapshot périodique — rapide, perd l'intervalle), AOF (journal rejoué — sûr, plus lourd), les deux combinés en prod sérieuse. redis-check-aof pour réparer un journal corrompu.
• Éviction (maxmemory-policy) : quand la RAM est pleine : noeviction (erreurs — sûr), allkeys-lru (vire le moins récent — cache typique), volatile-ttl (que les clés à TTL). Toujours maxmemory + politique explicite, sinon OOM du conteneur.
• Transactions (MULTI/EXEC) et Lua : atomicité côté serveur pour les opérations composées (check-and-set). Sans ça : race conditions entre tes 3 commandes.

Exemple : file robuste minimale

LPUSH jobs:mail '{"to":"a@b.c"}'   # producteur
BRPOPLPUSH jobs:mail jobs:doing 30  # worker : réserve + déplace (reprise si crash)
LREM jobs:doing 1 <payload>         # après traitement

Cas réel

Redis sans maxmemory dans un conteneur sans limite : fuite de clés (sessions sans TTL !) → RAM → OOM-killer → Redis mort → sessions perdues → tout le monde déconnecté un lundi. Depuis : maxmemory + allkeys-lru + alerte à 80 %.

Pièges

• KEYS * en prod : bloque le serveur (O(N) global). SCAN + curseur, toujours.
• AOF sans fsync adapté : everysec = bon compromis (1 s perdable max) ; always = lent, no = OS décide.
• Un seul Redis sans réplica pour du « presque critique » : Sentinel ou Cluster quand la dispo compte vraiment.

À retenir

RDB+AOF combinés, maxmemory + politique explicite, MULTI/Lua pour l'atomique, SCAN pas KEYS.