Laikykite atsargų skaitiklį vienoje atominėje vietoje ir mažinkite jį atomiškai — Redis DECR (arba Lua scenarijus), kuris grąžina likusią reikšmę. Jei rezultatas < 0, ta užklausa pralaimėjo; duomenų bazė niekada nėra lygiagretumo vartai. Visa kita — apie tai, kaip pigiai atmesti likusias 999 000 užklausų.
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 yra atominis — jokios dvi užklausos negali abi perskaityti „liko 1". Lua scenarijus tai atlieka per vieną round trip: patikrina likutį, sumažina ir įrašo SADD winners:{sale} {user}, kad vienas naudotojas negalėtų laimėti dukart. Lua Redise veikia vienoje gijoje, tad visas check-and-set yra vienas atominis žingsnis.>= 0) stumiami į eilę; workeris asinchroniškai įrašo užsakymą į Postgres. DB niekada nemato 1 mln. lygiagrečių įrašymų — tik ~1000 laimėtojų įrašymų.Interviuotojas nori pamatyti, kaip tiksliai įvardijate lenktynių sąlygą (race condition): SELECT stock, tada UPDATE dviem sakiniais leidžia dviem užklausoms abiem perskaityti 1000 ir abiem parduoti — klasikinis perpardavimas. „Gerai" yra „naudokite transakciją / SELECT ... FOR UPDATE"; „puikiai" yra suvokti, kad eilučių užraktai serializuoja 1 mln. užklausų į vieną karštą eilutę ir sugriauna throughput, tad perkeliate konkurenciją į vienos gijos atominę operaciją Redise ir įrašote tik laimėtojus. Spąstai — pasitikėti aplikacijos lygio patikromis (if (stock > 0)) be atomiškumo.
FOR UPDATE: Redis apdoroja 100k+ ops/s viename karštame rakte; Postgres eilutės užraktas serializuoja ir sutirpsta per flash sale. Palikite DB patvariems užsakymų įrašams.IT pokalbių klausimų biblioteka su išsamiais atsakymais — nuo Junior iki Senior.
Paaukoti