Redis, c'est quoi ? Guide cache, sessions et files

La réponse la plus courte à la question Redis, c'est quoi est la suivante : c'est un magasin de données clé-valeur, en mémoire, extrêmement rapide. Acronyme de Remote Dictionary Server, Redis conserve les données en RAM plutôt que sur disque, ce qui lui permet de lire et d'écrire en quelques microsecondes. Dans ce guide, j'explique pourquoi Redis est si rapide, dans quels cas il est réellement utile, et comment il s'intègre à un projet web comme cache, magasin de sessions et file d'attente, avec des exemples concrets.

Redis, c'est quoi et pourquoi est-il si rapide ?

Redis n'est pas conçu pour remplacer les bases de données relationnelles classiques (MySQL, PostgreSQL), mais pour se placer devant elles comme une couche rapide. Comme l'ensemble des données vit en mémoire, la latence du disque disparaît. À cela s'ajoutent quelques caractéristiques essentielles :

• Il utilise un modèle mono-thread, orienté événements, ce qui lui permet de traiter des centaines de milliers d'opérations par seconde sans conflit de verrous.
• Il propose plus que du simple texte : des structures riches comme les listes, ensembles (sets), ensembles triés, hash et compteurs.
• Si vous le souhaitez, il peut aussi écrire les données sur disque (instantanés RDB ou journal AOF) pour résister aux redémarrages.

Redis n'est donc pas qu'un simple « cache » ; bien utilisé, il peut servir de magasin de sessions, de courtier de file d'attente, de compteur en temps réel et même de canal de messagerie simple.

Commandes de base et structures de données

Le moyen le plus rapide de commencer avec Redis est le client en ligne de commande redis-cli. Les commandes les plus courantes sont assez intuitives :

SET utilisateur:42:nom "Aslain"
GET utilisateur:42:nom
EXPIRE utilisateur:42:nom 3600   # suppression auto après 1 heure
INCR page:vues                   # compteur atomique
LPUSH file:mail "id:1001"        # ajoute en tête de liste
HSET produit:7 nom "Clavier" prix 450

Les commandes EXPIRE et INCR sont importantes ici. L'expiration automatique (TTL) rend Redis idéal pour le cache, tandis que l'incrément atomique permet de tenir un compteur sans condition de concurrence (race condition). Utiliser une convention séparée par deux-points dans les noms de clés, comme utilisateur:42:nom, facilite le regroupement logique des données.

Scénario 1 : une couche de cache

L'usage le plus courant de Redis est de stocker le résultat de requêtes ou de calculs coûteux. La logique est toujours la même : consulter d'abord Redis et renvoyer la valeur si elle existe ; sinon, calculer à partir de la base, l'écrire dans Redis et la renvoyer. Avec Laravel, ce schéma se résume à une seule ligne, car dès que vous choisissez Redis comme driver de cache, toute l'API Cache s'appuie sur Redis en coulisses :

# .env
CACHE_STORE=redis
REDIS_HOST=127.0.0.1
REDIS_PORT=6379

use Illuminate\Support\Facades\Cache;

$populaires = Cache::remember('projets:populaires', now()->addHour(), function () {
    return Project::where('is_published', true)
        ->orderByDesc('views')
        ->take(10)
        ->get();
});

Cette approche transforme une requête lourde qui frappait la base à chaque chargement de page en une requête exécutée une fois par heure. Pour l'invalider au bon moment, on utilise Cache::forget('projets:populaires') ; lier cette ligne aux événements du modèle lorsque le contenu change est la solution la plus propre.

Scénario 2 : un magasin de sessions

Sur de petits projets mono-serveur, conserver les sessions dans des fichiers ne pose pas de problème. Mais dès que plusieurs serveurs tournent derrière un répartiteur de charge, un utilisateur peut tomber sur le serveur A à une requête et sur le serveur B à la suivante ; les sessions sur fichier le déconnectent alors sans cesse. Redis résout ce problème à la racine en tant que magasin de sessions centralisé et partagé :

# .env
SESSION_DRIVER=redis

Désormais, tous les serveurs lisent les sessions depuis la même instance Redis ; l'utilisateur reste connecté quel que soit le serveur sur lequel il atterrit. La même logique s'applique aux données du panier, aux jetons « se souvenir de moi » et aux états temporaires de l'utilisateur. Comme les sessions ont naturellement un TTL, l'expiration automatique de Redis tombe parfaitement à propos.

Scénario 3 : files d'attente et tâches en arrière-plan

Des tâches comme l'envoi d'un e-mail, le redimensionnement d'une image ou la génération d'un rapport ne doivent pas faire attendre l'utilisateur. La solution consiste à pousser ces tâches dans une file d'attente et à les traiter en arrière-plan, et Redis est un excellent courtier pour cela, car sa structure de liste se comporte comme une file naturelle. Avec Laravel, la configuration est là encore simple :

# .env
QUEUE_CONNECTION=redis

// Pousse la tâche dans la file — la requête revient aussitôt
SendWelcomeEmail::dispatch($user);

// Lance le worker sur le serveur
php artisan queue:work redis --tries=3

Ici, l'appel dispatch ajoute la tâche à une liste Redis et termine la requête instantanément ; le worker queue:work en arrière-plan retire les tâches de la liste une à une et les exécute. Avec --tries=3, les tâches échouées sont retentées plusieurs fois. Ce schéma accélère l'expérience utilisateur tout en étalant la charge serveur dans le temps.

Points de vigilance en production

Redis est puissant, mais il peut surprendre en cas de mauvais usage. Quelques règles pratiques :

• Surveillez la mémoire. Redis vit en RAM ; si vous écrivez des clés sans limite, la mémoire se remplit. Définissez maxmemory et une politique d'éviction (comme allkeys-lru).
• Prenez l'habitude de fixer un TTL. Les clés de cache écrites sans expiration finissent par s'accumuler comme des déchets.
• Clarifiez vos besoins de durabilité. Si vous l'utilisez seulement comme cache, la perte de données est sans gravité ; pour les sessions et les files, activer la persistance AOF est le choix prudent.
• Verrouillez l'accès. Ne laissez pas Redis exposé au monde extérieur ; bind 127.0.0.1 et un mot de passe (requirepass) sont des mesures de sécurité de base.

Questions fréquentes

Quelle est la différence entre Redis et Memcached ?

Memcached ne fait que du cache clé-valeur simple. Redis ajoute des structures de données comme les listes, ensembles, hash et ensembles triés, ainsi que la persistance, la réplication et les schémas de file/publication-abonnement. Pour du cache jetable, les deux conviennent ; si vous avez besoin de plus, Redis est bien plus flexible.

Les données Redis sont-elles persistantes ou perdues au redémarrage ?

Par défaut, elles vivent en mémoire, mais des options de persistance existent. RDB prend des instantanés disque périodiques, tandis que AOF écrit chaque opération dans un journal. En utilisant les deux, vous pouvez restaurer les données au redémarrage ; dans un scénario de cache pur, les désactiver est aussi une option.

Redis est-il indispensable pour un petit projet ?

Non. Sur un site mono-serveur à faible trafic, le cache fichier et les sessions fichier suffisent largement. Passer à Redis devient pertinent dès que vous avez plusieurs serveurs, un fort trafic, des compteurs en temps réel ou un besoin de files d'attente.

Vous voulez accélérer votre projet avec Redis ? Mesurons ensemble les goulets d'étranglement de votre application web et mettons en place la bonne configuration Redis pour le cache, les sessions et les files — contactez-moi.