Mbajeni counter-in e stokut në një vend të vetëm atomik dhe zbriteni atë në mënyrë atomike — një Redis DECR (ose një Lua script) që kthen vlerën e mbetur. Nëse rezultati është < 0, ai request humbi; baza e të dhënave kurrë nuk është porta e concurrency-t. Gjithçka tjetër ka të bëjë me heqjen e 999,000 request-eve të tjera në mënyrë të lirë.
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 është atomik — asnjë dy request nuk mund të lexojnë të dyja "1 i mbetur". Një Lua script e bën atë në një round trip të vetëm: kontrollon të mbeturën, zbret, dhe regjistron SADD winners:{sale} {user} që një përdorues të mos fitojë dy herë. Lua ekzekutohet single-threaded në Redis, kështu që i gjithë check-and-set është një hap i vetëm atomik.>= 0) shtyhen në një queue; një worker shkruan porosinë në Postgres në mënyrë asinkrone. DB kurrë nuk sheh 1M shkrime konkurrente — vetëm ~1000 shkrime fituesish.Intervistuesi dëshiron t'ju shohë të emërtoni race condition me saktësi: SELECT stock pastaj UPDATE në dy statement-e lejon dy request të lexojnë të dyja 1000 dhe të shesin të dyja — oversell klasik. "Mirë" është "përdor një transaction / SELECT ... FOR UPDATE"; "e shkëlqyer" është të kuptosh se row locks serializojnë 1M request mbi një row të nxehtë dhe shkatërrojnë throughput-in, kështu që e zhvendosni contention-in te një operacion atomik single-threaded në Redis dhe persistoni vetëm fituesit. Kurthi është të besosh kontrollet në nivel aplikacioni (if (stock > 0)) pa atomicitet.
FOR UPDATE: Redis përballon 100k+ ops/s në një key të nxehtë; një row lock në Postgres serializohet dhe shkrihet nën një flash sale. Rezervojeni DB-në për regjistrat e qëndrueshëm të porosive.Një bibliotekë pyetjesh intervistash IT me përgjigje të detajuara — nga Junior te Senior.
Dhuro