Caching verstehen: So arbeiten Redis und Memcached in der Softwareentwicklung

Caching bedeutet, häufig angefragte Daten aus einer schnellen Schicht auszuliefern, statt jedes Mal eine langsame Quelle abzufragen. Ich betreue Webprojekte seit 2012. Bei den meisten langsamen Websites liegt das Problem nicht im Code selbst, sondern in einer Architektur, die dieselbe Abfrage tausendfach wiederholt. In diesem Beitrag erkläre ich Strategien, TTL, Invalidierung und die echten Unterschiede zwischen Redis und Memcached.

Ich schreibe aus der Sicht eines Entwicklers, halte den Text aber auch für Projektverantwortliche verständlich. Weitere technische Beiträge finden Sie in der Kategorie Software.

Was ist Caching und wozu brauchen Anwendungen es?

Caching ist ein Verfahren, bei dem Sie das Ergebnis einer Abfrage oder Berechnung für begrenzte Zeit in schnellem Speicher ablegen, damit spätere Anfragen es ohne erneute Berechnung nutzen können. Ziel ist es, langsame Ressourcen wie Datenbanken, externe APIs oder aufwendige Berechnungen zu entlasten und die Antwortzeit zu senken.

Die Logik ist einfach, denn es geht um Geschwindigkeit. Arbeitsspeicher ist deutlich schneller als ein Festplattenzugriff oder eine Netzwerkabfrage. Deshalb halten Sie Daten, die oft gelesen, aber selten geändert werden, im RAM. Dazu zählen Produktlisten, Kategoriemenüs oder Wechselkurse. Somit arbeitet die Datenbank nur dann, wenn Sie wirklich frische Daten brauchen.

Allerdings ist Caching nie kostenlos. Sobald Sie Daten an zwei Orten halten, entsteht eine neue Frage: Welche Kopie stimmt? Der Rest dieses Beitrags dreht sich im Kern um genau diese Frage. Zunächst geht es um die Schichten, danach um die Strategien und schließlich um die zwei bekanntesten Werkzeuge.

Auf welchen Ebenen sitzt ein Cache im Web?

Eine Webanfrage durchläuft auf dem Weg vom Browser zur Datenbank mehrere Cache Ebenen. Jede Ebene löst dabei ein anderes Problem, denn die Anforderungen unterscheiden sich. Daher können Sie nicht alle mit denselben Regeln steuern.

• Browser Cache: speichert CSS, JavaScript und Bilder auf dem Gerät des Nutzers; Sie steuern ihn über HTTP Header.
• CDN und Reverse Proxy: halten statische Dateien und manchmal ganze HTML Seiten auf Servern in Nutzernähe.
• Anwendungscache: ein Server wie Redis oder Memcached speichert Abfrageergebnisse, Sessions und berechnete Objekte.
• Prozessinterner Cache: kleine Wörterbücher im Speicher der Anwendung selbst; am schnellsten, aber nicht zwischen Servern teilbar.
• Datenbankcache: der Pufferpool der Datenbank hält häufig gelesene Seiten im Speicher.

Für die HTTP Seite bietet der Leitfaden von web.dev zum HTTP Cache eine gute Übersicht. In diesem Beitrag konzentriere ich mich auf die Anwendungsebene, also auf Redis und Memcached.

Was bedeuten Cache Hit und Cache Miss?

Ein Hit liegt vor, wenn die gesuchten Daten bereits im Cache liegen. Die Anwendung liefert sie direkt aus dem Speicher. Bei einem Miss fehlen die Daten dagegen. In diesem Fall geht die Anwendung zur Quelle, liest den Wert und schreibt ihn meist zusätzlich in den Cache.

Konkret zeigt die Trefferquote, welchen Anteil aller Lesezugriffe der Cache bedient. Beispielrechnung: Kommen 900 von 1.000 Lesezugriffen aus dem Cache, liegt Ihre Trefferquote bei 90 Prozent. Die übrigen 100 Anfragen erreichen dann die Datenbank.

