Caching in Anwendungen: Ablaufzeiten, Invalidierung und Schutz vor dem Ansturm

Worum es geht

Beim Muster «Cache-aside» fragt die Anwendung zuerst den Cache; bei einem Fehltreffer liest sie die Quelle, legt das Ergebnis mit Ablaufzeit ab und liefert es aus. Redis dokumentiert die Bausteine: EXPIRE setzt eine Frist, nach deren Ablauf der Schlüssel automatisch gelöscht wird, und SET mit der Option NX schreibt nur, wenn der Schlüssel noch nicht existiert – die Grundlage für eine einfache Sperre. Auf HTTP-Ebene regelt RFC 9111 mit max-age dasselbe Prinzip einer begrenzten Frische; Anwendungs-Caches folgen keiner Norm, ihre Regeln legt man selbst fest.

Warum es wichtig ist

Ein Cache senkt Last und Latenz, aber ein veralteter Eintrag nach einem Schreibvorgang ist ein Korrektheitsfehler, der sich schwer reproduzieren lässt: Er tritt nur im Fenster zwischen Schreiben und Ablauf auf und verschwindet beim Nachstellen. Die Invalidierungsstrategie ist deshalb Teil des Entwurfs, nicht eine Nachbesserung.

So wird es angewendet

• Pro Datenklasse festlegen, wie alt ein Wert sein darf, und die Ablaufzeit danach setzen; eine kurze Frist begrenzt den Schaden jeder vergessenen Invalidierung.
• Beim Schreiben die betroffenen Schlüssel löschen statt überschreiben: Löschen ist idempotent und kann keinen älteren Wert zurücklassen, wenn zwei Schreiber einander überholen. Ein Leser, der zwischen Datenbanklesen und Cache-Schreiben von einem Schreibvorgang überholt wird, kann trotzdem einen veralteten Wert ablegen; dieses Fenster begrenzt nur die Ablaufzeit.
• Eine Versions- oder Schemakennung in den Schlüssel aufnehmen (kunde:v3:123), damit ein Deployment mit neuer Wertstruktur keine alten Einträge liest; die alten laufen von selbst ab.
• Abgeleitete Schlüssel mitdenken: Ändert sich ein Objekt, sind auch Listen, Zähler und Suchergebnisse betroffen, die es enthalten. Entweder deren Schlüssel mit löschen oder ihnen eine kürzere Frist geben.
• Ansturm («Stampede») verhindern: Läuft ein heisser Schlüssel ab, soll nur eine Anfrage die Quelle befragen. Mit SET sperre:<schlüssel> 1 NX EX 5 erhält ein Prozess das Nachladerecht; die anderen warten kurz oder liefern den noch vorhandenen alten Wert aus. Die Redis-Dokumentation nennt SET … NX EX eine einfache Sperre und verweist für fehlertolerante Sperren auf Redlock; für den Ansturmschutz, bei dem ein Fehlschlag nur einen zweiten Nachlader bedeutet, genügt die einfache Form.
• Negative Ergebnisse («nicht gefunden») mit kurzer Frist cachen, wenn viele Anfragen auf fehlende Schlüssel zielen.
• Trefferquote und Quelllast messen; ein Cache ohne Treffer kostet bei jedem Fehltreffer nur zusätzliche Latenz.

Stolpersteine

Nutzerabhängige Daten unter einem gemeinsamen Schlüssel. Den Cache als dauerhaften Speicher behandeln, obwohl ein Neustart ihn leert. Ablaufzeiten, die auf verschiedenen Hosts mit abweichender Uhr gesetzt und geprüft werden. Eine Sperre ohne Ablaufzeit, die nach einem Absturz des nachladenden Prozesses nie mehr freigegeben wird.