Succesvolle migratie: vier PHP-FPM-nodes achter een load balancer, sessies in Redis, implementaties zonder enorme ontkoppelingen. Redis-netwerkstoring op dinsdag om 11.00 uur: 100% van de gebruikers keerde terug naar de verbinding, winkelwagentjes werden geleegd, supporttickets vermenigvuldigd met tweehonderd. Monitoring heeft de PHP-processor gewaarschuwd – niet het Redis-geheugen of geweigerde verbindingen.
Dit scenario illustreert de klassieke schaling: Redis for Sessions lost horizontale schaling op, maar creëert een kritieke afhankelijkheid als deze wordt behandeld als een "wegwerpcache". De sessie is geen herberekenbare HTML-pagina; het is de huidige gebruikersstatus: winkelwagentje, sterke authenticatiestap, wizard met meerdere pagina's.
Teams die zonder herstelplan naar Redis migreren, ontdekken vaak dat hun dashboard de PHP-CPU controleert, en niet het Redis-geheugen of geweigerde verbindingen. Een Redis-fout manifesteert zich echter eerst door 500 fouten bij de verbinding, en niet door een waarschuwing dat de schijf vol is.
Veel teams ontdekken het probleem op de dag van de eerste Redis-storing, niet op de dag van de migratie. Voordat Redis wordt toegevoegd, is de vraag niet alleen "hoe PHP configureren?" » maar “wat gebeurt er als Redis vijf minuten verdwijnt – en wie wordt gewaarschuwd? »
Het antwoord moet worden geschreven: Sentinel-schakelaar, herstel van AOF of expliciete onderhoudspagina. Zonder procedure wordt de Redis-storing een totale bedrijfsstoring: verloren winkelwagentjes, sterke authenticatie onderbroken, ondersteuning binnen een paar minuten verzadigd.
Gezonde architectuur
| Onderdeel | Aanbeveling |
|---|---|
| Instantie | Toegewijde Redis-sessies of basis 1 gescheiden van de cache |
| Volharding | AOF voor herstel; sessies hebben sowieso een TTL |
| HAA | Sentinel (3 knooppunten) of Redis Cluster bij hoge belasting |
| Netwerk | Privénetwerk, niet Redis op het openbare internet |
| PHP | session.save_handler=redis, session.save_path=tcp://... |
Illustratieve PHP-configuratie:
session.save_handler = opnieuw indienen
session.save_path = "tcp://127.0.0.1:6379?database=1&timeout=2&prefix=sess:"
sessie.gc_maxlifetime = 3600
Korte vertraging op Redis-verbinding — het is beter om snel te falen dan PHP-FPM dertig seconden te blokkeren.
Redis-cache versus Redis-sessies: niet combineren
| Gebruik | TTL | Uitzetting |
|---|---|---|
| App-cache | Varieert | allkeys-lru acceptabel |
| Sessies | Rollende gebruikersactiviteit | vluchtige-lru of geen uitzetting |
Een onbedoelde FLUSHDB op de gedeelde cache veroorzaakt een globale ontkoppeling. Afzonderlijke instanties of, op zijn minst, basisindexen.
Terugval: hopen versus plannen
Realistische opties:
- Redis hoge beschikbaarheid — hoofdmodel.
- Bestanden vouwen als Redis niet beschikbaar is — verbreekt de balans zonder affiniteit; aanvaardbaar in een korte noodsituatie.
- Bewaakte degradatie: onderhoudspagina voor inloggen als de Redis-statuscontrole mislukt.
Beloof geen "transparante bestandsterugval" over vier knooppunten zonder sessieaffiniteit.
Toezicht
Monitor connected_clients, used_memory, rejected_connections. Meet de latentie met redis-cli --latency. Waarschuw als de meester valt (Sentinel). Correleer 5xx-foutpieken bij verbinding met Redis-status.
Hostingkant: Managed Redis (OVH, Scaleway) of speciale container op VPS – niet Redis op dezelfde virtuele machine als PHP zonder strikte geheugenlimieten. Zie ook Redis of Memcached en Verbindingspool.
Plan ook een hersteloefening: Redis stoppen in pre-productie, de tijd meten voordat de service wordt hersteld, verifiëren dat het team weet wie de Sentinel-schakelaar activeert. Zonder deze oefening blijft hoge beschikbaarheid een lijn op een architectonisch diagram.
Bovenkant: Redis-sessie is geen cache, het is gebruikersgeheugen
Vóór Redis-sessies: test het stoppen van Redis in pre-productie en time de impact. Daarna: Documenteer een herstelprocedure in minder dan vijftien minuten of een geteste Sentinel-failover – zonder documentatie wordt de storing een crisis.
Beslis en ga vooruit zonder blinde vlek
Reserveer een exemplaar speciaal voor sessies, stel Sentinel of beheerde Redis met hoge beschikbaarheid in vóór productie met meerdere knooppunten, en sluit een applicatiestatuscheck aan met Redis-waarschuwingen. Test elk kwartaal een gesimuleerde uitval en verbied elke 'FLUSH' zonder schriftelijke procedure. Het massaal verbreken van de verbinding gebeurt vaak als een administratief gebaar en niet als een aanval.
Veelgestelde vragen
Is Redis geschikt voor PHP-sessies?
Ja – lage latentie, native TTL, delen tussen PHP-nodes. Geef de voorkeur aan een speciaal exemplaar voor sessies of een afzonderlijke basisindex in plaats van cache en sessies op dezelfde sleutels te combineren.
Wat gebeurt er als Redis niet beschikbaar is?
Standaard een enorme ontkoppeling. Plan voor Sentinel-, Cluster-, AOF-persistentie of een gedocumenteerde terugval met zijn beperkingen.
Moeten sessies worden gecodeerd in Redis?
Als de gegevens gevoelig zijn, versleutel dan aan de applicatiezijde en gebruik een particulier netwerk met minimale ACL.
Redis-sessies versus sticky-sessie?
Redis staat PHP toe zonder lokale status; affiniteit alleen is kwetsbaar bij het opnieuw inzetten van een knooppunt.
Redis-sessies schalen uw PHP, zolang u de gebruikersstatus niet als wegwerpcache beschouwt.