Caching in Anwendungen: Kurzanleitung zu bewährten Methoden (und den darin verborgenen Fehlern)

Cache ist eines der verführerischsten Werkzeuge in der Softwareentwicklung. Mit wenig Aufwand verwandeln Sie einen langsamen Vorgang in eine sofortige Reaktion. Das System wird schneller, die Infrastruktur atmet, der Benutzer lächelt. Es sieht aus wie Magie.

Und gerade weil es wie Magie wirkt, richtet der Cache so großen Schaden an. Es löst das Leistungsproblem so einfach, dass die Leute den Cache überall verteilen, ohne zu bemerken, dass sie ein sichtbares Problem, die Langsamkeit, gegen ein unsichtbares Problem, nämlich falsche Daten, austauschen. Und falsche Daten sind viel schlimmer als langsame Daten.

Dies ist eine Kurzanleitung zur Verwendung des Caches. Die Idee besteht nicht darin, das Thema zu erschöpfen, sondern vielmehr darin, Ihnen die Kriterien zu nennen, die den Cache, der hilft, von dem Cache unterscheidet, der zur Falle wird. Wie der klassische Computerwitz sagt, gibt es nur zwei schwierige Probleme: Cache-Ungültigmachung, Benennung von Dingen und Eins-plus-eins-Fehler.

Was Cache macht, in einem Satz

Beim Caching wird das Ergebnis eines teuren Vorgangs gespeichert, um es wiederzuverwenden, anstatt den Vorgang jedes Mal wiederholen zu müssen. Sie berechnen es einmal, speichern es und geben beim nächsten Mal die gespeicherte Antwort ab.

Der „teure“ Vorgang könnte eine umfangreiche Datenbankabfrage, ein Aufruf eines externen Dienstes, eine komplexe Berechnung oder das Rendern einer Seite sein. Der Gewinn entsteht dadurch, dass die Arbeit nicht wiederholt wird. Wenn das gleiche Ergebnis viele Male angefordert wird und sich kaum ändert, ist Caching fast immer eine gute Idee.

Das Stichwort lautet „verändert sich wenig“. Darin liegt die ganze Komplexität, und hier machen die meisten Menschen einen Fehler.

Gute Praxis: Zwischenspeichern, was viel gelesen wird und wenig ändert

Der ideale Cache-Kandidat hat zwei Eigenschaften: Auf ihn wird häufig zugegriffen und er ändert sich selten. Denken Sie an eine Liste von Produktkategorien, die Konfiguration eines Systems oder das öffentliche Profil eines Benutzers. Diese Art von Daten wird ständig gelesen und von Zeit zu Zeit aktualisiert, perfekter Cache.

Der schlechte Cache-Kandidat ist das Gegenteil: Daten, die sich jeden Augenblick ändern oder deren Genauigkeit in Echtzeit von entscheidender Bedeutung ist. Der Kontostand eines Bankkontos, der zum Zeitpunkt des Kaufs verfügbare Bestand, der Preis in einer aktiven Verhandlung, Caching kann dem Benutzer eine Zahl liefern, die nicht mehr wahr ist, mit echten Konsequenzen.

Die praktische Frage vor dem Caching: Was passiert, wenn der Benutzer einen Wert sieht, der einige Sekunden oder Minuten veraltet ist? Wenn die Antwort „keine große Sache“ lautet, speichern Sie den Cache. Wenn die Antwort „ein ernstes Problem“ lautet, überlegen Sie es sich zweimal.

Das eigentliche Problem: Ungültigmachung

Das Ablegen von Daten im Cache ist trivial. Der schwierige Teil besteht darin, zu wissen, wann man entfernt oder aktualisiert. Dies ist das Ungültigkeitsproblem, und hier entsteht fast jeder Cache-Fehler.

Es gibt zwei grundlegende Strategien, und beide haben ihre Berechtigung. Der erste ist der Zeitablauf: Die Daten verbleiben für einen definierten Zeitraum im Cache und werden dann verworfen. Einfach, robust und für die meisten Fälle ausreichend. Sie akzeptieren, dass die Daten beispielsweise für fünf Minuten veraltet sein können, und machen mit Ihrem Leben weiter.

Die zweite Möglichkeit ist die Ereignisungültigmachung: Wenn sich die Daten ändern, entfernen oder aktualisieren Sie aktiv die zwischengespeicherte Version. Es ist präziser, aber auch anfälliger. Es erfordert, dass sich jede Datenänderung daran erinnert, den Cache zu benachrichtigen, und alles, was es braucht, ist ein vergessener Pfad, damit der Benutzer alte Informationen auf unbestimmte Zeit sehen kann.

