Brugen af Redis-cache forbedrer ydeevnen og effektiviteten af applikationer betydeligt, især til dataforespørgsler. Men samtidig medfører det også nogle problemer. Blandt dem er det vigtigste problem dataenes konsistens, som er strengt uløselig. Hvis datakonsistens er nødvendig, kan caching ikke anvendes.
Andre typiske problemer er cache-penetration, cache-lavine og cache-nedbrud. I øjeblikket findes der også mere populære løsninger i branchen. Denne artikel har ikke til formål at løse disse tre problemer mere perfekt, og den skal heller ikke undergrave de populære løsninger i branchen. I stedet vil vi demonstrere disse tre problemfænomener ud fra selve kodeoperationen. Grunden til dette er, at det er svært at have et meget levende koncept i hovedet blot ved at se på den akademiske forklaring af disse problemer, og med faktiske kodedemonstrationer kan man uddybe sin forståelse og forståelse af disse problemer.
Cache-penetration
Cache-penetration refererer til forespørgsler på data, der ikke findes i en database. Hvis nøglen ikke eksisterer, eller nøglen er udløbet, bliver databasen forespurgt, og de forespurgte objekter lægges i cachen. Hvis databaseforespørgselsobjektet er tomt, er det ikke cachet.
Kodeflow
- parameter overfører objektets primærnøgle-ID
- Få objektet fra cachen baseret på nøglen
- Hvis objektet ikke er tomt, returnerer det direkte
- Hvis objektet er tomt, udfør en databaseforespørgsel
- Hvis objektet, der forespørges fra databasen, ikke er tomt, læg det i cachen (sæt udløbstiden). Forestil dig denne situation, hvad ville der ske, hvis parameteren, der blev sendt ind, var -1? Denne -1 er et objekt, der ikke må eksistere. Databasen vil blive forespurgt hver gang, og hver forespørgsel vil være tom, og den vil ikke blive cachet hver gang. Hvis der sker et ondsindet angreb, kan denne sårbarhed udnyttes til at lægge pres på databasen eller endda overbelaste den. Selv hvis UUID bruges, er det nemt at finde en ikke-eksisterende KEY og angribe.
I mit arbejde vil jeg bruge metoden med at cache nullværdier, altså trin 5 i [kodeprocessen], hvis objektet, der forespørges fra databasen, er tomt, lægges det også i cachen, men den satte cache-udløbstid er kort, for eksempel ved at sætte den til 60 sekunder.
Cache avalanche
Cache-lavine refererer til, at cache-sættet udløber i en bestemt periode.
En af grundene til lavinen er for eksempel, at når man skriver denne artikel, vil klokken snart være nul på den tolvte dag, og der vil snart komme en bølge af hastkøb. Så klokken et om natten udløber lageret af denne batch varer. Adgangsforespørgslen for denne batch af varer ligger i databasen, og for databasen vil der være periodiske tryktoppe.
Når Xiaobian laver e-handelsprojekter, adopterer han generelt forskellige kategorier af varer og gemmer forskellige cyklusser. Varer i samme kategori, plus en tilfældig faktor. På denne måde kan cache-udløbstiden fordeles så meget som muligt, og cachetiden for produkter i populære kategorier er længere, og cachetiden for produkter i upopulære kategorier er kortere, hvilket også kan spare caching-tjenestens ressourcer.
Faktisk er centraliseret udløb ikke særlig dødeligt, og den mere fatale cache-lavine er, at en node på cacheserveren går ned eller afbrydes. Fordi cache-lavinen, der naturligt opstår, skal skabes inden for en bestemt periode, kan databasen modstå trykket, og på dette tidspunkt kan databasen også modstå presset. Det er ikke andet end periodisk pres på databasen. Nedetiden for cache-servicenoden skaber uforudsigeligt pres på databaseserveren, og det vil sandsynligvis overbelaste databasen på et øjeblik.
Cache-gennembrud
Cache-nedbrydning refererer til en nøgle, der er meget varm, konstant bærer stor samtidighed, stor samtidighed koncentrerer sig om at få adgang til dette punkt; når denne nøgle fejler, bryder kontinuerlig stor samtidighed gennem cachen og anmoder direkte databasen, ligesom at bore et hul i en barriere.
Da Xiaobian lavede e-handelsprojekter, gjorde han dette produkt til et "hit".
Faktisk er denne form for eksplosion i de fleste tilfælde svær at lægge knusende pres på databaseserveren. Der er få virksomheder, der har nået dette niveau. Derfor har den pragmatiske editor forberedt hovedprodukterne tidligt, så cachen aldrig udløber. Selv hvis nogle produkter fermenterer sig selv til hits, kan de sættes til aldrig at udløbe.
Hovedvejen er enkel, og mutex-nøglen til gensidig afvisningslås bruges faktisk ikke.
|
Opslået på 19/11/2019 09.55.04
|
|
|
|
