Håll lagerräknaren på ett enda atomiskt ställe och dekrementera den atomiskt — en Redis DECR (eller ett Lua-skript) som returnerar återstående värde. Om resultatet är < 0 förlorade den requesten; databasen är aldrig concurrency-grinden. Allt annat handlar om att billigt avvisa de övriga 999 000 requesterna.
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 är atomiskt — inga två requester kan båda läsa "1 kvar". Ett Lua-skript gör det i en round trip: kontrollera återstående, dekrementera och registrera SADD winners:{sale} {user} så att en användare inte kan vinna två gånger. Lua körs single-threaded på Redis, så hela check-and-set är ett atomiskt steg.>= 0) skickas till en kö; en worker skriver ordern till Postgres asynkront. DB:n ser aldrig 1M samtidiga skrivningar — bara ~1000 vinnarskrivningar.Intervjuaren vill se att du namnger race condition exakt: SELECT stock följt av UPDATE i två satser låter två requester båda läsa 1000 och båda sälja — klassisk översäljning. "Bra" är "använd en transaktion / SELECT ... FOR UPDATE"; "utmärkt" är att inse att row locks serialiserar 1M requester mot en enda het rad och kollapsar throughput, så du flyttar contention till en single-threaded atomisk operation i Redis och persisterar bara vinnare. Fällan är att lita på kontroller på applikationsnivå (if (stock > 0)) utan atomicitet.
FOR UPDATE: Redis hanterar 100k+ ops/s på en het nyckel; ett Postgres row lock serialiserar och smälter under en flash sale. Reservera DB:n för hållbara orderposter.Ett bibliotek med IT-intervjufrågor och detaljerade svar — från Junior till Senior.
Donera