Bruken av Redis-cache forbedrer ytelsen og effektiviteten til applikasjoner betydelig, spesielt for dataspørsler. Men samtidig medfører det også noen problemer. Blant dem er det viktigste problemet konsistensen i dataene, som er strengt uløselig. Hvis datakonsistens kreves, kan ikke caching brukes.
Andre typiske problemer er cache-penetrasjon, cache avalanche og cache breakdown. For øyeblikket finnes det også mer populære løsninger i bransjen. Denne artikkelen er ikke ment å løse disse tre problemene mer perfekt, og heller ikke å undergrave de populære løsningene i bransjen. I stedet vil vi demonstrere disse tre problemfenomenene ut fra selve kodeoperasjonen. Grunnen til dette er at det er vanskelig å ha et veldig levende konsept i hodet bare ved å se på den akademiske forklaringen av disse problemene, og med faktiske kodedemonstrasjoner kan du utdype forståelsen og forståelsen av disse problemene.
Cache-penetrasjon
Cache-penetrasjon refererer til å spørre data som ikke finnes i en database. Hvis nøkkelen ikke eksisterer eller nøkkelen har utløpt, blir databasen spørret, og de forespurte objektene legges i cachen. Hvis databasespørringsobjektet er tomt, er det ikke cachet.
Kodeflyt
- parameter passerer primærnøkkel-ID-en til objektet
- Hent objektet fra cachen basert på nøkkelen
- Hvis objektet ikke er tomt, returnerer det direkte
- Hvis objektet er tomt, utfør en databasespørring
- Hvis objektet som spørres i databasen ikke er tomt, legg det i cachen (sett utløpstiden). Tenk deg denne situasjonen, hva ville skje hvis parameteren som sendes inn var -1? Denne -1 er et objekt som ikke må eksistere. Databasen vil bli spurt hver gang, og hver spørring vil være tom, og den vil ikke bli bufret hver gang. Hvis det skjer et ondsinnet angrep, kan denne sårbarheten utnyttes for å legge press på databasen eller til og med overvelde den. Selv om UUID brukes, er det lett å finne en ikke-eksisterende NØKKEL og angripe.
I mitt arbeid vil jeg bruke metoden med å cache nullverdier, det vil si steg 5 i [kodeprosessen], hvis objektet som spørres i databasen er tomt, legges det også i cachen, men utløpstiden for satt cache er kort, for eksempel å sette den til 60 sekunder.
Cache avalanche
Cache-avalanche refererer til utløpet av cache-settet i en viss tidsperiode.
En av grunnene til snøskredet, for eksempel, når du skriver denne artikkelen, vil det snart være klokken null på den tolvte dagen, og det vil snart komme en bølge av rush-kjøp. Så, klokken ett om natten, vil lageret av denne batchen utløpe. Tilgangsspørringen for denne batchen av varer havner i databasen, og for databasen vil det være periodiske trykktopper.
Når Xiaobian gjør e-handelsprosjekter, adopterer han vanligvis ulike kategorier av varer og lagrer ulike sykluser. Varer i samme kategori, pluss en tilfeldig faktor. På denne måten kan cache-utløpstiden fordeles så mye som mulig, og cachetiden for produkter i populære kategorier er lengre, og cachetiden for produkter i upopulære kategorier er kortere, noe som også kan spare ressursene til caching-tjenesten.
Faktisk er sentralisert utløp ikke særlig dødelig, og det mer fatale cache-snøskredet er at en node på cache-serveren går ned eller kobler fra. Fordi cache-avalanchen som naturlig oppstår må skapes i løpet av en viss tidsperiode, kan databasen tåle trykket, og på dette tidspunktet kan også databasen tåle trykket. Det er ikke annet enn periodisk press på databasen. Nedetiden til cache-tjenestenoden skaper uforutsigbart press på databaseserveren, og det er sannsynlig at databasen vil overveldes på et øyeblikk.
Cache-gjennomgang
Cache-nedbrytning refererer til en nøkkel som er veldig varm, som stadig bærer stor samtidighet, stor samtidighet konsentrerer seg om å få tilgang til dette punktet, når denne nøkkelen feiler, bryter kontinuerlig stor samtidighet gjennom cachen og ber direkte om databasen, akkurat som å bore et hull i en barriere.
Da Xiaobian jobbet med netthandelsprosjekter, gjorde han dette produktet til en «suksess».
Faktisk er det i de fleste tilfeller vanskelig å legge et knusende press på databaseserveren med denne typen eksplosjon. Det er få selskaper som har nådd dette nivået. Derfor har den pragmatiske redaktøren forberedt hovedproduktene tidlig, slik at cachen aldri utløper. Selv om noen produkter fermenterer seg selv til hits, kan de settes som aldri utløpende.
Hovedveien er enkel, og mutex-nøkkelens gjensidige avvisningslås brukes egentlig ikke.
|
Publisert på 19.11.2019 09:55:04
|
|
|
|
