Redis

Redis est en mémoire — ce qui signifie que les données disparaissent si le processus s'arrête. Selon votre cas d'usage, c'est acceptable (cache pur) ou catastrophique (sessions utilisateur). Redis propose deux mécanismes pour persister les données sur disque.

L'expiration en pratique

Redis vérifie les expirations de deux façons :

Passive : quand vous accédez à une clé, Redis vérifie si elle est expirée. Si oui, il la supprime et retourne nil.

Active : toutes les 100ms, Redis échantillonne 20 clés aléatoires avec TTL et supprime celles qui ont expiré. Si plus de 25% des clés testées sont expirées, il recommence immédiatement.

Ce double mécanisme garantit que les clés expirées sont supprimées rapidement sans bloquer le serveur.

Patterns d'expiration utiles

# Cache avec refresh automatique
# Chaque accès renouvelle le TTL
SET cache:user:42 '{"name":"Alice"}' EX 3600
# ... plus tard, après accès :
EXPIRE cache:user:42 3600  # repart à 1h
 
# Token d'API qui expire à minuit
EXPIREAT api_token:xyz 1750377600
 
# Clé qui n'expire jamais (par défaut)
SET config:feature_flags '{"dark_mode":true}'
TTL config:feature_flags
# (integer) -1

RDB — Snapshot

RDB (Redis Database) crée des instantanés complets de la base à intervalles réguliers. C'est le mode par défaut.

# Dans redis.conf — sauvegarder si :
save 900 1      # 1 modification en 900 secondes (15 min)
save 300 10     # 10 modifications en 300 secondes (5 min)
save 60 10000   # 10 000 modifications en 60 secondes
 
# Emplacement du fichier
dir /var/lib/redis
dbfilename dump.rdb

Déclencher un snapshot manuellement :

# Bloquant (freeze pendant la sauvegarde)
redis-cli SAVE
 
# Non-bloquant (fork un processus enfant)
redis-cli BGSAVE
 
# Vérifier le statut
redis-cli LASTSAVE
# (integer) 1750373800  →  timestamp Unix du dernier snapshot

Avantages RDB : fichier compact, restauration rapide, impact minimal sur les performances en fonctionnement normal.

Inconvénient : vous pouvez perdre les données entre deux snapshots. Si Redis crashe 4 minutes après le dernier snapshot à 5 minutes, vous perdez 4 minutes de données.

AOF — Append Only File

AOF journalise chaque commande d'écriture dans un fichier. Pour restaurer, Redis rejoue le journal depuis le début.

# Activer AOF dans redis.conf
appendonly yes
appendfilename "appendonly.aof"
 
# Fréquence de synchronisation sur disque
appendfsync always    # après chaque commande — durabilité max, performances réduites
appendfsync everysec  # toutes les secondes — équilibre recommandé
appendfsync no        # laisse l'OS décider — performances max, risque de perte

AOF Rewrite : le fichier AOF grossit indéfiniment (chaque INCR ajoute une ligne). Redis le compacte périodiquement :

# Déclencher une réécriture manuelle
redis-cli BGREWRITEAOF
 
# Configuration automatique
auto-aof-rewrite-percentage 100   # si le fichier a doublé depuis le dernier rewrite
auto-aof-rewrite-min-size 64mb    # et fait au moins 64MB

Avantage AOF : perte de données maximale = 1 seconde (avec everysec).

Inconvénient : fichier plus grand, restauration plus lente (rejoue toutes les commandes).

Choisir entre RDB, AOF, ou les deux

Pour la majorité des cas en production : AOF avec appendfsync everysec + RDB toutes les heures comme backup.

# Configuration recommandée pour la production
save 3600 1
appendonly yes
appendfsync everysec

Vérifier la santé de la persistance

redis-cli info persistence

rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
aof_enabled:1
aof_last_rewrite_time_sec:2
aof_last_bgrewrite_status:ok
aof_current_size:8432192

Si rdb_last_bgsave_status ou aof_last_bgrewrite_status affiche err, quelque chose ne va pas — espace disque plein, permissions incorrectes sur le répertoire.

La persistance est configurée. Le chapitre suivant couvre les cas d'usage concrets : cache HTTP, sessions, rate limiting et pub/sub.