Uporaba Redis predpomnilnika močno izboljša zmogljivost in učinkovitost aplikacij, zlasti pri poizvedbah po podatkih. A hkrati prinaša tudi nekaj težav. Med njimi je najpomembnejši problem konsistentnost podatkov, ki je strogo nerešljiva. Če je potrebna konsistentnost podatkov, predpomnjenja ni mogoče uporabiti.
Drugi tipični problemi so prodor v predpomnilnik, plaz predpomnilnika in razpad predpomnilnika. Trenutno obstajajo tudi bolj priljubljene rešitve v industriji. Ta članek ni namenjen popolnejši rešitvi teh treh problemov, prav tako ne spodkopava priljubljenih rešitev v industriji. Namesto tega bomo prikazali te tri problemske pojave iz dejanske kode. Razlog za to je, da je težko imeti zelo živ koncept v glavi samo z akademsko razlago teh problemov, in z dejanskimi demonstracijami kode lahko poglobite svoje razumevanje in razumevanje teh problemov.
Prodor v predpomnilnik
Prodor v predpomnilnik se nanaša na poizvedovanje podatkov, ki v podatkovni bazi ne obstajajo. Če ključ ne obstaja ali je ključ potekel, se podatkovna baza izvede in poizvedbeni objekti se vnesejo v predpomnilnik. Če je objekt poizvedbe v podatkovni bazi prazen, ni predpomnjen.
Potek kode
- parameter posreduje primarni ključni ID objekta
- Pridobi objekt iz predpomnilnika na podlagi ključa
- Če objekt ni prazen, se vrne neposredno
- Če je objekt prazen, izvedemo poizvedbo v bazi podatkov
- Če objekt, ki ga poizvedujete iz baze, ni prazen, ga dajte v predpomnilnik (nastavite čas poteka). Predstavljajte si to situacijo, kaj bi se zgodilo, če bi bil podani parameter -1? Ta -1 je objekt, ki ne sme obstajati. Baza podatkov bo vsakič poizvedovana, vsaka poizvedba bo prazna in ne bo vsakič predpomnjena. Če pride do zlonamernega napada, se ta ranljivost lahko izkoristi za pritisk na bazo podatkov ali celo za njeno preobremenitev. Tudi če se uporablja UUID, je enostavno najti neobstoječi KLJUČ in napasti.
Pri svojem delu bom uporabil metodo predpomnjenja ničelnih vrednosti, torej korak 5 v [procesu kodiranja], če je objekt, ki ga poizvedujemo iz baze, prazen, se tudi ta shrani v predpomnilnik, vendar je čas poteka predpomnilnika kratek, na primer nastavitev na 60 sekund.
Plaz predpomnilnika
Plaz predpomnilnika se nanaša na potek nabora predpomnilnika v določenem časovnem obdobju.
Eden od razlogov za plaz, na primer, ko pišem ta članek, je, da bo kmalu ob ničli zvečer na dvanajsti dan, in kmalu bo sledil val hitrega nakupovanja. Potem bo ob eni zjutraj zaloga tega blaga potekla. Dostopna poizvedba za to serijo dobrin pade na bazo podatkov, za bazo pa bodo občasni pritiskovni vrhovi.
Ko Xiaobian izvaja e-trgovinske projekte, običajno sprejema različne kategorije blaga in shranjuje različne cikle. Blago v isti kategoriji, plus naključni dejavnik. Na ta način je mogoče čas poteka predpomnilnika čim bolj razpršiti, čas predpomnilnika izdelkov v priljubljenih kategorijah je daljši, čas predpomnilnika izdelkov v manj priljubljenih kategorijah pa krajši, kar lahko prav tako prihrani vire storitve predpomnjenja.
Pravzaprav centraliziran potek ni zelo usoden, še bolj usoden plaz predpomnilnika pa je, da vozlišče strežnika predpomnilnika pade ali se odklopi. Ker mora naravno nastanek plazu predpomnilnika nastati v določenem časovnem obdobju, lahko podatkovna baza prenese pritisk, v tem času pa lahko prenese tudi pritisk. To ni nič drugega kot občasni pritisk na bazo podatkov. Izpad vozlišča za storitve predpomnilnika povzroča nepredvidljiv pritisk na strežnik podatkovne baze in verjetno bo v trenutku preobremenil bazo podatkov.
Razčlenitev predpomnilnika
Razčlenitev predpomnilnika se nanaša na ključ, ki je zelo vroč in nenehno prenaša veliko sočasnost; velika sočasnost se osredotoča na dostop do te točke; ko ta ključ odpove, neprekinjena velika sočasnost prebije predpomnilnik in neposredno zahteva bazo podatkov, podobno kot vrtanje luknje v pregradi.
Ko je Xiaobian izvajal e-trgovinske projekte, je ta izdelek naredil za "uspešnico".
Pravzaprav je v večini primerov takšna eksplozija težko povzročiti uničujoč pritisk na strežnik baze podatkov. Le malo podjetij je doseglo to raven. Zato je pragmatični urejevalnik za glavne izdelke pripravil zgodaj, da predpomnilnik nikoli ne poteče. Tudi če se nekateri izdelki fermentirajo v udarce, jih lahko nastavimo tako, da nikoli ne potekajo.
Glavna cesta je preprosta, mutex ključ za medsebojno zavrnitev pa se pravzaprav ne uporablja.
|