Trotzdem sollten Sie die Trefferquote nicht zum einzigen Ziel machen. Mit einer sehr langen TTL treiben Sie sie leicht nach oben. Dann zeigen Sie Ihren Nutzern allerdings veraltete Daten. Entscheidend ist, ob Sie korrekte Daten mit akzeptabler Latenz liefern.

Kennen sollten Sie außerdem den kalten Cache. Nach einem Neustart oder einem neuen Release ist der Cache leer, und in den ersten Minuten verfehlt fast jede Anfrage ihr Ziel. Deshalb füllen stark besuchte Systeme die wichtigsten Keys direkt nach dem Deployment per Skript vor. Man nennt das Cache Warming.

Wie funktioniert das Muster Cache Aside?

Cache Aside, auch Lazy Loading genannt, ist das verbreitetste Caching Muster. Die Anwendung nutzt den Cache als Nebenspeicher und behält die volle Kontrolle. Auch das AWS Whitepaper zu Caching Mustern beschreibt diesen Ansatz als Grundlage.

1. Zunächst fragt die Anwendung den Cache nach einem Key.
2. Existiert der Wert, liefert sie ihn sofort zurück.
3. Fehlt er, liest sie ihn aus der Datenbank.
4. Dann schreibt sie das Ergebnis mit einer TTL in den Cache.
5. Schließlich gibt sie das Ergebnis an den Nutzer zurück.

Der größte Vorteil: Sie speichern nur Daten, die tatsächlich jemand angefragt hat. Zudem läuft die Anwendung weiter, wenn der Cache Server ausfällt; sie wird nur langsamer. Diese Robustheit macht Cache Aside zu meiner ersten Wahl. Der Nachteil sind zusätzliche Wege bei jedem Miss. Außerdem müssen Sie veraltete Keys selbst löschen, sobald sich Daten ändern.

Worin unterscheiden sich Read Through und Write Through?

Beim Read Through spricht die Anwendung nur mit dem Cache. Fehlt ein Key, lädt die Cache Schicht den Wert selbst aus der Quelle. Das heißt, die Logik für den Miss wandert aus Ihrem Code in eine Bibliothek oder zu einem Anbieter.

Write Through betrifft die Schreibseite. Aktualisiert die Anwendung einen Datensatz, schreibt sie den neuen Wert im selben Vorgang in die Datenbank und in den Cache. Folglich bleibt der Cache stets aktuell, und Lesezugriffe treffen sofort.

Andererseits verlangsamt Write Through jeden Schreibvorgang etwas, denn Sie schreiben an zwei Orte. Zudem füllen Sie den Cache mit Daten, die womöglich niemand liest. Deshalb nutze ich Write Through meist für Daten, die oft gelesen werden und sofort sichtbar sein müssen, etwa Lagerbestände oder Preise.

Sie können beide Ansätze auch kombinieren. In vielen meiner Projekte läuft Cache Aside für Lesezugriffe und Write Through für wenige kritische Datensätze.

Wann lohnt sich Write Behind?

Write Behind, auch Write Back genannt, schreibt zuerst in den Cache und überträgt die Änderungen später, oft gebündelt, in die Datenbank. Für den Nutzer fühlt sich das Schreiben sehr schnell an, weil niemand auf die langsame Quelle wartet.

Allerdings birgt dieses Muster ein ernstes Risiko. Stürzt der Cache Server vor der Übertragung ab, können Sie diese Schreibvorgänge verlieren. Daher setze ich Write Behind nie für Zahlungen, Bestellungen oder Rechnungen ein.

Wo hilft es also? Bei Daten, für die ungefähre Genauigkeit reicht und die sehr häufig geschrieben werden. Seitenaufrufzähler, Likes und Analyseereignisse sind gute Beispiele. Zum Beispiel erhöhen Sie einen Zähler im Speicher und sichern ihn einmal pro Minute, statt bei jedem Aufruf in die Datenbank zu schreiben.

