Stok sayacını tek bir atomik yerde tutun ve atomik olarak azaltın — kalan değeri döndüren bir Redis DECR (veya bir Lua script). Sonuç < 0 ise, o istek kaybetti; veritabanı asla concurrency kapısı değildir. Geri kalan her şey, diğer 999.000 isteği ucuza savuşturmakla ilgilidir.
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 atomiktir — iki istek aynı anda "1 kaldı" okuyamaz. Bir Lua script bunu tek round trip'te yapar: kalanı kontrol et, azalt ve SADD winners:{sale} {user} ile kaydet, böylece bir kullanıcı iki kez kazanamaz. Lua, Redis üzerinde single-threaded çalışır, dolayısıyla tüm check-and-set tek bir atomik adımdır.>= 0) bir kuyruğa itilir; bir worker siparişi asenkron olarak Postgres'e yazar. DB asla 1 milyon eşzamanlı yazma görmez — yalnızca ~1000 kazanan yazması.Mülakatı yapan kişi, race condition'ı tam olarak adlandırdığınızı görmek ister: iki ayrı ifadede SELECT stock ardından UPDATE, iki isteğin de 1000 okumasına ve ikisinin de satmasına izin verir — klasik oversell. "İyi", "bir transaction / SELECT ... FOR UPDATE kullan"dır; "harika", satır kilitlerinin 1 milyon isteği tek bir hot row üzerinde serileştirdiğini ve throughput'u çökerttiğini fark etmektir, bu yüzden çekişmeyi Redis'teki single-threaded atomik bir işleme taşır ve yalnızca kazananları kalıcılaştırırsınız. Tuzak, atomiklik olmadan uygulama seviyesi kontrollere (if (stock > 0)) güvenmektir.
FOR UPDATE: Redis, tek bir hot key üzerinde 100k+ ops/s işler; bir Postgres row lock serileştirir ve bir flash sale altında erir. DB'yi dayanıklı sipariş kayıtları için ayırın.Junior'dan Senior'a detaylı cevaplarla bir BT mülakat soruları kütüphanesi.
Bağış Yap