Redis noeviction: Wenn Schreibvorgänge stoppen
„maxmemory-policy noeviction“ wirkte sicher. Kein Datenverlust, oder?
Was passiert ist:
- Redis erreichte sein maxmemory-Limit
- noeviction-Policy: Redis blieb oben, lehnte aber jeden Schreibvorgang mit „OOM command not allowed when used memory > 'maxmemory'“ ab — kein Crash, nur Absagen
- Die Anwendung konnte keine neuen Cache-Einträge schreiben
- Aber sie konnte auch keine Session-Daten schreiben
- Nutzer wurden mitten in der Transaktion ausgeloggt
- Zahlungsfehler schossen um 400% in die Höhe
Das eigentliche Problem:
Wir speicherten wegwerfbaren Cache UND kritische Session-Daten in derselben Redis-Instanz mit derselben Eviction-Policy. Jede der beiden Policy-Optionen opfert einen Workload: Eviction wirft lebende Sessions weg, noeviction blockiert den Cache. (Wir hatten bereits auf die harte Tour gelernt, dass Sessions in Redis eigene Betriebsregeln brauchen.)
Die Lösung:
- Getrennte Redis-Instanzen für Cache und Sessions
- Cache: allkeys-lru (bei vollem Speicher die ältesten Einträge verdrängen)
- Sessions: noeviction + aggressive TTLs + Monitoring
- Alerts, sobald der Speicher 80% erreicht
Lektion: Ihre Eviction-Policy sollte zur Wichtigkeit Ihrer Daten passen. Wegwerfbarer Cache und kritische Sessions brauchen unterschiedliche Strategien.
Incidents wie dieser sind vermeidbar. Unser AWS Managed Services-Team überwacht Kundenumgebungen 24/7 mit KI-gestütztem Monitoring und Senior Engineers am Pager — damit Geschichten wie diese im Archiv bleiben.