Simpan kaunter stok di satu tempat atomik dan kurangkannya secara atomik — sebuah Redis DECR (atau Lua script) yang memulangkan nilai baki. Jika hasilnya < 0, permintaan itu kalah; database tidak pernah menjadi gerbang concurrency. Selebihnya adalah tentang menggugurkan (shed) 999,000 permintaan lain dengan murah.
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"
Penemu duga mahu melihat anda menyebut race condition dengan tepat: SELECT stock kemudian UPDATE dalam dua kenyataan membenarkan dua permintaan kedua-duanya membaca 1000 dan kedua-duanya menjual — oversell klasik. "Baik" ialah "guna transaction / SELECT ... FOR UPDATE"; "hebat" ialah menyedari bahawa row lock men-serialize 1J permintaan ke atas satu baris panas (hot row) dan meruntuhkan throughput, jadi anda mengalihkan pertikaian (contention) ke satu operasi atomik single-threaded di Redis dan hanya mengekalkan (persist) pemenang. Perangkapnya ialah mempercayai semakan peringkat aplikasi (if (stock > 0)) tanpa keatoman (atomicity).
FOR UPDATE: Redis mengendalikan 100k+ ops/s pada satu hot key; sebuah Postgres row lock men-serialize dan cair di bawah flash sale. Simpan DB untuk rekod order yang durable.Pustaka soalan temu duga IT dengan jawapan terperinci — daripada Junior hingga Senior.
DermaDECR stock:sale123 adalah atomik — tiada dua permintaan boleh kedua-duanya membaca "tinggal 1". Sebuah Lua script melakukannya dalam satu round trip: semak baki, kurangkan, dan rekod SADD winners:{sale} {user} supaya seorang pengguna tidak boleh menang dua kali. Lua berjalan secara single-threaded pada Redis, jadi keseluruhan check-and-set ialah satu langkah atomik.>= 0) ditolak ke queue; seorang worker menulis order ke Postgres secara tak segerak. DB tidak pernah melihat 1J penulisan serentak — hanya ~1000 penulisan pemenang.