Caching-Strategien: Lazy Loading und Write-Through

Wenn Sie einen Cache zwischen Ihre Anwendung und die Datenbank schalten, benötigen Sie eine Caching-Strategie – eine Reihe von Regeln, die festlegen, wann Daten in den Cache geschrieben, aus dem Cache gelesen und aus dem Cache entfernt werden. Die Wahl der falschen Strategie führt entweder zu veralteten Daten (der Cache gibt überholte Werte zurück), zu Cache Misses bei einem kalten Cache (der Cache ist leer und jede Anfrage greift auf die Datenbank zu) oder zu einem Cache Stampede (viele gleichzeitige Anfragen nach demselben fehlenden Schlüssel greifen gleichzeitig auf die Datenbank zu). Die beiden grundlegenden Strategien sind Lazy Loading und Write-Through.

Lazy Loading (auch Cache-Aside genannt) ist das am häufigsten verwendete Caching-Muster. Die Anwendung prüft zuerst den Cache. Bei einem Cache Hit werden die Daten direkt aus dem Cache zurückgegeben – der schnelle Pfad. Bei einem Cache Miss ruft die Anwendung die Daten aus der Datenbank ab, schreibt das Ergebnis mit einer TTL in den Cache und gibt es an den Aufrufer zurück. Der Cache wird nur mit tatsächlich angeforderten Daten gefüllt – daher „lazy“. Bei der nächsten Anfrage nach demselben Schlüssel befinden sich die Daten im Cache.

Lazy Loading bietet drei wesentliche Vorteile: Nur angeforderte Daten werden zwischengespeichert – der Cache wird nicht mit Daten gefüllt, die niemand liest, sodass der Speicher effizient genutzt wird. Ein kalter Cache legt die Anwendung nicht lahm – bei Cache Misses greift die Anwendung auf die Datenbank zurück. Selbst wenn ElastiCache neu gestartet wird oder ein Knoten ausfällt, funktioniert die Anwendung daher weiterhin, wenn auch mit höherer Latenz. Der Cache ist mit der Datenbank immer letztendlich konsistent, da veraltete Daten über die TTL ablaufen, selbst wenn Aktualisierungen übersehen wurden.

Lazy Loading hat drei wesentliche Nachteile: Cache Misses sind kostspielig – im Vergleich zu einem Cache Hit sind drei Vorgänge erforderlich (Cache-Prüfung, Datenbanklesevorgang und Schreiben in den Cache), was bei kalten Anfragen zu höherer Latenz führt. Veraltete Daten – nach einer Aktualisierung der Datenbank liefert der Cache weiterhin den alten Wert, bis die TTL abläuft oder der Schlüssel explizit invalidiert wird (Konsistenzfenster des Caches). Cache Stampede – wenn ein häufig verwendeter Schlüssel abläuft, erleben viele gleichzeitige Anfragen einen Cache Miss und greifen gleichzeitig auf die Datenbank zu, was diese möglicherweise überlastet.

Bei der Write-Through-Strategie wird jeder Schreibvorgang in der Datenbank gleichzeitig auch im Cache ausgeführt. Die Anwendung schreibt den Wert im Rahmen desselben Vorgangs sowohl in den Cache als auch in die Datenbank (oder die Datenbank löst eine Aktualisierung des Caches aus). Der Cache ist dadurch immer mit der Datenbank synchron – es gibt kein Zeitfenster mit veralteten Daten. Write-Through stellt sicher, dass die Daten im Cache immer aktuell sind, sodass nachfolgende Lesevorgänge für kürzlich geschriebene Daten stets Cache Hits sind.

Vorteile von Write-Through: Cache-Daten sind immer aktuell – es gibt keine veralteten Daten, da der Cache bei jedem Schreibvorgang aktualisiert wird. Lesevorgänge sind immer schnell – häufig verwendete Daten, die regelmäßig geschrieben werden, befinden sich stets im Cache. Kein Cache Stampede bei Lesevorgängen – da die Daten vor dem Lesen vorab im Cache gespeichert werden, gibt es für kürzlich geschriebene Daten keine Cache Misses bei einem kalten Cache. Diese Strategie eignet sich ideal für leseintensive Workloads mit häufigen Aktualisierungen, bei denen die Aktualität der Daten entscheidend ist, beispielsweise für Produktkataloge, Preissysteme oder Caches für Benutzerprofile.

