Das Problem mit dem veralteten Spickzettel
Sie notieren sich die Öffnungszeiten eines Cafés auf einem Post-it. Am nächsten Tag ändert das Café seine Zeiten, aber Ihr Zettel bleibt hängen. Sie stehen um neun vor verschlossener Tür. Darum geht es bei Cache-Konsistenz: Ein Cache speichert eine Kopie der Daten für schnellen Zugriff. Ändern sich die Originaldaten, wird die Kopie zur Falle. Der Cache liefert dann veraltete Preise, abgelaufene Berechtigungen oder nicht existierende Lagerbestände.
Cache-Konsistenz hält die Abweichung zwischen Cache und Datenbank klein. Je schneller ein System sein soll, desto mehr ist es auf Caching angewiesen. Fast jeder hochfrequentierte Dienst setzt heute Caches ein. Entscheidend ist zu wissen, wie weit die gecachten Werte von der Quelle abweichen dürfen, und diese Abweichung im Rahmen dessen zu halten, was Ihre Anwendung verkraftet. Dieser Beitrag erklärt, was Cache-Konsistenz bedeutet, warum Caches altern, welche klassischen Muster es gibt und wie ereignisgesteuerte Synchronisation die Daten frisch hält, wenn Zeitfenster allein nicht ausreichen.
Was Cache-Konsistenz bedeutet
Ein Cache ist konsistent, wenn seine Werte mit der Quelle der Wahrheit übereinstimmen. Jede Konsistenzstrategie zielt darauf ab, das Zeitfenster zu verkleinern, in dem die beiden voneinander abweichen. Diese Abweichung heißt Staleness – sie ist kein binärer Zustand, sondern ein Fenster. Jede Strategie in diesem Artikel versucht, dieses Fenster zu verkleinern, zu begrenzen oder zu entscheiden, welche Daten das engste Fenster benötigen.
Die Art, wie Sie Aktualisierungen propagieren, bestimmt, wie konsistent Ihre Lesevorgänge sind. Synchron bedeutet: Eine Änderung wird an alle relevanten Knoten weitergegeben, bevor ein Leser sie sieht. Asynchron bedeutet: Sie tauschen diese Garantie gegen Geschwindigkeit ein und landen in der Eventual Consistency, wo manche Knoten vorübergehend veraltete Daten ausliefern. Die meisten realen Systeme liegen irgendwo auf diesem Spektrum. Es ist besser, sich bewusst zu positionieren, als es erst bei einem Vorfall zu entdecken. Selbst Hyperscaler wie Meta haben Jahre investiert, um die Cache-Konsistenz ihres TAO-Systems von sechs Neunen auf zehn Neunen zu steigern.
Warum Caches altern: TTL, Schreibreihenfolge und Instanz-Wettläufe
Caches altern aus drei bekannten Gründen: TTL-Fenster, die länger leben als die Daten, Wettläufe bei der Schreibreihenfolge zwischen Cache und Datenbank sowie mehrere Anwendungsinstanzen, die sich bei Cache-Befüllungen gegenseitig behindern. Die Mechanismen unterscheiden sich, aber das Ergebnis ist gleich: Der Cache bedient einen Wert, nachdem die Quelle bereits weitergeschritten ist.
TTL-Zeitfenster
Im reinen Verfallsmodell bekommt jeder Eintrag eine Time-to-Live (TTL) – eine Lebensdauer, nach der er als veraltet gilt und entfernt oder erneuert wird. Ein Cache, der nur auf TTL setzt, liefert veraltete Daten für das gesamte Restfenster nach einer Datenbankänderung. Wenn Ihre TTL fünf Minuten beträgt und der Preis zehn Sekunden nach der Änderung abgefragt wird, sehen die Leser den alten Preis viereinhalb Minuten lang.
Die Verfallsmechanismen selbst bringen zusätzliche Feinheiten mit sich. Ein gutes Beispiel ist Redis: Es löscht abgelaufene Keys auf zwei Arten – passiv, wenn ein Client auf einen bereits abgelaufenen Key zugreift, und aktiv durch einen Hintergrundzyklus, der alle 100 Millisekunden 20 Keys stichprobenartig prüft und die abgelaufenen entfernt. Keys werden also nicht im exakten Moment ihres TTL-Ablaufs gelöscht. Das Fenster der Veraltung ist immer etwas größer als die TTL vorgibt.
Schreibreihenfolge-Wettläufe
TTL-Fenster sind wenigstens vorhersagbar; Wettläufe sind es nicht. Ein Race Condition entsteht, wenn zwei Operationen zeitlich überlappen und das Ergebnis davon abhängt, welche zuerst fertig wird. Ein veralteter Set tritt auf, wenn gleichzeitige Aktualisierungen umsortiert werden und der Cache einen Wert aus dem falschen Moment behält. Ein Cache-Fill kann mit einer Datenbanktransaktion verschränkt werden, sodass der Cache eine Mischung aus alten und neuen Daten erhält. Fällt dann die Invalidation-Nachricht aus, korrigiert sich nichts bis zum nächsten Schreibzugriff oder TTL-Ablauf. Das Wettlauf-Fenster ist winzig, aber im Hyperscaler-Maßstab mit enormen Anfrage- und Cache-Fill-Volumina treten selbst seltene Races häufig genug auf, um zu stören.
Multi-Instanz-Bevölkerungsrennen
Horizontale Skalierung vervielfacht die Racer. Stellen Sie sich zwei App-Instanzen vor: Instanz A löscht einen Cache-Eintrag und wird gleich die Datenbank aktualisieren. Bevor As Schreibzugriff landet, bekommt Instanz B einen Cache-Miss, liest den alten Wert aus der Datenbank und schreibt ihn zurück in den Cache. Dann führt A sein Update aus. Jetzt hat die Datenbank den neuen Wert und der Cache den alten – ohne dass eine Invalidation kommt, um das zu korrigieren. Ein weiteres Phänomen ist die Thundering Herd: Viele Anfragen erleiden gleichzeitig einen Cache-Miss und stürmen die Datenbank, jede rennt darum, den gleichen Key mit dem gerade gelesenen Schnappschuss zu befüllen.
Cache-Aside vs. Write-Through: Die klassischen Abwägungen
Diese Ausfallmodi erklären, warum das gewählte Caching-Muster entscheidend ist: Jedes zieht die Konsistenzgrenze an einer anderen Stelle. Diese Grenze bestimmt, ob Schreibvorgänge warten müssen, Lesevorgänge riskieren, veraltet zu sein, oder Ihre Anwendung mehr Koordinationsarbeit leisten muss.
Cache-Aside (Lazy Loading)
Beim Cache-Aside-Muster verwaltet die App den Cache direkt. Sie lädt Daten nur bei Bedarf: Prüfe den Cache – bei einem Miss lies aus der Datenbank – schreibe in den Cache – gib zurück. Bei Schreibvorgängen aktualisiert die App die Datenbank und invalidert dann den Cache-Eintrag, sodass der nächste Lesevorgang ihn frisch nachlädt. Es ist flexibel, aber diese Flexibilität hat Kosten: Ein externer Prozess kann die Datenbank jederzeit ändern, und der Cache merkt es erst beim nächsten Laden. Der erste Request für ungecachete Daten zahlt die volle Latenz – so langsam wie ein normaler Datenbankaufruf. Und die Multi-Instanz-Races von oben sind die charakteristische Schwachstelle von Cache-Aside.
Write-Through
Write-Through dreht den Schreibpfad um: Schreibvorgänge gehen sowohl in den Cache als auch in die Datenbank in derselben synchronen Operation. Leser sehen also nach erfolgreichem Schreiben den neuen Wert – sofern beide Schreibvorgänge durchkommen. Das erkauft Read-your-Writes-Verhalten, was für Daten wie Kontostände und Bestellungen wichtig ist. Dafür zahlt man dreifach: Jeder Schreibzugriff wartet auf zwei Systeme. Ein teilweiser Fehler zwischen den beiden Schreibvorgängen hinterlässt eine Inkonsistenz, die Sie selbst auflösen müssen. Und jeder geschriebene Wert landet im Cache, egal ob jemals jemand ihn liest – das kann Speicher für kalte Daten verschwenden.
Ein drittes Muster ist Write-Behind: Schreibvorgänge treffen zuerst den Cache und werden asynchron in die Datenbank gespült. Das bietet schnellere Schreibvorgänge, aber schwächere Konsistenz. Ein Cache-Absturz vor dem Spülen kann Datenverlust bedeuten. Es eignet sich für schreibintensive Workloads mit niedrigerem Risiko, wie Analyse-Events oder Zähler.
Ereignisgesteuerte Synchronisation schließt die Lücke der TTL
Keines der klassischen Muster hilft, wenn Daten außerhalb Ihrer App geändert werden: durch einen Batch-Job, einen Datenbankadministrator, einen anderen Dienst, der direkt in die Datenbank schreibt. Ereignisgesteuerte Invalidation reagiert auf die Änderung selbst, statt auf einen Timer zu warten.
Keyspace Notifications für Cache-seitige Änderungen
Redis liefert einen Baustein dafür: Keyspace Notifications. Clients abonnieren Pub/Sub-Kanäle und erhalten Ereignisse, wenn sich Keys ändern. So kann eine App-Instanz ihre lokale Kopie verwerfen, sobald eine andere Instanz einen Key modifiziert. Pub/Sub ist jedoch Fire-and-Forget: Ein Client, der die Verbindung verliert und wieder aufbaut, verpasst alle Ereignisse dazwischen. Eine Reconciliation-Strategie ist daher sinnvoll. Auch Expired-Events feuern erst, wenn Redis den Key tatsächlich löscht – nicht im Moment des TTL-Ablaufs – also kann es eine Verzögerung geben.
Change Data Capture für datenbankseitige Änderungen
Für Änderungen, die in Ihrer Quelldatenbank entstehen, ist Change Data Capture (CDC) die robustere Antwort. Log-basierte CDC-Tools wie Debezium lesen das Transaktionslog der Datenbank, wandeln festgeschriebene Zeilenänderungen in Ereignisse um und lassen einen Consumer Cache-Einträge nahezu in Echtzeit invalidieren oder aktualisieren. Debezium bietet At-Least-Once-Lieferung: Festschreibungen werden nicht verpasst, aber ein Datensatz kann mehrfach eintreffen – der Consumer muss Duplikate handhaben.
Ubers CacheFront zeigt sowohl die Leistungsfähigkeit als auch den Aufwand. Sein früheres Design kombinierte TTLs mit CDC und hatte Read-your-Writes-Probleme: Eine Zeile, die gelesen, gecacht und dann aktualisiert wurde, konnte veraltete Werte ausliefern, bis eine Invalidation oder der TTL-Ablauf kam. Solche Races zeigen, warum Cache-Schreibvorgänge Frischeprüfungen brauchen, statt den zuletzt eintreffenden Wert zu akzeptieren. Später schichtete Uber ein Write-Through-Protokoll darauf, bei dem jeder Knoten vor der Auslieferung die Frische mit der Datenbank validiert. Das System erzielte dann eine höhere Trefferquote bei längeren TTLs. In diesen Systemen erledigen ereignisgesteuerte Signale oft den Großteil der Frischearbeit, während die TTL als Sicherheitsnetz bleibt. Die eigentliche Ingenieursarbeit steckt in der Ordnung, Deduplizierung und Wiedergabelogik.
Die richtige Strategie wählen: Schreibvolumen und Veraltungstoleranz
Sie brauchen wahrscheinlich nicht Ubers Drei-Mechanismen-Setup. Überlegen Sie, wie viel Veraltung Ihre Daten vertragen und wie schreibintensiv die Arbeitslast ist, und ordnen Sie dann ein Muster zu.
Als Faustregeln: Bei leseintensiven Daten, die etwas Veraltung vertragen, reicht Cache-Aside mit TTL. Ein Produktkatalog, der ein paar Sekunden alt ist, fällt niemandem auf. Wenn Read-your-Writes erforderlich ist – etwa bei Kontoständen oder Zahlungen – passt Write-Through. Nutzer verkraften Schreiblatenz meist besser als Lese-Latenz, also liegt der Doppelschreibaufwand an der richtigen Stelle. Bei schreibintensiven, weniger riskanten Daten (Zähler, Events) absorbiert Write-Behind Schreibspitzen, gegen ein Datenverlustrisiko bei Cache-Ausfall. Ändern sich Daten außerhalb Ihrer App oder kostet Veraltung Geld, ergänzen Sie eine ereignisgesteuerte Invalidation – und behalten Sie eine konservative TTL als Rückfall für verpasste Ereignisse.
Diese Startpunkte sind keine Gesetze. Schon die Länge der TTL kann eine Strategie von gut zu schädlich verschieben. Eine fünfminütige TTL, die für eine Startseite harmlos ist, wäre für Live-Bestände problematisch. Segmentieren Sie TTLs nach der tatsächlichen Änderungsrate der jeweiligen Daten.
Ihren Cache mit Redis frisch halten
Die Teams, die Cache-Konsistenz beherrschen, schichten ihre Mechanismen: ein Muster, das zur Arbeitslast passt, eine TTL als Sicherheitsnetz und ein ereignisgesteuertes Frischesignal. Der schwierige Teil ist zu entscheiden, wie viel von dieser dritten Schicht Ihr Team selbst bauen und betreiben will. Das manuelle Errichten bedeutet, CDC-Connectors zu betreiben, Ordnung und Duplikate zu verwalten und eigene Race-Condition-Logik zu schreiben.
Redis Data Integration (RDI) übernimmt diese Schicht für Sie. RDI ist ein Change-Data-Capture-System, das Änderungen in einer Quelldatenbank verfolgt und auf Redis anwendet – zuerst durch einen vollständigen Snapshot, dann durch Streaming der Änderungen, sobald sie eintreten. In unterstützten RDI-Bereitstellungen können Aktualisierungen aus Ihrer Quelldatenbank den Cache innerhalb weniger Sekunden erreichen, abhängig von Quellenlast, Connector-Konfiguration und Netzwerkbedingungen. Sie definieren in Konfigurationsdateien, wie relationale Tabellen auf Redis Hashes, JSON oder Streams abgebildet werden. Die Lieferung erfolgt At-Least-Once, und RDI bewahrt die Änderungsreihenfolge pro Tabelle. So bleibt Ihr Cache frisch und Ihre Anwendung schnell – ohne dass Sie die Komplexität selbst stemmen müssen.
Quelle: redis.io
