Kratko o lavini keša, prodiranju keša i proboju keša

Kao backend programer, mislim da je keš nešto što svima dobro poznajemo.

U ovom članku predstaviću poslovnu pozadinu lavine keša, prodiranja keša i proboja keša, rešenja i obradu pouzdanosti sistema. Unapred napominjem da najbolje rešenje obavezno mora biti prilagođeno stvarnom poslu — različiti poslovi se ne rešavaju na potpuno isti način.

Zapravo, na internetu sam već video dosta tekstova o lavini keša, prodiranju i proboju keša. Ne znam da li je razlog tome što se bavimo različitim poslovima, ali primetio sam da mnogi drugovi imaju sledeća pitanja, na primer:

Ako se doda slučajno vreme isticanja, a vreme pristupa padne baš na podatke sa dodatim slučajnim vremenom, zar to slučajno vreme nije dodato uzalud?
Ako vrući podaci ne ističu, zar neće nastajati sve više prljavih podataka?

Sva ova pitanja će biti objašnjena jedan po jedan u nastavku. Svaki put kada se pomene keš, mislim na Redis.

Potrudiću se da ovu čestu temu sa intervjua objasnim jasno. Ako nakon čitanja budete mogli slobodno i opušteno da pričate o ovoj oblasti pred intervjuerom, onda ste najveći majstor.

Dakle, krećemo sa glavnom temom.

1. Lavina keša

Lavina keša znači da keš istovremeno u velikoj meri ističe. U tom trenutku pristiže ogroman talas zahteva koji se razbija o bazu podataka, i na kraju baza ne uspeva da ih obradi te pada.

1.1 Primer poslovnog scenarija

Početna stranica aplikacije sadrži mnogo vrućih podataka, i za vreme neke velike promocije potrebno je prikazivati različite podatke na početnoj stranici za različite vremenske intervale.

Na primer, u ponoć je potrebno zameniti podatke na početnoj stranici novima. Tada stari podaci ističu, a novi podaci se tek počinju učitavati.

A u ponoć istovremeno počinje i manja promocija, pa pristiže veliki broj zahteva. Pošto su se novi podaci tek počeli učitavati, većina zahteva ne pronalazi pogodak u kešu, pa idu direktno u bazu podataka, i konačno baza pada.

1.2 Rešenje

Naglašavam još jednom, tzv. rešenje se mora prilagođavati stvarnom poslu, i različiti poslovi se ne rešavaju na potpuno isti način.

1.2.1 Prvi metod

Uobičajen pristup je dodavanje slučajnog vremena na vreme isticanja.

Imajte na umu da to slučajno vreme nije par sekundi — može trajati i po nekoliko minuta. Jer ako je količina podataka velika, kao u gornjem primeru, a Redis obrađuje podatke jednonitno, onda par sekundi bafera ne mora nužno da garantuje da će svi novi podaci biti učitani.

Zato je bolje postaviti duže vreme isticanja nego kraće. Na kraju će ionako isteći, krajnji efekat je isti.

Pored toga, ako se opseg vremena isticanja proširi, ključevi će biti više raspršeni, što takođe do izvesne mere skraćuje vreme blokiranja Redis-a prilikom brisanja isteklih ključeva.

Što se tiče onoga što je rečeno na početku članka: „Ako vreme pristupa padne baš na podatke sa dodatim slučajnim vremenom, zar to slučajno vreme nije dodato uzalud?"

Sada kada to kombinujete sa gornjim primerom promocije, da li je to još uvek problem? Vezujte se za posao, obavezno se vezujte za posao.

1.2.2 Drugi metod

Dodati mutex bravu, ali ovo rešenje dovedi do očiglednog pada propusnosti. Zato opet zavisi od stvarnog posla; u gornjem primeru nije pogodno.

1.2.3 Treći metod

Vrućim podacima se ne postavlja vreme isticanja. Ako ne ističu, normalni poslovni zahtevi prirodno neće stizati do baze podataka.

Ali onda se javlja novi problem — ako ne ističu, ima prljavih podataka, šta onda?

Jednostavno, obrišite ih nakon što se cela promocija završi.

Kako onda obraditi gornji primer? — Izabrati prvi metod; ili unapred učitati nove podatke za ponoć u Redis, ne mora se čekati ponoć da se učitaju, i to je takođe prihvatljivo.

2. Proboj keša

Proboj keša znači da nakon što jedan vrući ključ istekne ili bude obrisan, zahtevi koji su pre mogli da ga pronađu u kešu odjednom u velikom broju idu na bazu podataka, i konačno dovode do pada baze.

Podseća na onu „mala rupa, veliki brod potopi".

2.1 Primer poslovnog scenarija

Pojava je obično posledica greške u radu, na primer pogrešno postavljeno vreme isticanja ili slučajno brisanje.

Ko bar jednom nije napravio grešku u radu? Čuli ste ono „obriši bazu i pobegni". Ja sam svakako jednom slučajno obrisao podatke iz test baze, srećom prošlo je bez posledica (da se šalim).