Nachteile von Write-Through: Schreib-Overhead – jeder Schreibvorgang umfasst zwei Operationen (Datenbank und Cache), wodurch sich die Latenz von Schreibvorgängen erhöht. Cache-Verschmutzung – Daten werden auch dann zwischengespeichert, wenn sie nie wieder gelesen werden (einmal geschrieben, nie angefordert), wodurch Cache-Speicher verschwendet wird. Ein Neustart des Caches führt zu einem kalten Cache – beim Neustart des Cache-Clusters gehen alle proaktiv geschriebenen Daten verloren, und der Cache muss durch Schreibvorgänge oder einen Cache-Warm-up-Prozess neu gefüllt werden. Kombinieren Sie Write-Through mit einer TTL, um ein unbeschränktes Wachstum selten gelesener Cache-Daten zu verhindern.

In der Praxis kombinieren viele Produktionssysteme beide Strategien: Verwenden Sie Write-Through für häufig aktualisierte und häufig gelesene Daten (beispielsweise Benutzersitzungen oder aktuelle Preise) und Lazy Loading für selten aktualisierte, aber häufig gelesene Daten (beispielsweise Produktbeschreibungen oder Artikelinhalte). Legen Sie für beide geeignete TTLs fest: Write-Through-Schlüssel erhalten eine lange TTL, da die Daten stets aktuell sind; Lazy-Loading-Schlüssel erhalten eine kürzere TTL, um das Zeitfenster für veraltete Daten zu begrenzen. Dieser hybride Ansatz maximiert die Cache-Trefferquote und minimiert gleichzeitig die Veraltung der Daten.

Die Time-to-Live (TTL) zwischengespeicherter Daten bestimmt das maximale Zeitfenster für veraltete Daten und den Speicherbedarf des Caches. Legen Sie TTLs anhand der folgenden Kriterien fest: Häufigkeit der Datenaktualisierung (Sitzungsdaten ändern sich häufig → kurze TTL; statische Inhalte ändern sich selten → lange TTL), Toleranz gegenüber veralteten Daten (Finanzkurse → sehr kurz; Blogbeitragstexte → Stunden oder Tage) und verfügbare Cache-Kapazität (wenig Speicher → kürzere TTL, damit veraltete Daten schneller entfernt werden). Legen Sie immer eine TTL fest – speichern Sie Daten niemals ohne Ablaufzeit zwischen, da sich der Cache sonst letztendlich mit veralteten Daten füllt.

Statt sich ausschließlich auf den Ablauf der TTL zu verlassen, können Sie Cache-Schlüssel explizit invalidieren (löschen), wenn sich die zugrunde liegenden Daten ändern. Dadurch wird das Zeitfenster für veraltete Daten vollständig beseitigt. Häufige Muster sind: Delete-on-Write (den Cache-Schlüssel nach jeder Datenbankaktualisierung löschen – der nächste Lesevorgang füllt ihn über Lazy Loading erneut) und ereignisgesteuerte Invalidierung (DynamoDB Streams oder die Änderungsaufzeichnung von RDS lösen eine Lambda-Funktion aus, die betroffene Schlüssel löscht). Die Cache-Invalidierung gehört zu den schwierigsten Problemen in verteilten Systemen; je einfacher die Invalidierungslogik ist, desto zuverlässiger ist Ihr Cache.

Ein weniger verbreitetes, aber leistungsfähiges Muster ist Write-Behind (Write-Back): Die Anwendung schreibt nur in den Cache, und der Cache überträgt die Daten asynchron im Hintergrund in die Datenbank. Dies ermöglicht extrem schnelle Schreibvorgänge (ausschließlich im Arbeitsspeicher), birgt jedoch das Risiko eines Datenverlusts, wenn der Cache vor der Übertragung ausfällt. Write-Behind eignet sich für Schreibvorgänge mit hoher Frequenz und hohem Volumen, bei denen die Daten rekonstruiert werden können oder kleine Verluste akzeptabel sind – beispielsweise für Trefferzähler, Analyseereignisse oder Aktualisierungen von Spielepunktständen. ElastiCache unterstützt Write-Behind nicht nativ; das Muster muss auf Anwendungsebene implementiert werden.

Testen Sie Ihr Verständnis der Konzepte aus dieser Lektion für AWS Solutions Architect (SAA-C03).

In dieser Lektion haben Sie gelernt: Lazy Loading füllt den Cache bei Lesevorgängen nach Cache Misses und nutzt den Speicher effizient, kann jedoch bis zum Ablauf der TTL veraltete Daten liefern. Write-Through aktualisiert den Cache bei jedem Schreibvorgang und verhindert veraltete Daten, verschwendet jedoch Speicher für ungelesene Daten. Eine explizite Invalidierung löscht Cache-Schlüssel bei Aktualisierungen der Datenbank und beseitigt dadurch Zeitfenster mit veralteten Daten. Als Nächstes untersuchen wir Muster für Sitzungsspeicher und Bestenlisten mit ElastiCache.