Was ist ein verteilter Cache und wie behandeln Sie seine Ausfälle?

Question

IT Interview Practice · Accepted Answer

**Ein verteilter Cache lässt mehrere Anwendungsinstanzen Daten über das Netzwerk wiederverwenden.** Er spart wiederholte teure Arbeit und braucht klare Regeln für Aktualität und Ausfälle.

Drei Backendinstanzen lesen etwa denselben Produktkatalog. Bei Prozesscaches hat jede ihre eigene Kopie. Ein gemeinsamer Cachedienst ermöglicht, dass eine Instanz eine von anderen genutzte Information lädt. Der Cachedienst kann selbst aus mehreren Knoten bestehen.

## 1. Bestimmen Sie sicher cachebare Daten

Beginnen Sie mit Erzeugungskosten und zulässigem Alter. Eine Produktbeschreibung verträgt kurze Verzögerung, die abschließende Bestandsprüfung möglicherweise nur maßgebliche Daten.

Der Schlüssel muss das gesamte Ergebnis einschließlich Mandant, Sprache und relevanter Eingaben bestimmen. Sonst liefert ein schneller Cache fremde Kundendaten. Die Datenbank bleibt maßgeblich für dauerhafte Geschäftsdaten, da Cachewerte verschwinden können.

## 2. Verstehen Sie Lesen vor Aktualisieren

Bei Cache-aside prüft die Anwendung den Cache, liest bei Fehlen die Datenbank und speichert das Ergebnis mit einer Ablaufzeit, TTL.

```text
Request -> Cache -> hit  -> Return value
                 -> miss -> Database -> Fill cache -> Return value
```

Das spart wiederholte Datenbankzugriffe auf denselben Wert. Netzwerkaufrufe und zusätzliche Abhängigkeit kosten aber ebenfalls; die Einsparung muss größer sein. Siehe [Redis Cache-aside](https://redis.io/docs/latest/develop/use-cases/cache-aside/).

## 3. Legen Sie die Sichtbarkeit von Änderungen fest

Für den Katalog bietet sich zunächst Commit in der Datenbank mit anschließender Cacheinvalidierung an. Der nächste Leser lädt neu. Dennoch kann ein Leser den alten Wert vor dem Commit holen und erst nach der Invalidierung cachen.

TTL begrenzt die Lebensdauer dieser neuen Cachekopie, garantiert aber keine sofortige Sicht des letzten Schreibens. Verletzen alte Rechte, Preise oder Salden die Regeln, prüfen Sie maßgebliche Daten oder entwerfen Sie versionierte Aktualisierung mit ausdrücklichen Garantien. Konsistenz folgt der Geschäftsoperation, nicht allein der Wahl von Redis.

## 4. Verhindern Sie Ausfälle durch Cache Misses

Läuft ein beliebter Eintrag ab, können viele Aufrufer gleichzeitig die Datenbank lesen: ein Cache Stampede. Ein Cacheausfall kann das für viele Einträge auslösen.

- Bündeln Sie gleichzeitiges Nachladen desselben Schlüssels und bestimmen Sie, ob die Koordination pro Prozess oder über alle Instanzen gilt.
- Verteilen Sie Ablaufzeiten gegen gemeinsame Expiration. Das glättet Aktualisierungsarbeit, löst aber nicht jedes Hot-Key-Problem.
- Liefern Sie während des Nachladens alte Werte nur bei fachlicher Erlaubnis.
- Nutzen Sie kurze Cachetimeouts und begrenzen Sie Datenbankfallback. Teilweise Ablehnung kann sicherer sein als eine überlastete Datenbank mit vollständigem Ausfall.

Testen Sie diese Wege gezielt. Eine hohe Trefferrate im Normalbetrieb sagt wenig über Verhalten ohne Cache.

## 5. Skalieren Sie nach dem tatsächlichen Engpass

Sharding verteilt Schlüssel, Replikation hält Kopien für Verfügbarkeit oder Lesen. Beides löst andere Probleme. Redis Cluster platziert mit Hash Slots, daher verteilt ein zusätzlicher Knoten nicht automatisch die Arbeit eines einzelnen Hot Keys. Siehe [Redis-Cluster-Spezifikation](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/).

Beobachten Sie Trefferquote, Latenz, Timeouts, Speicher, Verdrängungen und Datenbanklast. Eine Verdrängung entfernt Werte zur Speicherverwaltung und kann vor TTL erfolgen. Cacheeinträge sind keine garantierte dauerhafte Ablage für Geschäftsdaten oder Queuearbeit.

Für den Katalog würde ich mit expliziten Cache-aside-Schlüsseln, Aktualitätsregeln und geschütztem Fallback beginnen. Zusätzliche Knoten folgen erst auf einen gemessenen, verteilbar lösbaren Engpass. **Ein gutes Design erklärt vorhandene, fehlende und falsche Cachewerte.**

1. Bestimmen Sie sicher cachebare Daten

2. Verstehen Sie Lesen vor Aktualisieren

3. Legen Sie die Sichtbarkeit von Änderungen fest

4. Verhindern Sie Ausfälle durch Cache Misses

5. Skalieren Sie nach dem tatsächlichen Engpass

Ähnliche Fragen