Anwendungs-Caches: Cache-Aside, TTLs und Invalidierung

Worum es geht

Cache-Aside (Lazy Loading): Die Anwendung sucht einen Schlüssel im Cache; bei einem Miss liest sie aus der massgeblichen Quelle, speichert den Wert mit einer Time-to-Live und gibt ihn zurück. Schreibvorgänge gehen an die Quelle und löschen entweder den Cache-Eintrag (Invalidierung) oder überschreiben ihn (Write-Through). Der Cache enthält abgeleitete Daten und kann jederzeit verloren gehen.

Warum es wichtig ist

Caches reduzieren Last und Latenz, aber ein veralteter Eintrag, der nach einem Schreibvorgang ausgeliefert wird, ist ein Korrektheitsfehler, der sich schwer reproduzieren lässt. Die Invalidierungsstrategie ist eine Designentscheidung, kein nachträglicher Gedanke.

So wird es angewendet

• Die zulässige Veraltung je Datenklasse festlegen und TTLs entsprechend setzen; eine kurze TTL ist eine einfache Obergrenze für den möglichen Schaden.
• Bei einem Schreibvorgang die betroffenen Schlüssel löschen statt sie zu aktualisieren; das Löschen ist idempotent und vermeidet Race Conditions zwischen gleichzeitigen Schreibern.
• Eine Versions- oder Schema-Kennung in den Schlüssel aufnehmen (user:v3:123), damit Deployments, die die Form des Werts ändern, keine alten Einträge lesen.
• Gegen Stampedes schützen: Bei einem Miss auf einen stark gefragten Schlüssel nur eine Anfrage den Cache befüllen lassen, während andere kurz warten oder leicht veraltete Daten erhalten.
• Negative Ergebnisse ("nicht gefunden") mit einer kurzen TTL cachen, wenn Abfragen nach fehlenden Schlüsseln häufig vorkommen.
• Trefferquote und Last auf der Quelle messen; ein Cache, der nie getroffen wird, kostet bei jedem Miss zusätzliche Latenz.

Stolpersteine

Nutzerspezifische Daten unter einem gemeinsamen Schlüssel cachen. Eine Invalidierung, die abgeleitete Schlüssel (Listen, Zähler) nicht erfasst, wenn sich ein einzelnes Objekt ändert. Den Cache als dauerhaften Speicher behandeln. Uhrenabweichung zwischen den Hosts, die die TTL setzen, und denen, die sie prüfen.

Das Wettrennen zwischen Löschen und Neubefüllen

Delete-on-Write ist nicht frei von Race Conditions: Ein Leser kann den alten Wert kurz vor dem Commit eines Schreibvorgangs aus der Quelle laden und ihn nach dem Löschen durch den Schreiber im Cache ablegen, sodass bis zum Ablauf veraltete Daten stehen bleiben. Den Schaden mit kurzen TTLs begrenzen, oder das Rennen durch Versionierung der Schlüssel vermeiden (eine Version pro Objekt, die sich bei jedem Schreibvorgang ändert und Teil des Schlüssels ist), oder indem nach einer kurzen Verzögerung erneut gelöscht wird.