2.2 Rešenje

Prvi metod

Za probleme u kodu, odradite code review kako treba.

Da li vrući podaci uopšte treba da ističu, i kada tačno treba da isteknu — to mora biti jasno.

Pošto su to vrući podaci, velika je verovatnoća da pripadaju jezgru procesa. Onda ono što se mora garantovati u jezgru i dalje se mora garantovati, kako bi se smanjile šanse za greške. Ako nešto krene po zlu, sledi talas korisničkih žalbi.

Drugi metod

Za stvari poput grešaka u produkciji, ojačajte upravljanje dozvolama gde treba — posebno produkcione dozvole, obavezno mora postojati pregled/odobrenje, kako bi se izbegla „drhtava ruka".

3. Prodiranje keša

Prodiranje keša znači: klijent zahteva podatke koji ne postoje ni u kešu ni u bazi podataka, što dovodi do toga da svi zahtevi idu na bazu. Ako je zahteva mnogo, baza će ionako vrlo lepo pasti.

3.1 Primer poslovnog scenarija

Primarni ključ id u bazi je uvek pozitivan broj, ali klijent pošalje upit sa id = -1
Jedan interfejs za upit ima polje status, gde 0 znači početak, a 1 znači kraj. Ali stalno pristižu zahtevi sa status=3

3.2 Rešenje

3.2.1 Prvi metod

Dobro odradite validaciju parametara; za nerazumne parametre odmah uradite return i završite.

Ovo je veoma važno i važi za svaki posao — za backend mora postojati princip međusobnog nepoverenja.

Jednostavno rečeno: ne verujte podacima iz zahteva koji dolaze sa frontenda, klijenta ili uzvodnih servisa; validacija koja se mora odraditi, mora se odraditi.

Jer nikada ne znate kakve čudne podatke će korisnik uneti; ili čak iako ste se sa kolegom sa kojim se integrišete dogovorili kako se prosleđuju parametri, ne možete biti sigurni da će se toga pridržavati; a još jedan korak nazad — šta ako interfejs bude provaljen?

Morate da se zaštitite. Jer kada do problema dođe, pa kažete šefu da je kriv taj-i-taj što se nije pridržavao dogovora oko parametara, ili da niste računali da će korisnik tako popuniti polje — vidite šta će vam šef na to odgovoriti (smeško.jpg).

3.2.2 Drugi metod

I ključeve za koje se ne pronađu podaci, kratko keširajte.

Na primer 30s. Tako se izbegava da veliki broj istih zahteva odjednom pada na bazu, i smanjuje se pritisak.

Ali kasnije svakako treba ispitati zašto uopšte postoje takvi podaci i rešiti problem iz korena; ovaj metod ga samo ublažava.

Ako se ustanovi da upravo određene IP adrese šalju takve zahteve, i podaci su nelegalni, onda se na sloju gateway-a može ograničiti pristup sa tih IP adresa.

3.2.3 Treći metod

Obezbedite mehanizam koji može brzo da proceni da li je zahtev validan, na primer Bloom filter — Redis sam po sebi ima tu funkcionalnost.

Neka on održava sve legalne ključeve; ako parametar zahteva nije legalan, odmah se vraća. Inače se podatak uzima iz keša ili baze podataka.

O Bloom filteru možete pročitati u mom ranijem članku: xxx

4. Obrada poslovne pouzdanosti

Kao što je rečeno na početku, keš se odnosi na Redis.

Povećati dostupnost Redis-a: Redis treba da koristi ili cluster arhitekturu ili master-slave + sentinel. Garantujte dostupnost Redis-a.

Master-slave bez sentinela ne može automatski da radi failover, tako da ako imate samo master-slave, i padne u vrhuncu opterećenja ili u ključnom trenutku promocije...

Onda dok se pojavi produkciona uzbuna, dok se locira problem, dok se komunicira, dok operacija reši — dok se cela ta procedura završi, verovatno je već odavno kasno.

Smanjiti zavisnost od keša

Za vruće podatke, da li se može razmotriti dodavanje lokalnog keša, na primer: Guava, Ehcache, ili još jednostavnije — hashMap, List i slično.

Dok se smanjuje pritisak na Redis, istovremeno se poboljšavaju i performanse — dva muve jednim udarcem.

Degradacija posla

Sa stanovišta zaštite nizvodnih servisa (interfejsa ili baze podataka), da li se za scenarije sa velikim protokom može uvesti rate limiting? Tako čak i ako keš padne, neće povući sve nizvodne servise sa sobom.

I da li funkcionalnosti koje treba degradirati zaista mogu biti degradirane — unapred pripremite prekidač za degradaciju i logiku degradacije, u ključnom trenutku sve zavisi od njih.

Autor: Qi Xi, link za preuzimanje: https://mp.weixin.qq.com/s/juUzaf1TQYMuJFbw7Y3SXg