Giữ bộ đếm tồn kho ở một nơi atomic duy nhất và giảm nó theo kiểu atomic — một DECR trên Redis (hoặc script Lua) trả về giá trị còn lại. Nếu kết quả < 0, request đó thua; database không bao giờ là cổng kiểm soát concurrency. Phần còn lại là làm sao loại 999.000 request kia thật rẻ.
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 là atomic — không hai request nào cùng đọc được "còn 1". Một script Lua làm gọn trong một round trip: kiểm tra số còn lại, giảm, và ghi SADD winners:{sale} {user} để một user không thắng hai lần. Lua chạy đơn luồng trên Redis, nên cả bước check-and-set là một bước atomic.>= 0) được đẩy vào queue; một worker ghi đơn hàng vào Postgres bất đồng bộ. DB không bao giờ nhận 1 triệu ghi đồng thời — chỉ ~1000 lượt ghi của người thắng.Người phỏng vấn muốn thấy bạn gọi đúng tên race condition: SELECT stock rồi UPDATE trong hai câu lệnh khiến hai request cùng đọc 1000 và cùng bán — oversell kinh điển. "Khá" là "dùng transaction / SELECT ... FOR UPDATE"; "xuất sắc" là nhận ra row lock sẽ nối tiếp 1 triệu request lên một hàng nóng và bóp nghẹt throughput, nên bạn dời tranh chấp về một thao tác atomic đơn luồng trên Redis và chỉ ghi bền người thắng. Bẫy là tin vào kiểm tra ở tầng ứng dụng (if (stock > 0)) mà không có tính atomic.
FOR UPDATE: Redis xử lý 100k+ ops/s trên một key nóng; row lock của Postgres nối tiếp và tan chảy dưới flash sale. Dành DB cho bản ghi đơn hàng bền vững.Thư viện câu hỏi phỏng vấn IT với đáp án chi tiết — từ Junior đến Senior.
Ủng hộ