Après passage à deux serveurs web, les utilisateurs se déconnectent aléatoirement. La cause : un Redis unique configuré en maxmemory-policy allkeys-lru, où le cache évince les clés session:* sous charge. L'équipe avait « ajouté Redis » sans choisir quel rôle il joue dans l'architecture.
Ce scénario se répète dès qu'un outil efficace est déployé comme solution générique. Redis est un moteur en mémoire polyvalent — pas un produit unique avec un mode par défaut. Cache, stockage de sessions et courtier de messages partagent le protocole, mais pas les exigences de durabilité ni d'éviction.
Redis accélère ce que vous avez décidé de mettre en mémoire. Mal configuré, il accélère aussi vos incidents : déconnexions massives, emails jamais envoyés, données obsolètes servies pendant des heures. La question préalable n'est donc pas « faut-il Redis ? » mais « quel métier Redis doit-il assurer — et avec quelles règles si la mémoire sature ? »
Trois usages — trois contrats
Chaque usage impose un contrat différent entre volatilité, éviction et persistence.
| Usage | Volatilité OK | Éviction | Persistence |
|---|---|---|---|
| Cache objet | Oui | LRU/LFU souvent | Non |
| Session utilisateur | Non | noeviction ou instance dédiée | AOF recommandé |
| File d'attente | Non | noeviction | AOF + acquittement workers |
Cache — résultats de requêtes SQL, fragments HTML, compteurs de limitation de débit. Recalculable si disparu.
Sessions — panier, connexion PHP/Laravel/Symfony, liste noire de jetons. Disparition = expérience catastrophique.
File d'attente — Laravel Horizon, Sidekiq, Bull : emails, miniatures. Perte = messages jamais partis.
Un Redis qui évince des sessions pour libérer de la place pour du cache est un bug d'architecture, pas un réglage fin.
Patterns d'intégration
PHP/Laravel — configurez SESSION_DRIVER=redis et CACHE_DRIVER=redis avec deux connexions distinctes et des préfixes séparés (app_session:, app_cache:).
Node — utilisez connect-redis pour express-session et ioredis pour le cache avec un TTL explicite sur chaque clé.
Workers — placez les consommateurs sur des processus séparés du web ; même Redis pour la file, montée en charge horizontale des workers.
TTL cache — définissez toujours une durée de vie ; évitez les clés orphelines sans expiration.
Pour la couche SQL sous-jacente, voir MySQL pour site dynamique. Si vous hésitez entre hébergement managé et serveur dédié, le guide PaaS ou serveur aide à situer Redis dans l'ensemble.
Dimensionnement et haute disponibilité
Dimensionnez la RAM : taille du jeu de données plus vingt à trente pour cent de marge, en incluant les pics de file d'attente. Pas de swap sur Redis — la latence devient explosive. Pour des sessions critiques multi-nœuds, envisagez Redis Sentinel ou une offre managée (ElastiCache, Scaleway, OVH). Sauvegardez les files avec AOF ; le cache peut se reconstruire.
Comparez les offres Redis managées dans notre annuaire.
Erreurs fréquentes
Redis exposé sur Internet — port 6379 sans authentification mène souvent au minage de cryptomonnaie.
Clés sans espace de noms — collision entre préproduction et production.
*KEYS en production** — bloque le serveur entier.
Cache sans invalidation — données obsolètes après mise à jour métier.
File sans file morte — jobs perdus silencieusement.
Le sommet : Redis accélère — il ne corrige pas
Profilez SQL et sessions avant d'acheter quatre gigaoctets de Redis managé. Mesurez aussi le taux d'éviction après une semaine de charge réelle : un cache qui expulse des clés utiles chaque heure signale souvent un dimensionnement mémoire insuffisant ou une politique d'éviction mal choisie pour le rôle assigné.
Décider et avancer sans angle mort
Identifiez d'abord le besoin réel — session multi-serveur, cache objet, file d'attente, ou combinaison — puis séparez les instances et les politiques d'éviction par rôle. Configurez l'authentification, liez Redis au réseau privé et refusez toute exposition publique. Surveillez la mémoire et les évictions, et documentez les règles d'invalidation du cache métier avant de considérer l'architecture comme stable.
Questions fréquentes
Redis obligatoire pour accélérer mon site ?
Non. Commencez par le cache HTTP, OPcache et les requêtes SQL optimisées. Redis devient pertinent quand vous avez besoin de sessions partagées multi-serveur, d'un cache objet lourd ou de files d'attente asynchrones.
Cache et session sur le même Redis ?
Déconseillé en production : la politique d'éviction du cache peut expulser les clés de session. Séparez les instances ou les bases logiques avec des politiques adaptées.
Faut-il activer la persistence Redis ?
Pour un cache pur, souvent non. Pour les sessions ou les files d'attente, oui : AOF ou Redis managé avec sauvegarde.
Redis managé ou sur le VPS ?
Choisissez le managé si la haute disponibilité, les sauvegardes et les correctifs de sécurité dépassent vos compétences. Un VPS convient pour un trafic modeste avec surveillance mémoire stricte.
Redis : choisissez d'abord quel métier — cache, session ou file — avant d'installer une instance fourre-tout.