Caching-Strategien

Kurz: Ein Cache speichert Ergebnisse, damit man sie nicht jedes Mal neu berechnen oder laden muss. Das macht Anwendungen schneller und günstiger. Schwierig ist, veraltete Daten rechtzeitig loszuwerden.

Wo gecacht wird

1. Browser: Dateien und Antworten lokal speichern (Cache-Control-Header).
2. CDN: Kopien nahe beim Nutzer weltweit.
3. Server/Anwendung: häufige Ergebnisse im Arbeitsspeicher (z. B. Redis, memoization: Memoization).
4. Datenbank: Zwischenspeicher für Seiten und Abfragen.
5. CPU: Zwischenspeicher im Prozessor (Caches).

Muster

• Cache-Aside: Anwendung schaut erst in den Cache, bei Fehlschlag in die Datenbank und legt das Ergebnis ab. Am häufigsten.
• Write-Through: Schreiben geht in Cache und Datenbank gleichzeitig. Konsistent, etwas langsamer.
• Write-Back: zuerst nur in den Cache, später gesammelt in die Datenbank. Schnell, aber bei Absturz droht Verlust.

Das schwere Problem: Invalidierung

„Es gibt nur zwei schwere Dinge in der Informatik: Cache-Invalidierung und Dinge benennen.“ Wege:

• TTL (Time to live): Eintrag läuft nach X Sekunden ab. Einfach, aber zeitweise veraltet.
• Gezielt löschen, wenn sich Daten ändern (Cache-Tags, siehe Cache Tags und revalidateTag (Next.js)).
• Versionierte Namen für Dateien (app.4f3a.js), die nie veralten.

Fallen

1. Cache Stampede: Viele Anfragen holen gleichzeitig denselben abgelaufenen Wert. Abhilfe: Sperren oder etwas früher still erneuern.
2. Zu große Caches verdrängen Wichtiges (Speicherverwaltung und OOM-Killer).
3. Persönliche Daten gehören nicht in gemeinsam genutzte Caches.

Siehe auch: Skalierung