Držite brojač zaliha na jednom atomskom mjestu i dekrementirajte ga atomski — Redis DECR (ili Lua skripta) koji vraća preostalu vrijednost. Ako je rezultat < 0, taj je zahtjev izgubio; baza podataka nikada nije gate za konkurentnost. Sve ostalo tiče se jeftinog odbacivanja preostalih 999.000 zahtjeva.
1M clients ─▶ CDN/edge (waiting room, drop bots) ─▶ LB
│
Stateless API pods
│
Redis: DECR stock (Lua: check+dec+record)
│hit>=0 │miss<0
▼ ▼
enqueue order ─▶ DB reject "sold out"
DECR stock:sale123 je atomski — dva zahtjeva ne mogu oba pročitati "ostalo 1". Lua skripta to obavlja u jednom round tripu: provjeri preostalo, dekrementiraj i zabilježi SADD winners:{sale} {user} tako da jedan korisnik ne može pobijediti dvaput. Lua se izvršava jednonitno na Redisu, pa je cijeli check-and-set jedan atomski korak.>= 0) guraju se u queue; worker asinkrono zapisuje narudžbu u Postgres. Baza nikada ne vidi 1 milijun istovremenih upisa — samo ~1000 upisa pobjednika.Ispitivač želi vidjeti da precizno imenujete race condition: SELECT stock pa UPDATE u dvije naredbe dopušta da dva zahtjeva oba pročitaju 1000 i oba prodaju — klasična prekomjerna prodaja. "Dobro" je "koristi transakciju / SELECT ... FOR UPDATE"; "odlično" je prepoznati da row lockovi serijaliziraju 1 milijun zahtjeva na jedan vrući redak i uruše throughput, pa premještate borbu na jednonitnu atomsku operaciju u Redisu i persistirate samo pobjednike. Zamka je vjerovanje provjerama na razini aplikacije (if (stock > 0)) bez atomičnosti.
FOR UPDATE: Redis obrađuje 100k+ operacija/s na jednom vrućem ključu; Postgres row lock serijalizira i topi se pod flash saleom. Bazu rezervirajte za trajne zapise narudžbi.Knjižnica IT pitanja za razgovore za posao s detaljnim odgovorima — od Juniora do Seniora.
Doniraj