შეინახეთ მარაგის counter ერთ ატომურ ადგილას და შეამცირეთ ის ატომურად — Redis DECR (ან Lua script), რომელიც აბრუნებს დარჩენილ მნიშვნელობას. თუ შედეგი < 0-ია, ეს request წააგო; მონაცემთა ბაზა არასდროსაა concurrency-ის კარიბჭე. დანარჩენი ყველაფერი ეხება იმ დანარჩენი 999,000 request-ის იაფად ჩამოცილებას.
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 ატომურია — ორ request-ს ვერ წაუკითხავს ერთდროულად "1 დარჩა". Lua script ამას ერთ round trip-ში აკეთებს: ამოწმებს დარჩენილს, ამცირებს და აღრიცხავს SADD winners:{sale} {user}, რომ ერთმა მომხმარებელმა ორჯერ ვერ მოიგოს. Lua ერთ ნაკადში (single-threaded) მუშაობს Redis-ზე, ამიტომ მთელი check-and-set ერთი ატომური ნაბიჯია.>= 0) queue-ში ხვდებიან; worker order-ს ასინქრონულად წერს Postgres-ში. DB ვერასდროს ხედავს 1M ერთდროულ write-ს — მხოლოდ ~1000 გამარჯვებულის write-ს.ინტერვიუერს სურს დაინახოს, რომ ზუსტად ასახელებთ race condition-ს: SELECT stock შემდეგ UPDATE ორ განცხადებაში ორ request-ს აძლევს საშუალებას, ორივემ წაიკითხოს 1000 და ორივემ გაყიდოს — კლასიკური oversell. "კარგი" არის "გამოიყენე transaction / SELECT ... FOR UPDATE"; "შესანიშნავი" არის იმის აღიარება, რომ row lock-ები 1M request-ს ერთ ცხელ მწკრივზე სერიალიზებს და throughput-ს ანგრევს, ამიტომ contention-ს გადაგაქვთ Redis-ის single-threaded ატომურ ოპერაციაზე და მხოლოდ გამარჯვებულებს ინახავთ. ხაფანგია application-დონის შემოწმებების (if (stock > 0)) ნდობა ატომურობის გარეშე.
FOR UPDATE: Redis ამუშავებს 100k+ ops/s ერთ ცხელ გასაღებზე; Postgres-ის row lock სერიალიზებს და დნება flash sale-ის დროს. დაუტოვეთ DB durable order ჩანაწერებს.IT გასაუბრების კითხვების ბიბლიოთეკა დეტალური პასუხებით — Junior-დან Senior-მდე.
შემოწირულობა