Použití cache Redis výrazně zlepšuje výkon a efektivitu aplikací, zejména při dotazování dat. Ale zároveň to přináší i určité problémy. Mezi nimi je nejdůležitějším problémem konzistence dat, která je zcela neřešitelná. Pokud je vyžadována konzistence dat, nelze cache použít.
Dalšími typickými problémy jsou průnik cache, lavina cache a rozpad cache. V současnosti existují také populárnější řešení v oboru. Tento článek nemá za cíl tyto tři problémy řešit dokonaleji, ani nemá podkopávat populární řešení v oboru. Místo toho předvedeme tyto tři problémové jevy z reálné operace kódu. Důvodem je, že je těžké mít v hlavě velmi živý koncept jen tím, že se pohledem na akademické vysvětlení těchto problémů, a skutečnými ukázkami kódu můžete prohloubit své porozumění a porozumění těmto problémům.
Průnik cache
Průnik do cache označuje dotazování dat, která v databázi neexistují. Pokud klíč neexistuje nebo klíč vypršel, databáze je dotazována a dotazované objekty jsou vloženy do cache. Pokud je objekt dotazu do databáze prázdný, není uložen do mezipaměti.
Tok kódu
- parametr předává primární klíčové ID objektu
- Získejte objekt z cache na základě klíče
- Pokud objekt není prázdný, vrátí se přímo
- Pokud je objekt prázdný, proveďte databázový dotaz
- Pokud objekt dotazovaný z databáze není prázdný, vložte ho do cache (nastavte čas expirace). Představte si tuto situaci, co by se stalo, kdyby parametr vložený byl -1? Tento -1 je objekt, který nesmí existovat. Databáze bude dotazována pokaždé, každý dotaz bude prázdný a nebude pokaždé uložena do mezipaměti. Pokud dojde k škodlivému útoku, tato zranitelnost může být zneužita k vyvíjení tlaku na databázi nebo ji dokonce přetížení. I když se použije UUID, je snadné najít neexistující KLÍČ a zaútočit.
Ve své práci použiji metodu ukládání nulových hodnot do cache, tedy krok 5 v [kódovém procesu], pokud je objekt dotazovaný z databáze prázdný, je také vložen do cache, ale nastavená doba expirace cache je krátká, například při nastavení na 60 sekund.
Lavina cache
Lavina cache označuje vypršení sady cache během určitého časového období.
Jedním z důvodů laviny, například, když píšete tento článek, brzy bude v nule dvanáctého dne a brzy přijde vlna rychlého nákupu. Pak ve jednu hodinu ráno vyprší zásoba tohoto zboží. Přístupový dotaz pro tuto dávku zboží je na databázi a pro databázi budou periodické tlakové špičky.
Když Xiaobian dělá e-commerce projekty, obvykle přijímá různé kategorie zboží a uchovává různé cykly. Zboží ve stejné kategorii, plus náhodný faktor. Tímto způsobem lze co nejvíce rozprostřel dobu expirace cache, čas cache produktů v populárních kategoriích je delší a cache produktů v nepopulárních kategoriích kratší, což může také šetřit zdroje cacheovací služby.
Ve skutečnosti není centralizované vypršení příliš smrtelné a ještě smrtelnější lavina cache je, že jeden uzel cache serveru vypadne nebo se odpojí. Protože přirozeně vznikající lavina cache musí být vytvořena v určitém časovém období, databáze může tlak odolat a v této době může vydržet i tento tlak. Je to nic jiného než periodický tlak na databázi. Výpadek uzlu cache service způsobuje nepředvídatelný tlak na databázový server a je pravděpodobné, že databázi okamžitě přetíží.
Rozklad cache
Rozpad cache označuje klíč, který je velmi horký, neustále nese velkou souběžnost, velká souběžnost se soustředí na přístup k tomuto bodu, když tento klíč selže, kontinuální velká souběžnost prolomí cache a přímo požaduje databázi, stejně jako když vrtáte díru do bariéry.
Když Xiaobian dělal e-commerce projekty, udělal z tohoto produktu "hit".
Ve většině případů je takový výbuch obtížný vyvinout drtivý tlak na databázový server. Jen málo společností dosáhlo této úrovně. Proto pragmatický editor připravil hlavní produkty včas, aby cache nikdy nevypršela. I když se některé produkty samy fermentují do dávky, lze nastavit, že nikdy neexpirují.
Hlavní silnice je jednoduchá a mutex klíčový vzájemný odmítací zámek se opravdu nepoužívá.
|
Zveřejněno 19.11.2019 9:55:04
|
|
|
|
