Migration réussie : quatre nœuds PHP-FPM derrière un équilibreur de charge, sessions dans Redis, déploiements sans déconnexion massive. Panne réseau Redis un mardi à 11 h : 100 % des utilisateurs renvoyés à la connexion, paniers vidés, tickets support multipliés par deux cents. Le monitoring alertait le processeur PHP — pas la mémoire Redis ni les connexions refusées.
Ce scénario illustre la bascule classique : Redis pour sessions résout le scale horizontal, mais crée une dépendance critique si on le traite comme un « cache jetable ». La session n'est pas une page HTML recalculable — c'est l'état utilisateur en cours : panier, étape d'authentification forte, assistant multi-pages.
Les équipes qui migrent vers Redis sans plan de reprise découvrent souvent que leur tableau de bord surveille le processeur PHP, pas la mémoire Redis ni les connexions refusées. Or une panne Redis se manifeste d'abord par des erreurs 500 à la connexion, pas par une alerte disque saturé.
Beaucoup d'équipes découvrent le problème le jour de la première panne Redis, pas le jour de la migration. Avant d'ajouter Redis, la question n'est pas seulement « comment configurer PHP ? » mais « que se passe-t-il si Redis disparaît cinq minutes — et qui est alerté ? »
La réponse doit être écrite : bascule Sentinel, restauration depuis AOF, ou page de maintenance explicite. Sans procédure, la panne Redis devient une panne métier totale — paniers perdus, authentification forte interrompue, support saturé en quelques minutes.
Architecture saine
| Composant | Recommandation |
|---|---|
| Instance | Redis dédié sessions ou base 1 séparée du cache |
| Persistence | AOF pour reprise ; les sessions ont un TTL de toute façon |
| HA | Sentinel (3 nœuds) ou Redis Cluster si charge élevée |
| Réseau | Réseau privé, pas Redis sur Internet public |
| PHP | session.save_handler=redis, session.save_path=tcp://... |
Configuration PHP illustrative :
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379?database=1&timeout=2&prefix=sess:"
session.gc_maxlifetime = 3600
Délai court sur la connexion Redis — mieux vaut échouer vite que bloquer PHP-FPM trente secondes.
Redis cache vs Redis sessions : ne pas mélanger
| Usage | TTL | Éviction |
|---|---|---|
| Cache app | Variable | allkeys-lru acceptable |
| Sessions | Activité utilisateur glissante | volatile-lru ou noeviction |
Un FLUSHDB accidentel sur cache partagé provoque une déconnexion globale. Séparez instances ou, au minimum, index de base.
Repli : espérer vs planifier
Options réalistes :
- Redis haute disponibilité — modèle principal.
- Repli fichiers si Redis est indisponible — casse l'équilibrage sans affinité ; acceptable en urgence courte.
- Dégradation contrôlée — page de maintenance connexion si le contrôle de santé Redis échoue.
Ne promettez pas un « repli fichiers transparent » sur quatre nœuds sans affinité de session.
Surveillance
Surveillez connected_clients, used_memory, rejected_connections. Mesurez la latence avec redis-cli --latency. Alertez si le maître tombe (Sentinel). Corrélez les pics d'erreurs 5xx à la connexion avec l'état Redis.
Côté hébergement : Redis managé (OVH, Scaleway) ou conteneur dédié sur VPS — pas Redis sur la même machine virtuelle que PHP sans limites mémoire strictes. Voir aussi Redis ou Memcached et Pool de connexions.
Planifiez aussi un exercice de reprise : arrêt Redis en préproduction, mesure du temps avant restauration du service, vérification que l'équipe sait qui déclenche la bascule Sentinel. Sans cet exercice, la haute disponibilité reste une ligne sur un schéma d'architecture.
Le sommet : Redis session n'est pas un cache — c'est de la mémoire utilisateur
Avant Redis sessions : testez l'arrêt de Redis en préproduction et chronométrez l'impact. Après : documentez une procédure de reprise en moins de quinze minutes ou une bascule Sentinel testée — sans document, la panne devient une crise.
Décider et avancer sans angle mort
Réservez une instance dédiée aux sessions, mettez en place Sentinel ou du Redis managé haute disponibilité avant la production multi-nœuds, et branchez un contrôle de santé applicatif avec alerte Redis. Testez une panne simulée chaque trimestre, et interdisez tout FLUSH sans procédure écrite — la déconnexion massive arrive souvent d'un geste administratif, pas d'une attaque.
Questions fréquentes
Redis est-il adapté aux sessions PHP ?
Oui — faible latence, TTL natif, partage entre nœuds PHP. Préférez une instance dédiée aux sessions ou un index de base séparé plutôt que de mélanger cache et sessions sur les mêmes clés.
Que se passe-t-il si Redis est indisponible ?
Par défaut, déconnexion massive. Prévoyez Sentinel, Cluster, persistence AOF ou un repli documenté avec ses limites.
Faut-il chiffrer les sessions dans Redis ?
Si les données sont sensibles, chiffrez côté application et utilisez un réseau privé avec ACL minimum.
Redis sessions vs sticky session ?
Redis permet PHP sans état local ; l'affinité seule est fragile au redéploiement d'un nœud.
Redis sessions scale votre PHP — à condition de ne pas traiter l'état utilisateur comme du cache jetable.