Wie wählen Sie die passende TTL?

Die TTL, also Time to Live, legt fest, wie viele Sekunden ein Key im Cache bleibt. Läuft sie ab, verschwindet der Key. Der nächste Lesezugriff holt dann einen frischen Wert aus der Quelle.

Bei der Wahl stelle ich eine einzige Frage: Wie alt dürfen diese Daten sein, bevor das Geschäft Schaden nimmt? Die folgenden Spannen sind ein Startpunkt aus der Praxiserfahrung, keine Garantie. Messen Sie Ihren eigenen Traffic und passen Sie die Werte an.

• Kategoriemenüs und Einstellungen: Stunden.
• Produktdetails und Blogübersichten: einige Minuten bis eine Stunde.
• Bestand und Preise: Sekunden oder ereignisbasiertes Löschen.
• Sessiondaten: so lange, wie die Sitzung dauert.

Noch ein Tipp: Teilen Tausende Keys exakt dieselbe TTL, laufen sie im selben Moment ab. Das erzeugt eine plötzliche Lastspitze. Ergänzen Sie deshalb jede TTL um eine kleine Zufallsabweichung, oft Jitter genannt.

Warum ist Cache Invalidierung so schwierig?

Invalidierung bedeutet, die veraltete Kopie zu löschen oder zu aktualisieren, sobald sich die Quelldaten ändern. Schwierig ist das, weil ein Datenstück oft über viele Keys verteilt liegt.

Nehmen Sie zum Beispiel eine Preisänderung. Diese betrifft also nicht nur den Key der Produktseite. Auch die Kategorieliste, Suchergebnisse, eine Aktionsseite und die Startseite können diesen Preis enthalten. Vergessen Sie einen davon, sehen Nutzer zwei verschiedene Preise.

In der Praxis setze ich auf drei Ansätze:

• Ereignisbasiertes Löschen: Ändert sich ein Datensatz, löscht Ihr Code die betroffenen Keys ausdrücklich.
• Versionierte Keys: Sie hängen eine Versionsnummer an den Key; ändern sich die Daten, erhöhen Sie die Version, und alte Keys laufen einfach aus.
• Kurze TTL: Brauchen Sie keine perfekte Aktualität, überlassen Sie die Invalidierung allein der TTL.

Kurz gesagt: Halten Sie für jeden neuen Key fest, wer ihn wann löscht. Tun Sie das, bevor der Key live geht, nicht erst nach der ersten Fehlermeldung.

Was ist ein Cache Stampede und wie verhindern Sie ihn?

Ein Cache Stampede entsteht, wenn ein beliebter Key abläuft und Hunderte Anfragen gleichzeitig ins Leere greifen. Alle landen zugleich bei der Datenbank. Diese wird langsamer, weitere Anfragen stauen sich, und das ganze System kann stehen bleiben.

Vor allem passiert das zu Spitzenzeiten, etwa zum Start einer Rabattaktion. Zum Glück sind die Gegenmittel bekannt:

• Sperre nutzen: Bei einem Miss baut nur eine Anfrage den Wert neu auf; die anderen warten kurz oder erhalten den alten Wert.
• Jitter ergänzen: Keys laufen nicht mehr in derselben Sekunde ab.
• Früh erneuern: Ein Hintergrundjob frischt den Wert kurz vor Ablauf auf.
• Alt ausliefern, neu vorbereiten: Nutzer sehen kurz den alten Wert, während ein Worker den neuen berechnet.

In Redis bauen Sie eine einfache Sperre mit dem Befehl SET und seinen Optionen NX und EX. Nur der erste Prozess erhält die Sperre, und sie verfällt nach einer festen Zeit von selbst.

Was passiert, wenn der Cache Speicher voll ist?

Zunächst gilt: Ein Cache arbeitet mit begrenztem RAM. Ist der Speicher voll, muss er Keys entfernen, um Platz zu schaffen. Diesen Vorgang nennt man Eviction; die Eviction Policy entscheidet, welche Keys gehen.

