stock counter ਨੂੰ ਇੱਕੋ atomic ਥਾਂ ਉੱਤੇ ਰੱਖੋ ਅਤੇ ਇਸਨੂੰ atomically decrement ਕਰੋ — ਇੱਕ Redis DECR (ਜਾਂ ਇੱਕ Lua script) ਜੋ ਬਚਿਆ ਹੋਇਆ value return ਕਰੇ। ਜੇ ਨਤੀਜਾ < 0 ਹੈ, ਤਾਂ ਓਹ request ਹਾਰ ਗਈ; database ਕਦੇ ਵੀ concurrency gate ਨਹੀਂ ਹੁੰਦਾ। ਬਾਕੀ ਸਭ ਕੁਝ ਬਾਕੀ 9,99,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 ਬਚਿਆ" ਨਹੀਂ ਪੜ੍ਹ ਸਕਦੀਆਂ। ਇੱਕ Lua script ਇਹ ਇੱਕੋ round trip ਵਿੱਚ ਕਰਦਾ ਹੈ: ਬਚਿਆ ਹੋਇਆ check ਕਰੋ, decrement ਕਰੋ, ਅਤੇ SADD winners:{sale} {user} record ਕਰੋ ਤਾਂ ਜੋ ਇੱਕ user ਦੋ ਵਾਰ ਨਾ ਜਿੱਤ ਸਕੇ। Lua Redis ਉੱਤੇ single-threaded ਚੱਲਦਾ ਹੈ, ਇਸ ਲਈ ਪੂਰਾ check-and-set ਇੱਕੋ atomic step ਹੈ।>= 0) ਨੂੰ ਇੱਕ queue ਵਿੱਚ push ਕੀਤਾ ਜਾਂਦਾ ਹੈ; ਇੱਕ worker order ਨੂੰ asynchronously Postgres ਵਿੱਚ ਲਿਖਦਾ ਹੈ। DB ਕਦੇ 10 ਲੱਖ concurrent writes ਨਹੀਂ ਦੇਖਦਾ — ਸਿਰਫ਼ ~1000 winner writes।ਇੰਟਰਵਿਊਅਰ ਦੇਖਣਾ ਚਾਹੁੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ race condition ਨੂੰ ਸਹੀ-ਸਹੀ ਨਾਂ ਦਿਓ: SELECT stock ਫਿਰ UPDATE ਦੋ statements ਵਿੱਚ ਦੋ requests ਨੂੰ ਦੋਵਾਂ ਨੂੰ 1000 ਪੜ੍ਹਨ ਅਤੇ ਦੋਵਾਂ ਨੂੰ ਵੇਚਣ ਦਿੰਦਾ ਹੈ — classic oversell। "ਵਧੀਆ" ਹੈ "transaction / SELECT ... FOR UPDATE ਵਰਤੋ"; "ਸ਼ਾਨਦਾਰ" ਇਹ ਪਛਾਣਨਾ ਹੈ ਕਿ row locks 10 ਲੱਖ requests ਨੂੰ ਇੱਕ hot row ਉੱਤੇ serialize ਕਰ ਦਿੰਦੇ ਹਨ ਅਤੇ throughput ਢਾਹ ਦਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਤੁਸੀਂ contention ਨੂੰ Redis ਵਿੱਚ ਇੱਕ single-threaded atomic op ਉੱਤੇ ਲੈ ਜਾਂਦੇ ਹੋ ਅਤੇ ਸਿਰਫ਼ winners ਨੂੰ persist ਕਰਦੇ ਹੋ। ਫੰਦਾ ਹੈ application-level checks (if (stock > 0)) ਉੱਤੇ ਭਰੋਸਾ ਕਰਨਾ ਬਿਨਾਂ atomicity ਦੇ।
FOR UPDATE: Redis ਇੱਕ hot key ਉੱਤੇ 100k+ ops/s ਸੰਭਾਲਦਾ ਹੈ; ਇੱਕ Postgres row lock serialize ਕਰਦਾ ਹੈ ਅਤੇ flash sale ਹੇਠ ਪਿਘਲ ਜਾਂਦਾ ਹੈ। DB ਨੂੰ durable order records ਲਈ ਰਾਖਵਾਂ ਰੱਖੋ।ਵਿਸਤ੍ਰਿਤ ਜਵਾਬਾਂ ਨਾਲ IT ਇੰਟਰਵਿਊ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ — ਜੂਨੀਅਰ ਤੋਂ ਸੀਨੀਅਰ ਤੱਕ।
ਦਾਨ ਕਰੋ