Best Practice für eine Kurzanleitung: Bevorzugen Sie einen zeitlich festgelegten Ablauf, sofern die Toleranz dies zulässt. Es ist einfacher, resistenter gegen menschliches Versagen und vermeidet Fehler, bei denen der Cache die Aktualisierung „vergisst“. Reservieren Sie die Ereignisungültigmachung für den Fall, dass die Genauigkeit die Komplexität wirklich rechtfertigt.

Gute Vorgehensweise: Definieren Sie, was passiert, wenn der Cache ausfällt

Der Cache ist eine zusätzliche Ebene, und zusätzliche Ebenen schlagen fehl. Der Cache-Server kann ausfallen, nicht mehr verfügbar oder langsam sein. Die Frage, die viele Menschen vergessen zu beantworten: Was stoppt das System dann?

Gut gemachtes Caching ist eine Optimierung, keine Abhängigkeit. Wenn der Cache verschwindet, muss die Anwendung weiterarbeiten, vielleicht langsamer, aber funktionsfähig, und nach Daten aus der Originalquelle suchen. Wenn das gesamte System abstürzt, weil der Cache abgestürzt ist, liegt keine Optimierung vor. hat einen einzigen Fehlerpunkt, der als Leistungsverbesserung getarnt ist.

Es gibt auch ein tückisches Detail: Wenn der Cache auf einmal geleert wird, erreichen alle Anfragen gleichzeitig die ursprüngliche Quelle, und die Überlastung kann genau das zerstören, was der Cache geschützt hat. Es handelt sich um einen bekannten Effekt, und es lohnt sich, die Wiederherstellung unter Berücksichtigung dieses Effekts zu gestalten, damit das System den Cache erneut aufwärmt, ohne zu ertrinken.

Kritische Überlegung: Cache verbirgt das falsche Problem

Es gibt eine Verwendung von Caching, die sowohl technisch korrekt als auch strategisch faul ist: Caching, um eine schlecht gestellte Abfrage zu verbergen. Die Abfrage ist langsam, weil sie schlecht geschrieben ist oder die Datenbank schlecht modelliert ist. Statt die Ursache zu beheben, wird sie mit einem Cache überlagert. Es funktioniert, bis der Cache abläuft, bis der nicht zwischenspeicherbare Fall auftritt und bis sich das Problem verschiebt.

Der Cache sollte das beschleunigen, was bereits effizient ist, und nicht das ausgleichen, was ineffizient ist. Wenn Sie feststellen, dass Sie den Cache verwenden, um etwas erträglich zu machen, das behoben werden sollte, lohnt es sich, innezuhalten und nach der Ursache zu suchen. Der Cache dient in diesem Fall dazu, eine Schuld aufzuschieben, nicht zu begleichen.

Hinzu kommen die kognitiven Kosten. Jede Cache-Ebene ist ein weiterer Ort, an dem Daten möglicherweise veraltet sind, ein weiterer Ort, an dem untersucht werden kann, wenn etwas seltsam ist. „Warum sieht dieser Benutzer alte Informationen?“ ist eine der frustrierendsten Fragen beim Debuggen, gerade weil der Cache unsichtbar ist, bis ein Problem auftritt. Zu viel Cache macht ein einfaches System zu einem Versionierungsrätsel. Gehen Sie sparsam damit um, dokumentieren Sie, wo Sie sich befinden, und bevorzugen Sie weniger wohlverstandene Schichten gegenüber vielen mysteriösen Schichten.

Was bleibt

Cache ist ein mächtiges Werkzeug und wird ebenso häufig missbraucht. Bei guter Anwendung hinterlässt es schnelle und kostengünstige Systeme. Es wird missbraucht, liefert falsche Informationen, verbirgt echte Probleme und erzeugt Fehler, die schwer nachzuverfolgen sind.

Gute Praktiken passen in ein paar Zeilen: Zwischenspeichern, was viel gelesen wird und wenig ändert; bevorzugen Sie einen zeitlich festgelegten Ablauf gegenüber einer manuellen Ungültigmachung; Stellen Sie sicher, dass das System ohne Cache überlebt. und verwenden Sie Caching niemals, um ein Problem zu verbergen, das behoben werden sollte. Der Rest ist Feinabstimmung.

Wenn Sie mit Leistungsproblemen konfrontiert sind und Caching als Lösung in Betracht ziehen, lohnt es sich zunächst zu verstehen, ob der Engpass tatsächlich auf wiederholtes Lesen zurückzuführen ist oder auf etwas Tieferes zurückzuführen ist. Auf dem Blog gibt es weitere Texte zu Backend, Leistung und Architektur, die sich eingehender mit diesen Auswahlmöglichkeiten befassen.