In Redis steuern Sie das über die Einstellung maxmemory und die zugehörige Richtlinie. Laut der Redis Dokumentation zur Eviction lautet die Standardrichtlinie noeviction. Das heißt, Redis löscht bei vollem Speicher nichts, sondern lehnt neue Schreibvorgänge mit einem Fehler ab. Nutzen Sie Redis als reinen Cache, sollten Sie diese Voreinstellung ändern.

• LRU über alle Keys: entfernt den am längsten nicht genutzten Key; ein guter Standard für allgemeines Caching.
• LFU über alle Keys: entfernt den am seltensten genutzten Key.
• Nur Keys mit TTL: wählt ausschließlich unter Keys mit Ablaufzeit.
• noeviction: löscht nichts und lehnt Schreibvorgänge ab.

Memcached entfernt alte Einträge dagegen automatisch nach eigener LRU Logik. Eine Richtlinie müssen Sie dort nicht wählen.

Wie arbeitet Redis im Inneren?

Redis ist ein Server für Datenstrukturen im Arbeitsspeicher, der nach dem Key Value Prinzip arbeitet. Anders als ein schlichter Cache speichert er als Werte nicht nur Zeichenketten, sondern reichhaltige Datentypen.

Konkret unterstützt Redis Strings, Hashes, Listen, Sets, Sorted Sets und Streams. So bilden Sie eine Rangliste mit einem Sorted Set ab, eine Jobwarteschlange mit einer Liste und ein Nutzerprofil mit einem Hash. Sortieren oder Zählen erledigt der Server dann mit einem einzigen Befehl.

Außerdem bietet Redis Persistenz. RDB erstellt in Intervallen Momentaufnahmen, AOF hängt jeden Schreibbefehl an eine Logdatei an. Dadurch laden Sie die Daten nach einem Neustart wieder von der Festplatte.

Befehle führt Redis überwiegend in einem Hauptthread aus; seit Redis 6 können zusätzliche Threads die Netzwerkkommunikation übernehmen. Die Ausführung in einem Thread macht jeden Befehl atomar. Dennoch blockiert ein einzelner langsamer Befehl, etwa KEYS über einen großen Datenbestand, alle anderen Clients.

Wie funktionieren Replikation und Cluster in Redis?

Redis unterstützt Replikation von einem Primärserver auf ein oder mehrere Replikate. Lesezugriffe verteilen Sie auf die Replikate. Mit Sentinel erhalten Sie zudem ein automatisches Failover, wenn der Primärserver ausfällt.

Passen die Daten nicht mehr in den Speicher eines Servers, kommt Redis Cluster ins Spiel. Der Cluster teilt den Schlüsselraum in 16.384 Hash Slots und verteilt diese auf die Knoten. Somit skalieren Sie horizontal über mehrere Maschinen.

Auch die Lizenzlage sollten Sie kennen. Redis wechselte 2024 von der BSD Lizenz zu einer dualen Lizenz aus RSALv2 und SSPLv1; mit Redis 8 kam eine AGPLv3 Option hinzu. Nach dem Wechsel startete unter dem Dach der Linux Foundation der Open Source Fork Valkey. Klären Sie in Unternehmensprojekten gemeinsam mit Ihrer Rechtsabteilung, welche Distribution Sie einsetzen.

Wie funktioniert Memcached?

Memcached ist ein schlanker, mehrfädiger Key Value Store im Arbeitsspeicher, gebaut ausschließlich fürs Caching. Er interpretiert keine Werte. Sie übergeben eine Bytefolge und erhalten genau diese zurück.

Den Speicher verwaltet Memcached in Größenklassen, sogenannten Slabs. Das reduziert Fragmentierung, kann aber Platz verschwenden, wenn Ihre Werte stark in der Größe schwanken. Laut dem Memcached Wiki liegt die maximale Eintragsgröße standardmäßig bei 1 MB, und Keys dürfen bis zu 250 Byte lang sein. Das Limit für Einträge ändern Sie per Startparameter.

