Weka stock counter mahali pamoja pa atomic na uipunguze kwa njia ya atomic — DECR ya Redis (au Lua script) inayorudisha thamani iliyobaki. Ikiwa matokeo ni < 0, request hiyo imeshindwa; database kamwe si lango la concurrency. Kila kitu kingine kinahusu kuondoa (shed) requests nyingine 999,000 kwa gharama nafuu.
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 ni atomic — hakuna requests mbili zinazoweza kusoma "1 imebaki" kwa pamoja. Lua script hufanya hivyo katika round trip moja: kagua kilichobaki, punguza, na rekodi SADD winners:{sale} {user} ili mtumiaji mmoja asishinde mara mbili. Lua huendeshwa single-threaded kwenye Redis, hivyo check-and-set nzima ni hatua moja ya atomic.>= 0) husukumwa kwenye queue; worker huandika order kwenye Postgres kwa njia ya asynchronous. DB haioni kamwe writes milioni 1 kwa pamoja — ni writes za washindi ~1000 tu.Mhojiwa anataka kuona ukitaja race condition kwa usahihi: SELECT stock kisha UPDATE katika statements mbili huruhusu requests mbili zote kusoma 1000 na zote kuuza — oversell ya kawaida. "Nzuri" ni "tumia transaction / SELECT ... FOR UPDATE"; "bora sana" ni kutambua kwamba row locks hupanga requests milioni 1 mfululizo kwenye row moto mmoja na kuporomosha throughput, hivyo unahamishia contention kwenye operesheni moja ya atomic ya single-threaded katika Redis na kuhifadhi washindi tu. Mtego ni kuamini ukaguzi wa kiwango cha application (if (stock > 0)) bila atomicity.
FOR UPDATE: Redis hushughulikia ops 100k+ kwa sekunde kwenye hot key moja; row lock ya Postgres hupanga mfululizo na kuyeyuka chini ya flash sale. Hifadhi DB kwa order records za kudumu.Maktaba ya maswali ya mahojiano ya IT yenye majibu ya kina — kutoka Junior hadi Senior.
Changia