Laufen die Cache-Einträge beliebter Daten gleichzeitig ab, stürzen sich Tausende Anfragen auf einmal auf die DB.
Warum Beliebte Daten in Redis o. Ä. laufen gleichzeitig ab → Folge Anfragen, die dieselben Daten neu erzeugen wollen, landen alle gleichzeitig bei der DB → Auf dem Bildschirm Überlastete DB, mehrere Funktionen werden nacheinander langsam oder stehen still
Ablaufzeitpunkte zufällig streuen, nur eine Anfrage aktualisieren lassen und die übrigen mit dem alten Wert bedienen.
Aufgaben Infrastrukturteam
Replikate und automatisches Failover einrichten, damit der Cache bei Neustart oder Ausfall von Redis nicht komplett leer ist, prüfen, ob die DB genug Reserven hat, um auch einen leeren Cache zu verkraften.
Im Graphen
Spitzen in festen Abständen · Cache-Trefferquote, DB-Queries pro Sekunde
Wo nachsehen
keyspace_hits und keyspace_misses (Trefferquote), expired_keys und Neustarts (uptime_in_seconds) aus Redis INFO über die DB-Queries pro Sekunde legen und zählen, wie viele gleiche Queries in diesem Moment gleichzeitig auf der DB laufen (MySQL SHOW PROCESSLIST, PostgreSQL pg_stat_activity)
Spricht dafür
Schießen die Cache-Misses schlagartig hoch, steigt die Zahl der DB-Queries mit, und die meisten gleichzeitig laufenden Queries sind dieselbe Query auf dieselben Daten. Fällt mit dem Ablaufintervall beliebter Keys oder einem Redis-Neustart zusammen
Spricht dagegen
Cache-Misses normal, nur die DB-Queries steigen: Login-Ansturm (db-login-storm) oder Batch-Job (db-batch)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Dasselbe passiert, wenn Redis neu startet oder der Cache durch einen Ausfall komplett leer ist. Besonders gefährdet sind Architekturen, deren DB im Vertrauen auf den Cache knapp dimensioniert ist.
Quellen
Scaling Memcache at Facebook (NSDI '13)USENIX Wird ein häufig genutzter Key invalidiert, landen viele Lesezugriffe bei der DB (Thundering Herd); Gegenmittel sind Leases (nur ein Client aktualisiert) und die Rückgabe veralteter Werte, Cluster mit leerem Cache werden separat vorgewärmt
Optimal Probabilistic Cache Stampede PreventionVLDB Endowment Laufen beliebte Einträge ab, erzeugen mehrere Anfragen sie gleichzeitig neu (Cache-Stampede); Gegenmittel ist eine probabilistische vorzeitige Aktualisierung vor dem Ablauf
INFORedis keyspace_hits und keyspace_misses (erfolgreiche und fehlgeschlagene Key-Lookups), expired_keys (abgelaufene Keys), uptime_in_seconds (Zeit seit dem Start)
SHOW PROCESSLIST StatementMySQL Je Session die laufende Anweisung (Info) und die Verweildauer im aktuellen Zustand (Time, in Sekunden)