Memcached bietet weder Persistenz noch eingebaute Replikation. Die Verteilung auf mehrere Server erfolgt meist auf Clientseite über Consistent Hashing. Anders gesagt entscheidet die Clientbibliothek, welcher Server welchen Key hält.

Diese Schlichtheit ist daher eine Stärke. Mit wenigen Einstellungen sinkt das Risiko einer Fehlkonfiguration, und die Threads verteilen Last gut auf mehrere Prozessorkerne.

Achten Sie auf eine Falle: Geben Sie eine Ablaufzeit von mehr als 30 Tagen an, liest Memcached die Zahl als Unix Zeitstempel statt als Sekunden. Ein falscher Wert lässt den Key dann sofort ablaufen.

Redis oder Memcached: Welche Unterschiede sind entscheidend?

Zunächst arbeiten beide Werkzeuge im Arbeitsspeicher und liefern bei einfachen Aufgaben ähnliche Geschwindigkeit. Der echte Unterschied liegt im Funktionsumfang und im Betriebsmodell. Die Tabelle fasst deshalb die wichtigsten Punkte zusammen.

Vereinfacht gesagt ist Redis ein Schweizer Taschenmesser, Memcached dagegen eine einzelne scharfe Klinge.

Wann wählen Sie Redis und wann Memcached?

Die meisten neuen Projekte starte ich mit Redis. Der Grund ist nicht die reine Geschwindigkeit, sondern dass ein Werkzeug Caching, Sessionspeicher, Warteschlangen und Rate Limiting abdeckt.

Wählen Sie Redis, wenn Sie Datenstrukturen wie sortierte Listen oder Zähler brauchen. Ebenso passt Redis, wenn Daten einen Neustart überstehen müssen oder Sie Echtzeitnachrichten über Pub/Sub planen.

Memcached lohnt sich, wenn Sie nur einen einfachen, flüchtigen Objektcache benötigen. Es passt außerdem, wenn Sie aus einem Server mit vielen Kernen maximalen Durchsatz holen wollen oder Ihr System bereits darauf läuft. Zum Beispiel würde ich eine funktionierende Memcached Installation in einem älteren PHP Projekt nicht nur aus Modegründen ersetzen.

Berücksichtigen Sie schließlich das Wissen Ihres Teams. Ein schlichtes Werkzeug, das Sie gut kennen, ist sicherer als ein mächtiges, das Sie halb verstehen.

In der Cloud bieten verwaltete Dienste wie AWS ElastiCache sowohl Redis kompatible Engines als auch Memcached an. Backups, Patches und Failover übernimmt dann der Anbieter. Für kleine Projekte genügt oft eine einzelne Redis Instanz auf demselben Server.

Worin unterscheidet sich Full Page Caching von Objektcaching?

Full Page Caching speichert die komplette HTML Ausgabe und schickt sie unverändert an den nächsten Besucher. Objektcaching speichert dagegen Teile einer Seite, etwa ein Abfrageergebnis oder ein berechnetes Menü. Die Seite setzt sich dann bei jeder Anfrage aus diesen Teilen zusammen.

Full Page Caching bringt den größten Geschwindigkeitsgewinn, weil Ihr Anwendungscode kaum läuft. Allerdings ist es riskant auf Seiten mit persönlichen Bereichen wie Warenkorb, angemeldetem Nutzernamen oder individuellen Preisen. Deshalb setze ich es für Blogbeiträge, Unternehmensseiten und Kampagnenseiten ein.

Objektcaching ist dagegen flexibler, weil es einzelne Bausteine speichert. Selbst auf personalisierten Seiten lesen Sie gemeinsame Teile wie den Kategoriebaum aus dem Cache. In der Praxis kombinieren Sie beides: ganze Seiten für anonyme Besucher, Objektcaching für angemeldete Nutzer.

Sollten Sie Sessions im Cache speichern?

