Förhindra cache-stampeder och thundering herds

Det grundläggande mönstret läser från cachen och frågar databasen vid en miss, för att sedan lagra resultatet. Varje samtidig miss kör denna databasfråga – det är sårbarheten.

Låt endast den första begäran som saknar värdet återskapa det, medan övriga väntar eller använder föråldrade data. Redis SET NX ger exakt en klient ett kortvarigt lås.

Vid en miss:

• Försök hämta låset med SET NX
• Om Ni fick låset frågar Ni databasen och fyller på cachen
• Om inte väntar Ni kort och läser cachen igen

Endast en databasfråga körs per utgång.

Lagra värdet med en logisk utgångstid som infaller tidigare än den fysiska TTL:en. När den logiska tiden har passerat returnerar Ni det föråldrade värdet direkt och uppdaterar det i bakgrunden, så att användarna aldrig behöver vänta vid en miss.

Vid varje begäran uppdateras nyckeln frivilligt före utgången, med en liten sannolikhet som ökar när utgångstiden närmar sig. På så sätt sprids omberäkningen över tid och någon anstormning uppstår aldrig.

Om många nycklar skrivs samtidigt, till exempel vid en driftsättning, löper de också ut samtidigt och orsakar en synkroniserad anstormning. Lägg till slumpmässig jitter i varje TTL så att utgångarna sprids ut.

Ta bort låset efter återskapandet. Ge även låset en kort TTL, så att en kraschad arbetsprocess inte håller det för evigt och blockerar uppdateringar.

Riktlinjer:

• Lås: enklast, fördröjer vissa begäranden kortvarigt
• Stale-while-revalidate: bäst användarupplevelse, kräver uppdatering i bakgrunden
• Probabilistisk utgång + jitter: jämnar ut belastningen, ingen väntan

Kombinera dem för mycket heta nycklar.

En relaterad risk är en miss på grund av cache penetration: många begäranden efter en nyckel som inte finns i databasen missar alltid cachen och överbelastar backend-systemet. Cacha även resultatet ”hittades inte” en kort stund, så att upprepade sökningar fångas upp.

Ni har lärt Er att stoppa cache-stampedes:

• En cache-stampede överbelastar databasen när en het nyckel löper ut
• Ett SET NX-lås för omberäkning begränsar återskapandet till en klient
• Stale-while-revalidate levererar gamla data medan uppdateringen pågår
• Tidig probabilistisk utgång sprider ut omberäkningen
• Jitter för TTL förhindrar synkroniserade massutgångar