A Redis gyorsítótár használata jelentősen javítja az alkalmazások teljesítményét és hatékonyságát, különösen adatlekérdezés esetén. Ugyanakkor ez néhány problémát is hoz. Közülük a legfontosabb probléma az adatok konzisztenciája, amely szigorúan megoldhatatlan. Ha adatkonzisztenciára van szükség, akkor gyorsítótározás nem használható.
További tipikus problémák a gyorsítótár behatolása, a gyorsítótár lavina és a cache lebontás. Jelenleg népszerűbb megoldások is léteznek az iparágban. Ez a cikk nem azért szolgál, hogy ezeket a három problémát tökéletesebben megoldja, és nem is az iparágban népszerű megoldások aláásására. Ehelyett ezeket a három problémajelenséget a tényleges kódműveletből fogjuk bemutatni. Ennek az oka, hogy nehéz egy nagyon élénk fogalmat alkotni a fejben pusztán az akadémiai magyarázatok alapján, és valódi kódbemutatókkal mélyebb lehet megérteni és megérteni ezeket a problémákat.
Cache behatolás
A cache penetráció olyan adatok lekérdezését jelenti, amelyek nem léteznek adatbázisban. Ha a kulcs nem létezik, vagy lejárt, az adatbázist lekérdezik, és a lekérdezés során érintett objektumokat a gyorsítótárba helyezik. Ha az adatbázis lekérdezési objektum üres, akkor nem kerül gyorsagtárba.
Kódáramlás
- paraméter továbbítja az objektum elsődleges kulcsazonosítóját
- A kulcs alapján szerezd meg az objektumot a cache-ből
- Ha az objektum nem üres, közvetlenül visszatér
- Ha az objektum üres, hajtson végre adatbázis-lekérdezést
- Ha az adatbázisból lekérdezett objektum nem üres, tedd a gyorsítótárba (állítsd be a lejárati időt). Képzeld el ezt a helyzetet, mi történne, ha a bejutott paraméter -1 lenne? Ez az -1 egy olyan objektum, amelynek nem szabad léteznie. Az adatbázist minden alkalommal lekérdezik, minden lekérdezés üres lesz, és nem kerül gyorstárba minden alkalommal. Ha rosszindulatú támadás történik, ezt a sebezhetőséget kihasználhatják, hogy nyomást gyakoroljanak az adatbázisra, vagy akár túlterheljék azt. Még ha UUID-t is használunk, könnyű találni egy nem létező KULCSOT és támadni.
A munkámban a null értékek gyorsítótárázásának módszerét fogom használni, vagyis az [kódfolyamat] 5. lépését, ha az adatbázisból kért objektum üres, akkor az is a gyorsítótárba kerül, de a gyorsítótár lejárati ideje rövid, például 60 másodpercre állítom.
Cache lavina
A cache lavina azt jelenti, hogy a cache-készlet egy adott időszakban lejár.
Az egyik oka a lavinának, például amikor ezt a cikket írom, hamarosan a tizenkettedik nap nulla órakora lesz, és hamarosan hullám lesz a gyorsvásárlás hulláma. Aztán hajnali egykor ennek az árukészletnek a készlete lejár. A hozzáférési lekérdezés ezen árutételnek az adatbázisán alapul, és az adatbázisban időszakos nyomáscsúcsok lesznek.
Amikor Xiaobian e-kereskedelmi projekteket végez, általában különböző árukategóriákat alkalmaz, és különböző ciklusokat rejt el. Ugyanabban a kategóriában lévő áruk, plusz egy véletlenszerű tényező. Így a cache lejárati ideje a lehető legtávolabb eloszlik, a népszerű kategóriák termékeinek gyorsítótári ideje hosszabb, és a népszerű kategóriák termékeinek gyorsítótári ideje rövidebb, ami a gyorsítótárkezelő szolgáltatás erőforrásait is megtakaríthatja.
Valójában a központosított lejárat nem túl végzetes, és a legvégzetesebb cache lavina, ha a cache szerver egyik csomópontja leáll vagy megszakad a kapcsolat. Mivel a természetes cache lavina egy adott időszakban kell létrehozni, az adatbázis képes kibírni a nyomást, és ekkor az adatbázis is kibírja a nyomást. Ez nem más, mint időszakos nyomás az adatbázisra. A cache szolgáltatás csomópontjának leállásideje kiszámíthatatlan nyomást gyakorol az adatbázis szerverére, és valószínűleg azonnal túlterhelheti az adatbázist.
Cache bontás
A cache breakdown egy nagyon forró kulcsot jelent, amely folyamatosan nagy egyidejű egyidejű megoldást hordoz, nagy egyidejű egységességgel koncentrál ennek a pontnak a elérésére, amikor ez a kulcs meghibásodik, a folyamatos nagy egyidejű egység áttöri a gyorsítótárt, és közvetlenül az adatbázist kéri, pont úgy, mint amikor egy akadályban lyukat fúrnának.
Amikor Xiaobian e-kereskedelmi projekteket csinált, ezt a terméket "sikerré" tette.
Valójában a legtöbb esetben ilyen robbanásnak nehéz nyomást gyakorolni az adatbázis szerverére. Kevés cég jutott el erre a szintre. Ezért a pragmatikus szerkesztő korán felkészült a fő termékekre, hogy a cache soha ne járjon le. Még ha egyes termékek maguktól is erjesztődnek, beállíthatók úgy, hogy soha nem járnak le.
A főút egyszerű, és a mutex kulcsos kölcsönös elutasító zárat valójában nem használják.
|
Közzétéve 2019. 11. 19. 9:55:04
|
|
|
|