Ja, in den meisten Fällen, und genau das ist einer der häufigsten Einsätze von Redis. Mit mehreren Anwendungsservern scheitern dateibasierte Sessions, denn jede Anfrage kann auf einem anderen Server landen. Der Nutzer verliert dann seine Sitzung. Ein gemeinsamer Redis Server löst das.

Denken Sie hier trotzdem anders als beim reinen Caching. Verschwindet ein Session Key, wird der Nutzer abgemeldet. Folglich darf Ihre Eviction Policy diese Keys nicht zufällig löschen. Ich lege Sessions meist in eine eigene Redis Instanz oder eine separate logische Datenbank.

Stimmen Sie außerdem die Laufzeit der Sessions auf Ihre Sicherheitsrichtlinie ab. Eine sehr lange Sitzung lässt ein gestohlenes Cookie lange funktionieren.

Wie sichern Sie die Caching Schicht ab?

Cache Server sind auf Tempo ausgelegt, deshalb gerät Sicherheit in Standardinstallationen leicht ins Hintertreffen. Ein offener Redis oder Memcached Server ohne Passwort lädt Angreifer ein, Daten zu lesen oder die Maschine zu missbrauchen.

• Binden Sie den Cache Server nur an ein privates Netz oder an localhost.
• Vergeben Sie in Redis ein Passwort und nutzen Sie ACLs für Rechte pro Nutzer.
• Schließen Sie den Port in der Firewall nach außen.
• Aktivieren Sie TLS, wenn Clients über ein Netzwerk zugreifen.
• Schreiben Sie niemals Kartendaten oder Passwörter in den Cache.

Kurz gesagt: Nehmen Sie die Caching Schicht so ernst wie die Datenbank, denn sie enthält eine Kopie derselben Daten.

Wann ist Caching überflüssig?

Allerdings braucht nicht jedes Projekt einen Cache. Nehmen Sie eine kleine Firmenwebsite mit einigen hundert Besuchen am Tag, deren Abfragen ohnehin in Millisekunden antworten. Dort schafft Caching eine neue Fehlerquelle ohne echten Nutzen.

Auch Anfragen, die jedes Mal ein einzigartiges Ergebnis liefern, etwa persönliche Berichte, profitieren kaum, weil ihre Trefferquote niedrig bleibt. Optimieren Sie zuerst Indizes und Abfragen. Ein fehlender Index bringt oft deutlich mehr als jeder Cache.

Meine Regel ist einfach: Ich ergänze Caching erst, nachdem ich gemessen und den Engpass gefunden habe, nie vorher.

Wie gestalten Sie gute Cache Keys?

Die Gestaltung der Keys wirkt zunächst nebensächlich, doch davon hängt ab, wie leicht Sie invalidieren. Ein guter Key ist also lesbar, eindeutig und vorhersehbar.

Konkret folge ich meist dem Schema "app:objekt:id:version". So verrät "shop:produkt:4521:v3" auf einen Blick, was er enthält. Hängen Inhalte von Sprache oder Währung ab, gehört auch das in den Key. Sonst erhält ein deutscher Besucher womöglich die englische Seite.

Verzichten Sie zudem in der Produktion auf Mustersuchen mit KEYS, weil der Befehl den Server bei großen Datenmengen blockiert. Für Massenlöschungen nutzen Sie stattdessen SCAN oder versionierte Keys. Legen Sie nutzerspezifische Daten nie unter einem gemeinsamen Key ab; das ist der leiseste Weg zu einem Datenleck.

Wie wirkt sich Caching auf Ladezeit und SEO aus?

Caching verkürzt direkt die Zeit bis zum ersten Byte, kurz TTFB. Der Server baut die Seite nicht mehr bei jeder Anfrage aus der Datenbank neu. Also verlässt das HTML den Server früher, und der Browser beginnt früher mit dem Rendern.

