Erfolgreiche Migration: vier PHP-FPM-Knoten hinter einem Load Balancer, Sitzungen in Redis, Bereitstellungen ohne massive Verbindungsabbrüche. Ausfall des Redis-Netzwerks an einem Dienstag um 11 Uhr: 100 % der Benutzer kehrten zur Verbindung zurück, Einkaufswagen wurden geleert, Support-Tickets verdoppelt. Die Überwachung alarmierte den PHP-Prozessor – nicht den Redis-Speicher oder verweigerte Verbindungen.
Dieses Szenario veranschaulicht die klassische Skalierung: Redis für Sitzungen löst die horizontale Skalierung auf, erstellt jedoch eine kritische Abhängigkeit, wenn es als „Wegwerf-Cache“ behandelt wird. Die Sitzung ist keine neu berechenbare HTML-Seite – es ist der aktuelle Benutzerstatus: Warenkorb, starker Authentifizierungsschritt, mehrseitiger Assistent.
Teams, die ohne Wiederherstellungsplan zu Redis migrieren, stellen häufig fest, dass ihr Dashboard die PHP-CPU überwacht, nicht den Redis-Speicher oder abgelehnte Verbindungen. Ein Redis-Fehler macht sich jedoch zunächst durch 500 Verbindungsfehler bemerkbar, nicht durch eine Warnung, dass die Festplatte voll ist.
Viele Teams entdecken das Problem am Tag des ersten Redis-Ausfalls, nicht am Tag der Migration. Vor dem Hinzufügen von Redis stellt sich nicht nur die Frage: „Wie konfiguriere ich PHP?“ » aber „Was passiert, wenn Redis für fünf Minuten verschwindet – und wer wird alarmiert? »
Die Antwort muss wie folgt lauten: Sentinel-Failover, Wiederherstellung von AOF oder explizite Wartungsseite. Ohne ein Verfahren wird der Redis-Ausfall zu einem totalen Geschäftsausfall – verlorene Einkaufswagen, unterbrochene starke Authentifizierung, gesättigter Support in wenigen Minuten.
Gesunde Architektur
| Komponente | Empfehlung |
|---|---|
| Instanz | Dedizierte Redis-Sitzungen oder Basis „1“, getrennt vom Cache |
| Beharrlichkeit | AOF zur Genesung; Sitzungen haben sowieso eine TTL |
| HA | Sentinel (3 Knoten) oder Redis-Cluster bei hoher Auslastung |
| Netzwerk | Privates Netzwerk, nicht Redis im öffentlichen Internet |
| PHP | session.save_handler=redis, session.save_path=tcp://... |
Beispielhafte PHP-Konfiguration:
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379?database=1&timeout=2&prefix=sess:"
session.gc_maxlifetime = 3600
Kurze Verzögerung bei der Redis-Verbindung – besser schnell scheitern, als PHP-FPM dreißig Sekunden lang zu blockieren.
Redis-Cache vs. Redis-Sitzungen: nicht mischen
| Verwendung | TTL | Räumung |
|---|---|---|
| App-Cache | Variiert | allkeys-lru akzeptabel |
| Sitzungen | Laufende Benutzeraktivität | volatile-lru oder noeviction |
Ein versehentliches „FLUSHDB“ im gemeinsam genutzten Cache führt zu einer globalen Verbindungsunterbrechung. Separate Instanzen oder zumindest Basisindizes.
Fallback: Hoffen vs. Planen
Realistische Optionen:
- Redis-Hochverfügbarkeit – Hauptmodell.
- Dateien falten, wenn Redis nicht verfügbar ist – unterbricht den Ausgleich ohne Affinität; in einem kurzen Notfall akzeptabel.
- Überwachte Verschlechterung – Melden Sie sich auf der Wartungsseite an, wenn die Redis-Gesundheitsprüfung fehlschlägt.
Versprechen Sie kein „transparentes Datei-Fallback“ über vier Knoten ohne Sitzungsaffinität.
Überwachung
Überwachen Sie „connected_clients“, „used_memory“, „rejected_connections“. Messen Sie die Latenz mit „redis-cli --latency“. Warnung, wenn der Meister fällt (Sentinel). Korrelieren Sie 5xx-Fehlerspitzen bei der Verbindung mit dem Redis-Status.
Hosting-Seite: Managed Redis (OVH, Scaleway) oder dedizierter Container auf VPS – nicht Redis auf derselben virtuellen Maschine wie PHP ohne strenge Speicherbeschränkungen. Siehe auch Redis oder Memcached und Verbindungspool.
Planen Sie außerdem eine Wiederherstellungsübung: Stoppen Sie Redis in der Vorproduktion, messen Sie die Zeit bis zur Wiederherstellung des Dienstes und stellen Sie sicher, dass das Team weiß, wer den Sentinel-Wechsel auslöst. Ohne diese Übung bleibt Hochverfügbarkeit eine Linie in einem Architekturdiagramm.
Oben: Die Redis-Sitzung ist kein Cache, sondern der Benutzerspeicher
Vor Redis-Sitzungen: Testen Sie das Stoppen von Redis in der Vorproduktion und messen Sie die Auswirkungen. Nachher: Dokumentieren Sie einen Wiederherstellungsvorgang in weniger als fünfzehn Minuten oder einen getesteten Sentinel-Failover – ohne Dokumentation wird der Ausfall zu einer Krise.
Entscheide dich und gehe ohne blinden Fleck voran
Reservieren Sie eine für Sitzungen dedizierte Instanz, richten Sie Sentinel oder verwaltetes Redis mit hoher Verfügbarkeit vor der Produktion mit mehreren Knoten ein und integrieren Sie eine Anwendungszustandsprüfung mit Redis-Warnungen. Testen Sie vierteljährlich einen simulierten Ausfall und verbieten Sie jegliches „FLUSH“ ohne schriftliches Verfahren – Massenabschaltungen erfolgen oft als administrative Geste und nicht als Angriff.
Häufig gestellte Fragen
Ist Redis für PHP-Sitzungen geeignet?
Ja – niedrige Latenz, natives TTL, gemeinsame Nutzung zwischen PHP-Knoten. Bevorzugen Sie eine dedizierte Instanz für Sitzungen oder einen separaten Basisindex, anstatt Cache und Sitzungen auf denselben Schlüsseln zu mischen.
Was passiert, wenn Redis nicht verfügbar ist?
Standardmäßig massive Verbindungsunterbrechung. Planen Sie Sentinel-, Cluster-, AOF-Persistenz oder einen dokumentierten Fallback mit seinen Einschränkungen.
Sollten Sitzungen in Redis verschlüsselt werden?
Wenn die Daten vertraulich sind, verschlüsseln Sie sie auf der Anwendungsseite und verwenden Sie ein privates Netzwerk mit minimaler ACL.
Redis-Sitzungen vs. Sticky-Sitzung?
Redis erlaubt PHP ohne lokalen Status; Die Affinität allein ist bei der erneuten Bereitstellung eines Knotens fragil.
Redis-Sitzungen skalieren Ihr PHP – solange Sie den Benutzerstatus nicht als verfügbaren Cache behandeln.