Ajiye counter na stock a wuri ɗaya na atomic kuma ka rage shi cikin atomic — Redis DECR (ko Lua script) da ke dawo da ragowar ƙima. Idan sakamakon < 0, wannan request ya rasa; database ba shi taɓa zama ƙofar concurrency. Sauran duk game da yadda za a zubar da sauran requests 999,000 cikin arha ne.
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 atomic ne — babu requests biyu da za su duka karanta "1 ne ya rage". Lua script yana yin sa cikin round trip ɗaya: bincika ragowa, rage, sannan rubuta SADD winners:{sale} {user} don mai amfani ɗaya kada ya yi nasara sau biyu. Lua yana gudana single-threaded a Redis, don haka duk check-and-set mataki ɗaya ne na atomic.>= 0) ana tura su cikin queue; worker yana rubuta order ɗin zuwa Postgres cikin asynchronous. DB ba ya taɓa ganin rubuce-rubuce miliyan 1 a lokaci guda — kusan rubuce-rubuce 1000 na masu nasara ne kawai.Mai yin hirar yana son ganin ka ambaci race condition daidai: SELECT stock sannan UPDATE a cikin statements biyu yana bar requests biyu su duka karanta 1000 su kuma duka sayar — oversell na gargajiya. "Mai kyau" shi ne "amfani da transaction / SELECT ... FOR UPDATE"; "mai kyau sosai" shi ne fahimtar cewa row locks suna serialize requests miliyan 1 zuwa row mai zafi ɗaya kuma suna rushe throughput, don haka ka mai da contention zuwa atomic op na single-threaded a Redis kuma ka adana masu nasara kawai. Tarkon shi ne dogaro da bincike a matakin application (if (stock > 0)) ba tare da atomicity ba.
FOR UPDATE: Redis yana sarrafa ops 100k+ a daƙiƙa a key mai zafi ɗaya; Postgres row lock yana serialize kuma yana narke a ƙarƙashin flash sale. Ajiye DB don durable order records.Ɗakin karatu na tambayoyin hira na IT tare da amsoshi cikakke — daga Junior zuwa Senior.
Ba da Gudummawa