Google berücksichtigt die Core Web Vitals als Teil der Page Experience, und eine langsame Serverantwort verschlechtert den LCP. Diesen Zusammenhang erkläre ich ausführlich im Beitrag wie die Ladezeit SEO beeinflusst. Um die Wirkung einer Änderung zu messen, folgen Sie den Schritten aus meinem Leitfaden zum Lighthouse Test.

Außerdem zählt Caching für Crawler der Suchmaschinen. Ein schneller Server erlaubt dem Crawler somit, in derselben Zeit mehr Seiten zu besuchen. Für die übrigen technischen Themen empfehle ich meine Tipps zum technischen SEO.

Welche Caching Fehler sehe ich am häufigsten?

In den Projekten, die ich prüfe, begegnen mir immer wieder dieselben Fehler. Die meisten entstehen durch fehlende Planung, nicht durch technische Grenzen.

1. Alles cachen: selten gelesene Daten füllen den Speicher und verdrängen nützliche Keys.
2. Keine TTL setzen: Keys ohne Ablauf füllen sich langsam mit veralteten Daten.
3. Die Standardrichtlinie behalten: Redis lehnt bei vollem Speicher Schreibvorgänge ab.
4. Persönliche Seiten in einen gemeinsamen Cache legen: der Warenkorb eines Nutzers erscheint womöglich bei einem anderen.
5. Den Cache als Primärspeicher nutzen: ohne Persistenz können kritische Daten verschwinden.
6. Optimieren ohne Messen: ein Cache vor der Analyse der langsamen Abfrage verdeckt das Problem, statt es zu lösen.

Bei Onlineshops nehme ich den letzten Punkt besonders ernst. Solche Infrastrukturentscheidungen treffe ich in der E-Commerce Beratung auf Basis von Messdaten.

Wie messen Sie die Leistung Ihres Caches?

Einem Cache, den Sie nicht messen, können Sie nicht vertrauen. Deshalb empfehle ich, mindestens vier Kennzahlen zu verfolgen.

• Trefferquote: in Redis berechnen Sie sie aus keyspace_hits und keyspace_misses in INFO stats.
• Speichernutzung: zeigt, wie nah Sie an maxmemory liegen; dauerhaft am Limit steigen die Evictions.
• Evictions: wächst evicted_keys schnell, ist der Speicher zu klein oder Sie speichern unnötige Daten.
• Latenz: protokollieren Sie Antwortzeiten für gecachte und ungecachte Anfragen getrennt.

Nutzen Sie außerdem SLOWLOG in Redis, um langsame Befehle zu erkennen. So bemerken Sie früh, wenn ein schwerer Befehl das ganze System ausbremst.

Auf Anwendungsseite hilft es, jeden Cache Aufruf mit einem Etikett zu protokollieren. Sehen Sie etwa, welche Gruppe von Keys am häufigsten verfehlt, wissen Sie sofort, ob Sie die TTL verlängern oder eine Invalidierungsregel korrigieren müssen.

Wo fangen Sie mit einer Caching Strategie an?

Starten Sie zunächst klein. Suchen Sie dann die fünf langsamsten und häufigsten Abfragen Ihrer Anwendung; meist stammt der Großteil der Last von wenigen Abfragen. Dann versehen Sie diese mit Cache Aside und einer kurzen TTL und beobachten die Trefferquote.

Danach schreiben Sie Ihre Invalidierungsregeln auf. Eine Tabelle, die jede Datenänderung den zu löschenden Keys zuordnet, bewahrt neue Entwickler vor Fehlern. Anschließend ergänzen Sie den Schutz vor einem Stampede und ein einfaches Monitoring.

In größeren Architekturen hängt die Cache Schicht auch davon ab, wie Sie das Frontend aufteilen. Das behandle ich im Beitrag über Micro Frontends. Bauen Sie eine neue Website, planen Sie Caching von Anfang an im Webdesign mit ein; das kostet weit weniger als spätere Flickarbeit. Ob Ihre Domain auf den richtigen Server zeigt, prüfen Sie mit der DNS Abfrage. Weiterleitungsketten sehen Sie im Redirect Checker.