Trzymaj licznik zapasów w jednym atomowym miejscu i dekrementuj go atomowo — Redis DECR (lub skrypt Lua) zwracający pozostałą wartość. Jeśli wynik jest < 0, to żądanie przegrało; baza danych nigdy nie jest bramką współbieżności. Cała reszta polega na taniej redukcji pozostałych 999 000 żądań.
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 jest atomowe — żadne dwa żądania nie mogą jednocześnie odczytać „został 1". Skrypt Lua robi to w jednym round tripie: sprawdza pozostałą wartość, dekrementuje i zapisuje SADD winners:{sale} {user}, aby jeden użytkownik nie mógł wygrać dwukrotnie. Lua działa jednowątkowo w Redis, więc całe check-and-set jest jednym atomowym krokiem.>= 0) trafiają do kolejki; worker asynchronicznie zapisuje zamówienie do Postgres. Baza nigdy nie widzi 1 mln równoległych zapisów — tylko ~1000 zapisów zwycięzców.Rozmówca chce zobaczyć, że precyzyjnie nazwiesz wyścig (race condition): SELECT stock, a potem UPDATE w dwóch instrukcjach pozwala dwóm żądaniom odczytać 1000 i obu sprzedać — klasyczny oversell. „Dobrze" to „użyj transakcji / SELECT ... FOR UPDATE"; „świetnie" to rozpoznanie, że blokady wierszy serializują 1 mln żądań na jednym gorącym wierszu i zawalają throughput, więc przenosisz rywalizację do jednowątkowej operacji atomowej w Redis i utrwalasz tylko zwycięzców. Pułapką jest ufanie kontrolom na poziomie aplikacji (if (stock > 0)) bez atomowości.
FOR UPDATE: Redis obsługuje ponad 100 tys. operacji/s na jednym gorącym kluczu; blokada wiersza w Postgres serializuje i topi się pod flash sale. Zarezerwuj bazę na trwałe rekordy zamówień.Biblioteka pytań rekrutacyjnych IT ze szczegółowymi odpowiedziami — od Juniora do Seniora.
Wesprzyj