Cache-Daten mit TTL und Invalidierung aktualisieren

Einführung

Ein Cache reduziert Quellenzugriffe, kann nach einer Änderung aber einen alten Preis liefern. Beobachte dieses Zeitfenster, lass den Wert ablaufen und mache danach eine Anwendungsänderung durch gezielte Invalidierung sofort sichtbar.

Absolviere zuerst Add a Cache to a Product Lookup. Diese neue VM stellt eigene Anwendung, DynamoDB-Katalog und verbundenen Valkey-Knoten bereit. Nutze Terminal für AWS CLI und Anwendungsbefehle sowie AWS View zum Vergleich. Ressourcen früherer VMs werden nicht wiederverwendet.

Bezug zur Zertifizierung

Einen Preis nach TTL-Ablauf aktualisieren

TTL, Time to Live, begrenzt die Verfügbarkeit einer Cache-Kopie. Der Ablauf entfernt nur die Kopie, nicht das maßgebliche DynamoDB-Element.

Prüfe Identität und Einstellungen:

cd /home/labex/project
aws sts \
  get-caller-identity
cat app.json

Die ARN endet auf labex-ca02-operator. Die Anwendung verwendet bereits cache-aside; Produkt 101 kostet anfangs 20.00. Speichere und zeige den Endpunkt:

CACHE_HOST=$(jq -r .cache_host app.json)
echo "$CACHE_HOST"

Verwende fünf Sekunden TTL für diese kurze Demonstration. Nur neue Cache-Schreibvorgänge verwenden die neue TTL; vorhandene Schlüssel ändern sich nicht rückwirkend:

jq '.ttl_seconds = 5' app.json > app.next.json
mv app.next.json app.json

Führe den gesamten folgenden Block ohne Unterbrechung aus: Lies das ursprüngliche Produkt, ändere direkt DynamoDB und lies vor Ablauf von fünf Sekunden erneut. Die direkte Änderung benachrichtigt den Anwendungscache nicht:

curl -sS http://127.0.0.1:8080/api/products/101
aws dynamodb \
  update-item \
  --table-name product-catalog \
  --key '{"product_id":{"S":"101"}}' \
  --update-expression 'SET price = :price' \
  --expression-attribute-values '{":price":{"N":"21.00"}}' \
  --return-values ALL_NEW
curl -sS http://127.0.0.1:8080/api/products/101

Die Quelle meldet 21.00, die sofortige Cache-Antwort noch 20.00 mit served_from: cache. AWS View zeigt den neuen Quelldatensatz und die Einstellungen. Ein Datenbankupdate invalidiert einen Anwendungscache nicht automatisch. Warte länger als die TTL und frage erneut ab:

sleep 6
curl -sS http://127.0.0.1:8080/api/products/101

Die Antwort liefert 21.00 aus der Quelle. Der abgelaufene Schlüssel fehlt, deshalb liest die Anwendung DynamoDB und speichert den neuen Wert. Prüfe zeitnah die verbleibende Lebensdauer:

valkey-cli -h "$CACHE_HOST" -p 6379 TTL product:101

Eine positive Zahl gibt verbleibende Sekunden an; -2 bedeutet, dass der Schlüssel bereits abgelaufen ist. Fünf Sekunden dienen der Beobachtung, nicht als Produktionsvorgabe. Die geeignete TTL hängt von der tolerierbaren Veraltung ab.

Das geänderte Produkt sofort invalidieren

Invalidierung entfernt eine Kopie, damit die nächste Anfrage aktuelle Quelldaten liest. Sie ergänzt die TTL und macht bekannte Änderungen ohne Warten sichtbar.

Der HTTP-PUT der Anwendung aktualisiert DynamoDB und löscht anschließend den passenden Schlüssel. Führe Befüllen, Ändern und zwei Abfragen als einen Block aus, damit die kurze TTL beobachtbar bleibt:

curl -sS http://127.0.0.1:8080/api/products/101
curl -sS -X PUT \
  -H 'Content-Type: application/json' \
  --data '{"price":"22.00"}' \
  http://127.0.0.1:8080/api/products/101
curl -sS http://127.0.0.1:8080/api/products/101
curl -sS http://127.0.0.1:8080/api/products/101

Die Änderung meldet invalidation_key: product:101 und normalerweise removed: 1. Ist der Schlüssel zuvor abgelaufen, ist removed: 0 gültig; der richtige Schlüssel bleibt erforderlich. Die nächste Anfrage liefert 22.00 aus der Quelle, die folgende aus dem Cache. Lesen und Invalidieren müssen denselben Schlüssel verwenden.

Prüfe, dass das unabhängige Produkt 202 weiterhin Notebook für 12.50 ist:

aws dynamodb \
  get-item \
  --table-name product-catalog \
  --key '{"product_id":{"S":"202"}}' \
  --consistent-read

Lass die aktualisierte Anwendung zur Prüfung verfügbar. Die Kontrollen lesen tatsächliche Ergebnisse und Quelldaten; ein Schlüssel muss nicht über seine kurze TTL hinaus bestehen.

Zusammenfassung

Du hast eine veraltete Cache-Antwort nach einer direkten Quellenänderung, eine Aktualisierung nach Ablauf und eine sofortige Aktualisierung durch gezielte Invalidierung beobachtet. Die Quelle bleibt maßgeblich; die TTL begrenzt das Zeitfenster und die Anwendung invalidiert genau den Leseschlüssel.

Weitere Informationen bietet die AWS-Dokumentation: TTL und tolerierbare Veraltung des Caches; Valkey-TTL-Rückgabewerte.