stock counter-ஐ ஒரே atomic இடத்தில் வைத்து அதை atomic-ஆக decrement செய்யுங்கள் — மீதமுள்ள மதிப்பைத் திருப்பித் தரும் ஒரு Redis DECR (அல்லது ஒரு Lua script). முடிவு < 0 எனில், அந்த request தோற்றது; database ஒருபோதும் concurrency gate அல்ல. மற்ற எல்லாமே மீதமுள்ள 999,000 requests-ஐ மலிவாக அகற்றுவது பற்றியது.
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 — இரண்டு requests-ம் "1 left" என்று படிக்க முடியாது. ஒரு Lua script இதை ஒரே round trip-இல் செய்கிறது: மீதத்தைச் சரிபார்க்கிறது, decrement செய்கிறது, மேலும் SADD winners:{sale} {user} பதிவு செய்கிறது, இதனால் ஒரு பயனர் இருமுறை வெற்றி பெற முடியாது. Redis-இல் Lua single-threaded-ஆக இயங்குகிறது, எனவே முழு check-and-set-ம் ஒரே atomic படி.>= 0) ஒரு queue-க்குத் தள்ளப்படுகின்றன; ஒரு worker order-ஐ Postgres-க்கு asynchronous-ஆக எழுதுகிறது. DB ஒருபோதும் 1M concurrent writes-ஐப் பார்ப்பதில்லை — வெறும் ~1000 winner writes மட்டுமே.race condition-ஐ நீங்கள் துல்லியமாகக் குறிப்பிடுவதை நேர்காணல் செய்பவர் பார்க்க விரும்புகிறார்: இரண்டு statements-இல் SELECT stock பிறகு UPDATE என்பது இரண்டு requests-ம் 1000-ஐப் படித்து இருமுறை விற்க அனுமதிக்கிறது — classic oversell. "நல்லது" என்பது "transaction / SELECT ... FOR UPDATE பயன்படுத்து"; "சிறந்தது" என்பது row locks 1M requests-ஐ ஒரே hot row மீது serialize செய்து throughput-ஐ சரிக்கச் செய்யும் என்பதை உணர்ந்து, contention-ஐ Redis-இல் ஒரு single-threaded atomic op-க்கு நகர்த்தி winners-ஐ மட்டும் persist செய்வது. atomicity இல்லாமல் application-level சரிபார்ப்புகளை (if (stock > 0)) நம்புவது தான் பொறி.
FOR UPDATE: Redis ஒரே hot key மீது 100k+ ops/s கையாளுகிறது; ஒரு Postgres row lock serialize செய்து flash sale-இல் உருகும். durable order records-க்காக DB-ஐ reserve செய்யுங்கள்.விரிவான பதில்களுடன் கூடிய IT நேர்காணல் கேள்விகளின் நூலகம் — Junior முதல் Senior வரை.
நன்கொடை