Utilizarea cache-ului Redis îmbunătățește semnificativ performanța și eficiența aplicațiilor, în special pentru interogarea datelor. Dar, în același timp, aduce și unele probleme. Dintre acestea, cea mai importantă problemă este consistența datelor, care este strict nerezolvabilă. Dacă este necesară consistența datelor, atunci cache-ul nu poate fi folosit.
Alte probleme tipice sunt penetrarea cache-ului, avalanșa cache-ului și destructurarea cache-ului. În prezent, există și soluții mai populare în industrie. Acest articol nu este menit să rezolve aceste trei probleme mai perfect, nici să submineze soluțiile populare din industrie. În schimb, vom demonstra aceste trei fenomene problematice din operațiunea efectivă a codului. Motivul pentru care faci asta este că este dificil să ai un concept foarte viu în minte doar uitându-te la explicația academică a acestor probleme, iar cu demonstrații reale de cod, poți aprofunda înțelegerea și înțelegerea acestor probleme.
Penetrarea cache-ului
Penetrarea cache-ului se referă la interogarea datelor care nu există într-o bază de date. Dacă cheia nu există sau cheia a expirat, baza de date este interogată, iar obiectele interogate sunt introduse în cache. Dacă obiectul de interogare a bazei de date este gol, acesta nu este stocat în cache.
Flux de cod
- Parameter care trece ID-ul cheie primară al obiectului
- Obține obiectul din cache pe baza cheii
- Dacă obiectul nu este gol, returnează direct
- Dacă obiectul este gol, efectuați o interogare în baza de date
- Dacă obiectul interogat din baza de date nu este gol, pune-l în cache (setează timpul de expirare). Imaginează-ți această situație, ce s-ar întâmpla dacă parametrul introdus ar fi -1? Acest -1 este un obiect care nu trebuie să existe. Baza de date va fi interogată de fiecare dată, iar fiecare interogare va fi goală și nu va fi stocată în cache de fiecare dată. Dacă are loc un atac malițios, această vulnerabilitate poate fi exploatată pentru a pune presiune pe baza de date sau chiar pentru a o copleși. Chiar dacă se folosește UUID, este ușor să găsești o cheie inexistentă și să ataci.
În munca mea, folosesc metoda de stocare a valorilor nulle, adică pasul 5 din [proces de cod], dacă obiectul interogat din baza de date este gol, acesta este de asemenea introdus în cache, dar timpul de expirare setat este scurt, de exemplu setarea la 60 de secunde.
Avalanșă de cache
Avalanșa cache-ului se referă la expirarea setului cache-ului într-o anumită perioadă de timp.
Unul dintre motivele avalanșei, de exemplu, când scriu acest articol, va fi în curând la ora zero în a douăsprezecea zi și va urma curând un val de cumpărături în grabă. Apoi, la ora unu dimineața, depozitul acestui lot de marfă va expira. Interogarea de acces pentru acest lot de bunuri cade în baza de date, iar pentru aceasta vor exista periodic picuri de presiune.
Când Xiaobian realizează proiecte de comerț electronic, adoptă în general categorii diferite de bunuri și stochează cicluri diferite. Bunuri din aceeași categorie, plus un factor aleatoriu. Astfel, timpul de expirare a cache-ului poate fi dispersat cât mai mult posibil, iar timpul de cache al produselor din categoriile populare este mai lung, iar timpul de cache al produselor din categoriile nepopulare este mai scurt, ceea ce poate economisi și resursele serviciului de cache.
De fapt, expirarea centralizată nu este foarte fatală, iar avalanșa mai fatală a cache-ului este că un nod al serverului cache se oprește sau se deconectează. Deoarece avalanșa de cache care apare în mod natural trebuie creată într-o anumită perioadă de timp, atunci baza de date poate rezista presiunii, iar în acest moment, și baza de date poate rezista presiunii. Nu este altceva decât o presiune periodică asupra bazei de date. Timpul de nefuncționare al nodului de serviciu cache provoacă o presiune imprevizibilă asupra serverului de baze de date și este probabil să copleșească baza de date într-o clipă.
Decompunerea cache-ului
Degradarea cache-ului se referă la o cheie foarte fierbinte, care transportă constant o concurență mare, concurența mare se concentrează pe accesarea acestui punct, iar când această cheie eșuează, concurența mare continuă străpunge cache-ul și solicită direct baza de date, exact ca și cum ai fora o gaură într-o barieră.
Când Xiaobian făcea proiecte de comerț electronic, a transformat acest produs într-un "hit".
De fapt, în majoritatea cazurilor, acest tip de explozie este dificil de pus sub o presiune copleșitoare asupra serverului de baze de date. Puține companii au atins acest nivel. Prin urmare, editorul pragmatic s-a pregătit pentru produsele principale din timp, astfel încât cache-ul să nu expire niciodată. Chiar dacă unele produse fermentează singure în fumuri, acestea pot fi setate ca fiind niciodată de expirare.
Drumul principal este simplu, iar încuietoarea cu respingere mutuală a cheii mutex nu este folosită.
|
Postat pe 19.11.2019 09:55:04
|
|
|
|
