Die Anwendung bei Cache-Ausfällen funktionsfähig halten

Einführung

Eine Produktabfrage soll bei einem nicht antwortenden optionalen Cache weiter funktionieren. Beobachte den Fehler, begrenze die Cache-Wartezeit, aktiviere den Rückgriff auf die Quelle und stelle danach Hits wieder her.

Absolviere zuerst Add a Cache to a Product Lookup. Diese unabhängige VM bietet eigene Anwendung, DynamoDB-Quelle und Valkey-Knoten. Nutze Terminal und AWS View. Die vorbereitete Fehlersteuerung pausiert nur den Cache-Prozess dieses Labs; ein eigenes Fehlertool ist nicht nötig.

Bezug zur Zertifizierung

Einen tatsächlichen Cache-Timeout beobachten

Ein Timeout begrenzt die Wartezeit. Ein pausierter Prozess behält seinen Endpunkt, antwortet aber nicht; das unterscheidet sich von einem fehlenden Schlüssel.

Prüfe Identität und Einstellungen:

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

Die ARN endet auf labex-ca03-operator. Anfangs gelten timeout_seconds: 2 und fallback_on_error: false. Frage bei gesundem Cache zweimal ab:

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

Die erste Anfrage liest die Quelle, die zweite den Cache. Aktiviere den vorbereiteten Fehler:

curl -sS -X POST \
  -H 'Content-Type: application/json' \
  --data '{"action":"pause"}' \
  http://127.0.0.1:8080/api/fault

Frage das Produkt mit HTTP-Status ab:

curl -sS -w '\nHTTP %{http_code}\n' \
  http://127.0.0.1:8080/api/products/101

Dieser Fehler ist beabsichtigt. Nach ungefähr zwei Sekunden erhältst du HTTP 503 mit failure: TimeoutError, obwohl die Datenbank das Produkt noch enthält. Ein Cache-Ausfall sollte nicht automatisch den Katalog unbenutzbar machen.

Wartezeit begrenzen und die Quelle verwenden

Fallback ist ein bewusst gewählter Alternativpfad nach einem Cache-Fehler. Ein normaler Miss bedeutet lediglich eine fehlende Kopie.

Stelle für diese kontrollierte Übung 0.2 Sekunden ein und aktiviere Fallback:

jq '.timeout_seconds = 0.2 | .fallback_on_error = true' \
  app.json > app.next.json
mv app.next.json app.json

Lass den Cache pausiert und zeige die Anfragedauer:

curl -sS -w '\nHTTP %{http_code}; elapsed %{time_total}s\n' \
  http://127.0.0.1:8080/api/products/101

HTTP 200 liefert den aktuellen Preis 20.00, served_from: source und cache_error: TimeoutError. Die Cache-Wartezeit beträgt ungefähr 0.2 Sekunden. Jede Anfrage während des Ausfalls liest die Quelle: Fallback erhält die Funktion, erhöht aber die Datenbanklast.

Vergleiche in AWS View Timeout, pausierten Zustand und Lesezähler. Diese Einzelumgebung bestimmt weder einen Produktions-Timeout noch Lastkapazität oder AWS-Verfügbarkeitsgarantien.

Den Cache fortsetzen und wieder Hits beobachten

Ein gesunder Cache und erfolgreicher Fallback sind verschiedene Ergebnisse. Setze den Cache-Prozess fort:

curl -sS -X POST \
  -H 'Content-Type: application/json' \
  --data '{"action":"resume"}' \
  http://127.0.0.1:8080/api/fault

Frage zweimal ab:

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

Beobachte served_from: cache und cache_error: null. Falls die ursprüngliche TTL abgelaufen ist, befüllt die erste Anfrage den Schlüssel aus der Quelle; die nächste ist ein Hit. Bei aufeinanderfolgenden Hits bleibt der Quellenzähler gleich.

Lass Cache und begrenzten Fallback zur Prüfung aktiv. Überwache in echten Diensten Cache-Fehler und zusätzliche Quellenlast; Fallback kann eine ebenfalls ausgefallene Datenbank nicht verfügbar machen.

Zusammenfassung

Du hast einen echten Timeout eines pausierten Caches beobachtet, begrenzten Fallback aktiviert und tatsächliche Hits nach Wiederherstellung gesehen. Misses und Fehler brauchen unterschiedliche Behandlung; Fallback erhält Antworten durch zusätzliche Datenbankarbeit.

Weitere Informationen bietet die AWS-Dokumentation: Client-Zeitüberschreitungen passend zur Arbeitslast wählen.