Användningen av Redis-cache förbättrar prestandan och effektiviteten hos applikationer avsevärt, särskilt vid datasökningar. Men samtidigt medför det också vissa problem. Bland dessa är det viktigaste problemet datans konsistens, vilket är strikt olösligt. Om datakonsistens krävs kan caching inte användas.
Andra typiska problem är cachepenetration, cachelavin och cachebreakdown. För närvarande finns det också mer populära lösningar i branschen. Denna artikel är inte till för att lösa dessa tre problem mer perfekt, och den är inte heller för att undergräva de populära lösningarna i branschen. Istället kommer vi att demonstrera dessa tre problemfenomen utifrån själva kodoperationen. Anledningen till detta är att det är svårt att ha ett mycket levande koncept i huvudet bara genom att titta på den akademiska förklaringen av dessa problem, och med faktiska koddemonstrationer kan du fördjupa din förståelse och förståelse av dessa problem.
Cachepenetration
Cachepenetration avser att söka data som inte finns i en databas. Om nyckeln inte existerar eller om nyckeln har gått ut, frågas databasen och de efterfrågade objekten läggs i cachen. Om databasfrågeobjektet är tomt är det inte cachas.
Kodflöde
- parameterpassa primärnyckel-ID:t för objektet
- Hämta objektet från cachen baserat på nyckeln
- Om objektet inte är tomt, returnerar det direkt
- Om objektet är tomt, utför en databasfråga
- Om objektet som efterfrågas från databasen inte är tomt, lägg det i cachen (sätt utgångstiden). Föreställ dig denna situation, vad skulle hända om parametern som skickas in var -1? Detta -1 är ett objekt som inte får existera. Databasen kommer att förfrågas varje gång, och varje fråga kommer att vara tom, och den kommer inte att cachelagras varje gång. Om det sker en illvillig attack kan denna sårbarhet utnyttjas för att sätta press på databasen eller till och med överbelasta den. Även om UUID används är det lätt att hitta en icke-existerande KEY och attackera.
I mitt arbete använder jag metoden att cacha nollvärden, det vill säga steg 5 i [kodprocessen], om objektet som efterfrågas från databasen är tomt, läggs det också i cachen, men den inställda cachens utgångstid är kort, till exempel att sätta den till 60 sekunder.
Cache avalanche
Cachelavin avser att cache-setet går ut under en viss tidsperiod.
En av anledningarna till lavinen, till exempel, när du skriver denna artikel är att det snart kommer att vara klockan noll på den tolfte dagen, och snart kommer en våg av snabbköp. Sedan, klockan ett på natten, går lagret av denna batch varor ut. Åtkomstfrågan för denna batch av varor hamnar i databasen, och för databasen kommer det att finnas periodiska trycktoppar.
När Xiaobian gör e-handelsprojekt använder han vanligtvis olika kategorier av varor och lagrar olika cykler. Varor i samma kategori, plus en slumpfaktor. På detta sätt kan cachens utgångstid fördelas så mycket som möjligt, och cachetiden för produkter i populära kategorier är längre, och cachetiden för produkter i opopulära kategorier är kortare, vilket också kan spara resurser för cachetjänsten.
Faktum är att centraliserad utgång inte är särskilt dödlig, och den mer dödliga cachelavinen är att en nod på cacheservern går ner eller kopplas bort. Eftersom cachelavinen som naturligt uppstår måste skapas under en viss tidsperiod, kan databasen stå emot trycket, och vid denna tidpunkt kan även databasen stå emot trycket. Det är inget annat än periodiskt tryck på databasen. Driftstoppet för cache-tjänstnoden orsakar oförutsägbar press på databasservern, och det är sannolikt att databasen överbelastas omedelbart.
Cache-genombrott
Cache-breakdown avser en nyckel som är mycket het, ständigt bär på stor samtidighet, stor samtidighet koncentrerar sig på att nå denna punkt, när denna nyckel fallerar bryter kontinuerlig stor samtidighet igenom cachen och begär direkt databasen, precis som att borra ett hål i en barriär.
När Xiaobian gjorde e-handelsprojekt gjorde han denna produkt till en "succé".
Faktum är att i de flesta fall är denna typ av explosion svår att sätta förkrossande tryck på databasservern. Det finns få företag som har nått denna nivå. Därför har den pragmatiske redaktören förberett sig för huvudprodukterna tidigt, så att cachen aldrig går ut. Även om vissa produkter jäser sig själva till hits kan de ställas in som aldrig utgångsdatum.
Huvudvägen är enkel, och mutex-nyckelns ömsesidiga avvisningslås används egentligen inte.
|
Publicerad på 2019-11-19 09:55:04
|
|
|
|
